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

Fri Jul 29 10:45:47 BST 2016

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