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

Wed Jul 27 14:30:09 BST 2016

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