<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>here is a patch that contains my latest findings to fix <br>
</p>
<p>the problems reg. "preserved" points plus the experimental code for the sorting,
<br>
</p>
<p>after applying the patch to r3683 see MapBuilder line 1123 and below.</p>
<p><br>
</p>
<p>I still want to fix minor problems with the overview map,</p>
<p>that's why I did not yet publish the patch.</p>
<p><br>
</p>
<p>Gerd<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> Mittwoch, 27. Juli 2016 11:57:17<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 all<br>
<br>
Gerd, do you have a patch I can try - I have some examples where this<br>
should fix things.<br>
<br>
I've started to look at the code and, regardless of --preserve-element<br>
order, mkgmap will chop up and change the processing order of polygon,<br>
relating to overlap, inclusion, bounding box and multi-polygons.<br>
<br>
The relevant code is in ./mkgmap/reader/osm/MultiPolygonRelation.java<br>
<br>
I can't work out all of what it is doing, but it<br>
does seem to have bits that work out a hierarchy of polygon<br>
inclusion/overlap. I suspect that multi-polygons and maybe overlaps<br>
sometimes cause this to process a contained simple polygon before<br>
processing one that contains it.<br>
<br>
My idea of sorting by size was to avoid trying to calculate this<br>
inclusion hierarchy - a polygon can't contained a larger one!<br>
<br>
I don't think I'd like to touch any code in MultiPolyonRelation, so I<br>
still think the best solution is sorting somewhere in Mapbuilder, after<br>
area splitting. <br>
<br>
Ticker<br>
<br>
On Wed, 2016-07-27 at 07:29 +0000, Gerd Petermann wrote:<br>
> Hi Felix,<br>
> <br>
> reg. the idea of "cutting out overlaps": I guess it would consume<br>
> quite a lot of CPU and it would heavily increase the img size<br>
> because we would have to write many more points. Think of a shape for<br>
> "place=village" with hundreds of holes for each building<br>
> shape. Up to now we save the shape for the village and the shapes for<br>
> the buildings. With cutting we have to calculate what<br>
> remains of the village shape, this would be a very complex shape with<br>
> many holes, so it would have many points.<br>
> I don't think that would be a good idea.<br>
> <br>
> reg. sorting by size: I've not noticed any visible change in Basecamp<br>
> or on my Oregon, so I don't think this is a solution.<br>
> <br>
> I looked at maps produced by Garmin and 1st got the impression that<br>
> they are sorted by type, highest types coming first,<br>
> but I also found exceptions. Don't know if this means that the order<br>
> is not important or if there is a complex rules behind this.<br>
> <br>
> Gerd<br>
> Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag<br>
> von Felix Hartmann <extremecarver@gmail.com><br>
> Gesendet: Sonntag, 24. Juli 2016 21:40:47<br>
> An: Development list for mkgmap<br>
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order<br>
> <br>
> That is not really a good approach. Basecamp orders the polygons<br>
> opposite to most gps devices. So it will still be broken.<br>
> <br>
> <br>
> There is however a proper way to do - but that would be much much<br>
> more complicated: Create a list of polygons that may not overlap (in<br>
> the style-file). Then if mkgmap finds that 2 of these polygons do<br>
> overlap - mkgmap should cut out the smaller polygon shape from the<br>
> bigger. Basically the result of that approach would mimic how a<br>
> Mapnik map looks in this case. Still the real solution however would<br>
> be to fix the underlying OSM data. I have no clue how code and time<br>
> intensive the "mimic Mapnik" approach would be, but everything else<br>
> won't really solve much.<br>
> <br>
> On 24 July 2016 at 20:42, Gerd Petermann <<br>
> GPetermann_muenchen@hotmail.com> wrote:<br>
> > Hi Ticker,<br>
> > <br>
> > with the current algo the order is either "unpredictable" or <br>
> > the order in the input file (osm.pbf is typically sorted by id).<br>
> > This depends on the --preserve-element-order<br>
> > If I see this right this order will have an influence on the result<br>
> > of the so-called shape merger which tries to combine shapes <br>
> > with similar attributes.<br>
> > I still don't understand why the size should matter, but it should<br>
> > be easy to add a sort after the line<br>
> > shapes = mergedShapes; <br>
> > in MapBuilder.java<br>
> > <br>
> > I don't have the time today, so try on your own or wait a little<br>
> > for a patch .<br>
> > <br>
> > <br>
> > Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag<br>
> > von Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> > Gesendet: Sonntag, 24. Juli 2016 20:23:41<br>
> > An: mkgmap-dev@lists.mkgmap.org.uk<br>
> > Betreff: Re: [mkgmap-dev] Option to output polygons in size order<br>
> > <br>
> > Hi Gerd<br>
> > <br>
> > Looking at the meaning of the sub-division, this looks like just<br>
> > 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<br>
> > the<br>
> > individual polygon.<br>
> > <br>
> > Concerning the new thread "Why do we render place=island polygons<br>
> > in<br>
> > the default style", I have used "place=island & size_of() <<br>
> > 1000000" to<br>
> > get around the major problem but it seemed a bit arbitrary, and<br>
> > 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<br>
> > scale.<br>
> > > They are used to group nearby elements, and they have several<br>
> > limits<br>
> > > like "not more than 255 points and not more than 255 lines in one<br>
> > 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/imgform">
http://sourceforge.net/projects/garmin-img/files/OldFiles/imgform</a><br>
> > at.p<br>
> > > df/download<br>
> > > Other sources:<br>
> > > <a href="http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_For">
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_For</a><br>
> > mat<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<br>
> > 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: <br>
> > <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<br>
> > 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>
> > <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>
> <br>
> <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>