<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Hi Felix,</p>
<p><br>
</p>
<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><br>
</p>
<p>reg. sorting by size: I've not noticed any visible change in Basecamp or on my Oregon, so I don't think this is a solution.</p>
<p><br>
</p>
<p>I looked at maps produced by Garmin and 1st got the impression that they are sorted by type, highest types coming first,</p>
<p>but I also found exceptions. Don't know if this means that the order is not important or if there is a complex rules behind this.<br>
</p>
<p><br>
</p>
<p>Gerd<br>
</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>Von:</b> mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com><br>
<b>Gesendet:</b> Sonntag, 24. Juli 2016 21:40:47<br>
<b>An:</b> Development list for mkgmap<br>
<b>Betreff:</b> Re: [mkgmap-dev] Option to output polygons in size order</font>
<div> </div>
</div>
<div>
<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>
</div>
</body>
</html>