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

Wed Jul 27 13:52:08 BST 2016

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