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

Wed Jul 27 14:45:11 BST 2016

I would be surprised to find a lake in the saa data, the input should be from natural=coastline.

Anyway, I tried with your version and still sea the island .

Tested with r3683 and (unchanged) default style.

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 15:30:09
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Option to output polygons in size order

Ah - I guess the Chieemsee will be taken from the sea input files - won't it? I never really now what water features are taken from which input. 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.

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<mailto: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<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto: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<mailto: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<mailto: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<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto: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<mailto: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<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20160727/9e3cd44e/attachment.html>