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

Wed Jul 27 15:08:49 BST 2016

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)