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

Wed Jul 27 13:31:28 BST 2016

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