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

Thu Jul 28 23:11:45 BST 2016

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