[mkgmap-dev] Option to output polygons in size order

Fri Jul 29 12:55:36 BST 2016

well I have no other rules with 0x3c and resolution 18-21 in my style. So I
don't know how else it can happen. And yes - mapdata is up to date from
geofabrik as of yesterday. Strangely the europe map is fine, Germany and
Alps are not fine - so it's kinda random.
Oh yeah - the name for the water is not Chieemsee but Herreninsel.

However for island the only rule that should fit is:
place=island & layer!=*     & 20resolution!=yes & name:en!="North Island" &
name:en!="South Island" & natural!=coastline & area_size() < 2000000 [0x0d
resolution 20]

but it clearly puts 0x3c and starts at resolution 18. The actual island
does not end up in the map - as I guess 20resolution=yes is set further up
in the style.

On 29 July 2016 at 13:40, Gerd Petermann <GPetermann_muenchen at hotmail.com>
wrote:

> Hi Felix,
>
>
> I have no idea why the Herreninsel
> http://www.openstreetmap.org/way/4605746
>
> should  trigger any of these rules. Are you sure that your input file
> contains the current
>
> OSM data?
>
> To make sure I suggest to download the relation
> http://www.openstreetmap.org/relation/32246
>
> in JOSM, safe it to a file and use that as input for mkgmap.
>
> Next, you can enable logging so that you see what happens in mkgmap.
>
>
> Gerd
>
> ------------------------------
> *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> *Gesendet:* Freitag, 29. Juli 2016 13:12:05
>
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>
> I guess the area_size() function kinda checks if it's big enough - and in
> turn does not check anymore if it is part of the multipolygon or not. Else
> I really cannot explain the flooding. I can change all lines which have
> 0x3c to a unique number - and check which line it is. Will do so tomorrow.
> However there is clearly some bug.
>
> On 29 July 2016 at 12:05, Gerd Petermann <GPetermann_muenchen at hotmail.com>
> wrote:
>
>> Hi Felix,
>>
>>
>> I suggest to use echotags to find out if a rule fires or not. What kind
>> of error
>>
>> do you expect with the area_size() function?
>>
>>
>> Gerd
>> ------------------------------
>> *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
>> von Felix Hartmann <extremecarver at gmail.com>
>> *Gesendet:* Freitag, 29. Juli 2016 11:45:47
>>
>> *An:* Development list for mkgmap
>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>
>> Nope - it's not the splitter - it's fully within one tile. I guess there
>> is a bug in the style parser together with area_size() filter and continue
>> command?
>>
>> I actually looked at it with gpsmapedit - and I see the island is cut out
>> - but additionally to the cut out water is put into it. The only lines in
>> my polygons file that can be related to it are as follows:
>> (note the flooded island also exists at resolution 18 as 0x3c - so all
>> other lines are only relevant for the key 20resolution!=yes).
>> I put those lines which should not fire in grey. Chiemsee is
>> natural=water & water=lake.
>>
>> ( natural=forest | landuse=wood | natural=forrest | landuse=forrest )
>> {set landuse=forest}
>> ( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution
>> 18-20 continue with_actions]
>> ( natural=glacier | landuse=glacier ) & 20resolution!=yes {set
>> 20resolution=yes} [0x4d resolution 18-21 continue with_actions]
>>
>> ( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set
>> 20resolution=yes} [0x3c resolution 18-21 continue with_actions]
>> natural=water & water=oxbow     & 20resolution!=yes {set
>> 20resolution=yes} [0x3c resolution 20-21 continue with_actions]
>> natural=water & ( water=cove | water=lagoon )    & 20resolution!=yes {set
>> 20resolution=yes} [0x3c resolution 21-21 continue with_actions]
>> natural=water & water=* & water!=lake & water!=reservoir & water!=canal &
>> water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake  &
>> area_size() < 1000         & 20resolution!=yes {set 20resolution=yes}
>> natural=water & water=reflecting_pool     & 20resolution!=yes {set
>> 20resolution=yes}
>> natural=water & water=lock     & 20resolution!=yes {set 20resolution=yes}
>> natural=water & water=moat     & 20resolution!=yes {set 20resolution=yes}
>> natural=water & water=wastewater     & 20resolution!=yes {set
>> 20resolution=yes}
>> natural=water & ( water=shallow | water=drain | water=well |
>> water=salt_pool | water='Salt_pool' )     & 20resolution!=yes {set
>> 20resolution=yes}
>> natural=water & ( water=intermittent | intermettent=yes )     &
>> 20resolution!=yes {set 20resolution=yes}
>> natural=water & ( water=reservoir | water=canal )    & 20resolution!=yes
>> {set 20resolution=yes} [0x3c resolution 19-21 continue with_actions]
>> natural=water & 20resolution!=yes & area_size() > 2000 {set
>> 20resolution=yes} [0x3c resolution 18-21 continue with_actions]
>>
>>
>>
>> Is there maybe a bug related to the area_size() filter and Multipolygons?
>>
>> (not I did not use yet this mornings patch). Right now my server is
>> blocked - I can try out things only from tomorrow onwards.
>>
>> On 29 July 2016 at 07:07, Gerd Petermann <GPetermann_muenchen at hotmail.com
>> > wrote:
>>
>>> Hi Felix,
>>>
>>>
>>> okay. In case that you also used splitter to calculate new tiles a
>>> possible explanation
>>>
>>> might be a special case at tile boundaries, although the --keep-complete
>>> option should
>>>
>>> avoid that.
>>>
>>>
>>> Gerd
>>> ------------------------------
>>> *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
>>> von Felix Hartmann <extremecarver at gmail.com>
>>> *Gesendet:* Freitag, 29. Juli 2016 00:11:45
>>> *An:* Development list for mkgmap
>>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>>
>>> Well - recompiled and this time the Chieemsee is fine. Really do wonder
>>> why it missed the islands. Next time someone reports somethink like this -
>>> or I notice a problem somewhere I'll report on time...
>>>
>>> On 27 July 2016 at 16:08, Thorsten Kukuk <kukuk at suse.de> wrote:
>>>
>>>> On Wed, Jul 27, Felix Hartmann wrote:
>>>>
>>>> > Ah - I guess the Chieemsee will be taken from the sea input files -
>>>> won't
>>>> > it?
>>>>
>>>> No, it does not. Lakes are natural=water and most of the time
>>>> multipolygones.
>>>>
>>>> > I never really now what water features are taken from which input.
>>>>
>>>> Quite easy: coastline, and only coastlines, are taken from the sea
>>>> input.
>>>> Lakes are no sea.
>>>>
>>>> > If
>>>> > not I would really wonder why all islands in the Chieemsee are
>>>> flooded for
>>>> > me. The Chieemsee was updated last time 20 days ago - so I should
>>>> have the
>>>> > correct data if it is taken from the normal osm.pbf file.
>>>>
>>>> On my map, the Chiemsee including the three islands, is correct, no
>>>> flooding
>>>> anywhere.
>>>>
>>>>   Thorsten
>>>>
>>>> > I used them since 10.06.2016 without update. I just uploaded the
>>>> version I
>>>> > use here: https://openmtbmap.org/sea.zip
>>>> >
>>>> >
>>>> > Felix
>>>> >
>>>> >
>>>> >
>>>> > On 27 July 2016 at 15:14, Gerd Petermann <
>>>> GPetermann_muenchen at hotmail.com>
>>>> > wrote:
>>>> >
>>>> > > Hmm,
>>>> > >
>>>> > >
>>>> > > the way 4605746 is an inner member of mp-relation
>>>> > > https://www.openstreetmap.org/relation/32246
>>>> > >
>>>> > > I see no problems with the default style. Do you still have the
>>>> 18.07.
>>>> > > data ?
>>>> > >
>>>> > >
>>>> > > Gerd
>>>> > >
>>>> > >
>>>> > > ------------------------------
>>>> > > *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
>>>> Auftrag von
>>>> > > Felix Hartmann <extremecarver at gmail.com>
>>>> > > *Gesendet:* Mittwoch, 27. Juli 2016 14:59:51
>>>> > >
>>>> > > *An:* Development list for mkgmap
>>>> > > *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order
>>>> > >
>>>> > > Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07
>>>> data
>>>> > > and already flodded in June. Was fine in March though.
>>>> > >
>>>> > > http://www.openstreetmap.org/way/4605746
>>>> > >
>>>> > > It should be a multipolygon but it's not. It's much smaller than
>>>> the lake
>>>> > > however. Basically right now in my map the whole forest is flooded.
>>>> Also
>>>> > > Fraueninsel flooded. Mapnik get'r it right however!
>>>> > >
>>>> > > On 27 July 2016 at 14:52, Felix Hartmann <extremecarver at gmail.com>
>>>> wrote:
>>>> > >
>>>> > >> Know - sadly not. Usually such places are fixed up sooner or later
>>>> - and
>>>> > >> then sometimes destroyed again. It's kinda hard to find them too -
>>>> because
>>>> > >> you will either give lake or water preference (or give it same
>>>> > >> draw-priority and end up with chance). I just know since I
>>>> implemented a
>>>> > >> limited layer approach - complaints about something "missing" are
>>>> much more
>>>> > >> rare.
>>>> > >>
>>>> > >> On 27 July 2016 at 14:44, Gerd Petermann <
>>>> GPetermann_muenchen at hotmail.com
>>>> > >> > wrote:
>>>> > >>
>>>> > >>> Hi Felix,
>>>> > >>>
>>>> > >>>
>>>> > >>> okay, I like the idea reg. layer, but I was not yet able to find
>>>> an
>>>> > >>> example in OSM.
>>>> > >>>
>>>> > >>> I assume the problem appears only in specific regions wheres such
>>>> an
>>>> > >>> unexperienced
>>>> > >>>
>>>> > >>> mapper is active. Do you know such a region?
>>>> > >>>
>>>> > >>>
>>>> > >>> Gerd
>>>> > >>>
>>>> > >>>
>>>> > >>> ------------------------------
>>>> > >>> *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
>>>> Auftrag
>>>> > >>> von Felix Hartmann <extremecarver at gmail.com>
>>>> > >>> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28
>>>> > >>>
>>>> > >>> *An:* Development list for mkgmap
>>>> > >>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size
>>>> order
>>>> > >>>
>>>> > >>> Well the smaller polygon in usual is the one that people expect
>>>> to end
>>>> > >>> up on top. HOWEVER - before even checking for size - there could
>>>> be a check
>>>> > >>> for the layer tag. It is still commonly used by people who do not
>>>> > >>> understand how to use multipolygons.
>>>> > >>>
>>>> > >>> So an approach could be - take polygon overlap check for values
>>>> defined
>>>> > >>> in "overlap" style-file - after multipolgyon overlap is gone.
>>>> > >>> Check if layer tag is present on either of the polygons. If yes -
>>>> then
>>>> > >>> cut out according to layer.
>>>> > >>> If not - cut out the smaller from the bigger. Usually it's the
>>>> smaller
>>>> > >>> polygon that should appear.
>>>> > >>>
>>>> > >>> I guess it needs to happen quite late therefore. Why smaller -
>>>> well
>>>> > >>> quite often people contacted me about islands missing/flooded or
>>>> similar -
>>>> > >>> and usually it was the smaller polygon that should have been on
>>>> top. I
>>>> > >>> guess with layer tag however 90% of all cases can already be
>>>> resolved. (I
>>>> > >>> do this in a very limited way already - by having some polygons
>>>> like water
>>>> > >>> and forest in several versions with different priority based on
>>>> layer tag -
>>>> > >>> this did help a lot)
>>>> > >>>
>>>> > >>> Felix
>>>> > >>>
>>>> > >>> On 27 July 2016 at 13:41, Gerd Petermann <
>>>> > >>> GPetermann_muenchen at hotmail.com> wrote:
>>>> > >>>
>>>> > >>>> Hi Felix,
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> okay, maybe I'll add this as an experimental option as well.
>>>> > >>>>
>>>> > >>>> One big question here is: At what point would the cutting
>>>> > >>>>
>>>> > >>>> happen? Before style processing (as we do with mp-relations)
>>>> > >>>>
>>>> > >>>> or maybe as a new stage before the img data is written.
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> What I don't yet understand is the idea that a smaller
>>>> > >>>>
>>>> > >>>> polygon is more important. Do you have examples for that,
>>>> > >>>>
>>>> > >>>> esp. cases where shapes do only partially overlap?
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> Gerd
>>>> > >>>> ------------------------------
>>>> > >>>> *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
>>>> Auftrag
>>>> > >>>> von Felix Hartmann <extremecarver at gmail.com>
>>>> > >>>> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37
>>>> > >>>> *An:* Development list for mkgmap
>>>> > >>>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size
>>>> order
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> On 27 July 2016 at 09:29, Gerd Petermann <
>>>> > >>>> GPetermann_muenchen at hotmail.com> wrote:
>>>> > >>>>
>>>> > >>>>> reg. the idea of "cutting out overlaps": I guess it would
>>>> consume
>>>> > >>>>> quite a lot of CPU and it would heavily increase the img size
>>>> > >>>>>
>>>> > >>>>> because we would have to write many more points. Think of a
>>>> shape for
>>>> > >>>>> "place=village" with hundreds of holes for each building
>>>> > >>>>>
>>>> > >>>>> shape. Up to now we save the shape for the village and the
>>>> shapes for
>>>> > >>>>> the buildings. With cutting we have to calculate what
>>>> > >>>>>
>>>> > >>>>> remains of the village shape, this would be a very complex
>>>> shape with
>>>> > >>>>> many holes, so it would have many points.
>>>> > >>>>>
>>>> > >>>>> I don't think that would be a good idea.
>>>> > >>>>>
>>>> > >>>>>
>>>> > >>>> Well that's why I wrote we will need an additional file in the
>>>> > >>>> style-file for this. So only for certain polygons this should be
>>>> done.
>>>> > >>>> Prime examples are: any kind of forest, most kind of water, and
>>>> maybe a
>>>> > >>>> handful more. However definitely not buildings or for example
>>>> poygons you
>>>> > >>>> can put semi-transparent.
>>>> > >>>>
>>>> > >>>> I'm quite sure with this limited approach 90% of problems would
>>>> be
>>>> > >>>> gone. And mapsize only a couple percent bigger. However I have
>>>> no clue
>>>> > >>>> about complexity and CPU cycles for such a limited approach.
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> --
>>>> > >>>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>>> > >>>> Schusterbergweg 32/8
>>>> > >>>> 6020 Innsbruck
>>>> > >>>> Austria - Österreich
>>>> > >>>>
>>>> > >>>> _______________________________________________
>>>> > >>>> mkgmap-dev mailing list
>>>> > >>>> mkgmap-dev at lists.mkgmap.org.uk
>>>> > >>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>> > >>>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>> --
>>>> > >>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>>> > >>> Schusterbergweg 32/8
>>>> > >>> 6020 Innsbruck
>>>> > >>> Austria - Österreich
>>>> > >>>
>>>> > >>> _______________________________________________
>>>> > >>> mkgmap-dev mailing list
>>>> > >>> mkgmap-dev at lists.mkgmap.org.uk
>>>> > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>> > >>>
>>>> > >>
>>>> > >>
>>>> > >>
>>>> > >> --
>>>> > >> Felix Hartman - Openmtbmap.org & VeloMap.org
>>>> > >> Schusterbergweg 32/8
>>>> > >> 6020 Innsbruck
>>>> > >> Austria - Österreich
>>>> > >>
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > Felix Hartman - Openmtbmap.org & VeloMap.org
>>>> > > Schusterbergweg 32/8
>>>> > > 6020 Innsbruck
>>>> > > Austria - Österreich
>>>> > >
>>>> > > _______________________________________________
>>>> > > mkgmap-dev mailing list
>>>> > > mkgmap-dev at lists.mkgmap.org.uk
>>>> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Felix Hartman - Openmtbmap.org & VeloMap.org
>>>> > Schusterbergweg 32/8
>>>> > 6020 Innsbruck
>>>> > Austria - Österreich
>>>>
>>>> > _______________________________________________
>>>> > mkgmap-dev mailing list
>>>> > mkgmap-dev at lists.mkgmap.org.uk
>>>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>
>>>>
>>>> --
>>>> Thorsten Kukuk, Senior Architect SLES & Common Code Base
>>>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
>>>> GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG
>>>> Nürnberg)
>>>> _______________________________________________
>>>> mkgmap-dev mailing list
>>>> mkgmap-dev at lists.mkgmap.org.uk
>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>> Schusterbergweg 32/8
>>> 6020 Innsbruck
>>> Austria - Österreich
>>>
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160729/fa8e627c/attachment-0001.html>