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

Fri Jul 29 12:12:05 BST 2016

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160729/577a2462/attachment-0001.html>