<div dir="ltr"><div><div><div><div><div>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. <br><br></div>So an approach could be - take polygon overlap check for values defined in "overlap" style-file - after multipolgyon overlap is gone.<br></div>Check if layer tag is present on either of the polygons. If yes - then cut out according to layer.<br></div>If not - cut out the smaller from the bigger. Usually it's the smaller polygon that should appear.<br><br></div>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)<br><br></div>Felix<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 27 July 2016 at 13:41, Gerd Petermann <span dir="ltr"><<a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>

<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Felix,</p>
<p><br>
</p>
<p>okay, maybe I'll add this as an experimental option as well. <br>
</p>
<p>One big question here is: At what point would the cutting</p>
<p>happen? Before style processing (as we do with mp-relations)</p>
<p>or maybe as a new stage before the img data is written.</p>
<p><br>
</p>
<p>What I don't yet understand is the idea that a smaller </p>
<p>polygon is more important. Do you have examples for that,</p>
<p>esp. cases where shapes do only partially overlap?<br>
</p>
<p><br>
</p>
<p>Gerd<br>
</p>
</div>
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><span class=""><b>Von:</b> mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag von Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>><br>
</span><b>Gesendet:</b> Mittwoch, 27. Juli 2016 13:24:37<span class=""><br>
<b>An:</b> Development list for mkgmap<br>
<b>Betreff:</b> Re: [mkgmap-dev] Option to output polygons in size order</span></font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div class="gmail_extra"><br><div><div class="h5">
<div class="gmail_quote">On 27 July 2016 at 09:29, Gerd Petermann <span dir="ltr">
<<a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p>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<br>
</p>
<p>because we would have to write many more points. Think of a shape for "place=village" with hundreds of holes for each building</p>
<p>shape. Up to now we save the shape for the village and the shapes for the buildings. With cutting we have to calculate what</p>
<p>remains of the village shape, this would be a very complex shape with many holes, so it would have many points.</p>
<p>I don't think that would be a good idea.</p>
<p></p>
</blockquote>
</div>
<br>
</div></div></div><div><div class="h5">
<div class="gmail_extra">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.<br>
</div>
<div class="gmail_extra">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.<br>
<br>
</div>
<div class="gmail_extra">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.<br>
</div>
<div class="gmail_extra"><br clear="all">
<br>
-- <br>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>
<div>Felix Hartman - Openmtbmap.org & VeloMap.org<br>
</div>
Schusterbergweg 32/8<br>
</div>
<div>6020 Innsbruck<br>
</div>
</div>
Austria - Österreich</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

<br>_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div>Schusterbergweg 32/8<br></div><div>6020 Innsbruck<br></div></div>Austria - Österreich</div></div></div></div>
</div>