<div dir="ltr"><div>That is not really a good approach. Basecamp orders the polygons opposite to most gps devices. So it will still be broken.<br><br><br></div>There is however a proper way to do - but that would be much much more complicated: Create a list of polygons that may not overlap (in the style-file). Then if mkgmap finds that 2 of these polygons do overlap - mkgmap should cut out the smaller polygon shape from the bigger. Basically the result of that approach would mimic how a Mapnik map looks in this case. Still the real solution however would be to fix the underlying OSM data. I have no clue how code and time intensive the "mimic Mapnik" approach would be, but everything else won't really solve much.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 July 2016 at 20:42, 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 dir="ltr">
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Ticker,</p>
<p><br>
</p>
<p>with the current algo the order is either "unpredictable" or <br>
</p>
<p>the order in the input file (osm.pbf is typically sorted by id).</p>
<p>This depends on the --preserve-element-order</p>
<p>If I see this right this order will have an influence on the result</p>
<p>of the so-called shape merger which tries to combine shapes <br>
</p>
<p>with similar attributes.<br>
</p>
<p>I still don't understand why the size should matter, but it should</p>
<p>be easy to add a sort after the line</p>
<p><span>shapes = mergedShapes; </span></p>
<p>in MapBuilder.java</p>
<p><br>
</p>
<p>I don't have the time today, so try on your own or wait a little</p>
<p>for a patch .<br>
</p>
<p><br>
</p>
<p><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 Ticker Berkin <<a href="mailto:rwb-mkgmap@jagit.co.uk" target="_blank">rwb-mkgmap@jagit.co.uk</a>><br>
</span><b>Gesendet:</b> Sonntag, 24. Juli 2016 20:23:41<span class=""><br>
<b>An:</b> <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<b>Betreff:</b> Re: [mkgmap-dev] Option to output polygons in size order</span></font>
<div> </div>
</div>
</div><div><div class="h5">
<font size="2"><span style="font-size:10pt">
<div>Hi Gerd<br>
<br>
Looking at the meaning of the sub-division, this looks like just the<br>
place to try and order the polygons by size! What governs the order<br>
they appear in at the moment? The size should be the full size of the<br>
individual polygon.<br>
<br>
Concerning the new thread "Why do we render place=island polygons in<br>
the default style", I have used "place=island & size_of() < 1000000" to<br>
get around the major problem but it seemed a bit arbitrary, and when I<br>
found other examples where, just sometimes, large polygons mask all<br>
features within I thought there must be a more general solution<br>
<br>
Ticker<br>
<br>
On Sun, 2016-07-24 at 00:<a href="tel:05%20-0700" value="+4350700" target="_blank">05 -0700</a>, Gerd Petermann wrote:<br>
> Hi Ticker,<br>
> <br>
> Ticker Berkin wrote<br>
> > I'd understood and hoped that, for areas with the same level it<br>
> > rendered areas in file order, and I see on my device it<br>
> > overwriting,<br>
> > sometimes woods with island, sometimes the other way around,<br>
> > depending<br>
> > on, I presumed, the input ordering. I see the exactly the same<br>
> > overwriting effect zooming in or scrolling in any direction.<br>
> > <br>
> > What is the scale of the 'sub areas' you mention?<br>
> <br>
> I should have said sub division , and they have no specific scale.<br>
> They are used to group nearby elements, and they have several limits<br>
> like "not more than 255 points and not more than 255 lines in one sub<br>
> div"<br>
> For details see first the imgformat-1.0.pdf from Mechalas:<br>
> <a href="http://sourceforge.net/projects/garmin-img/files/OldFiles/imgformat.p" target="_blank">
http://sourceforge.net/projects/garmin-img/files/OldFiles/imgformat.p</a><br>
> df/download<br>
> Other sources:<br>
> <a href="http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format" target="_blank">
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format</a><br>
> (which has more links at the end)<br>
> <br>
> Reg. the British Islands polygon: If I got that right this is the<br>
> very complex mp-relation <br>
> <a href="https://www.openstreetmap.org/relation/6038068" target="_blank">https://www.openstreetmap.org/relation/6038068</a><br>
> (don't use the link, the thing is too complex)<br>
> It was added 2016-03-09 so maybe the problem is rather new and nobody<br>
> noticed it. I think it makes no sense to render that polygon, the<br>
> rules<br>
> in the default style should be changed to check the <br>
> area_size() for place=island so that large polygons are ignored.<br>
> I'll try to find a reasonable value.<br>
> <br>
> Gerd<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> --<br>
> View this message in context: <a href="http://gis.19327.n5.nabble.com/Option-t" target="_blank">
http://gis.19327.n5.nabble.com/Option-t</a><br>
> o-output-polygons-in-size-order-tp5878989p5879011.html<br>
> Sent from the Mkgmap Development mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> mkgmap-dev mailing list<br>
> <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
</div>
</span></font>
</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>