<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
        {margin-top:0;
        margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" 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 tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
<b>Gesendet:</b> Sonntag, 24. Juli 2016 20:23:41<br>
<b>An:</b> mkgmap-dev@lists.mkgmap.org.uk<br>
<b>Betreff:</b> Re: [mkgmap-dev] Option to output polygons in size order</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">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:05 -0700, 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">
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">
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">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">
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>
> mkgmap-dev@lists.mkgmap.org.uk<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
_______________________________________________<br>
mkgmap-dev mailing list<br>
mkgmap-dev@lists.mkgmap.org.uk<br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
</div>
</span></font>
</body>
</html>