<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>please note that the patch also contains a change to the style file.</p>
<p>If you compare results you should create one map with enabled sorting</p>
<p>and one without, don't compare with the output of r3683.</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 13:35:05<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>
Thanks for this. I've just tested it and a see quite a few land-use<br>
type features that I didn't see before, and changes in my suspect area<br>
but I still don't see the lake (for more than a fraction of a second) I<br>
was expecting.<br>
<br>
I'm going to compare some of what I see with how <a href="http://www.openStreetMap.org">
www.openStreetMap.org</a><br>
renders the same area - I know it shows the lake.<br>
<br>
Ticker<br>
<br>
On Wed, 2016-07-27 at 10:33 +0000, Gerd Petermann wrote:<br>
> Hi Ticker,<br>
> <br>
> here is a patch that contains my latest findings to fix <br>
> the problems reg. "preserved" points plus the experimental code for<br>
> the sorting, <br>
> after applying the patch to r3683 see MapBuilder line 1123 and below.<br>
> <br>
> I still want to fix minor problems with the overview map,<br>
> that's why I did not yet publish the patch.<br>
> <br>
> Gerd<br>
> Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag<br>
> von Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> Gesendet: Mittwoch, 27. Juli 2016 11:57:17<br>
> An: mkgmap-dev@lists.mkgmap.org.uk<br>
> Betreff: Re: [mkgmap-dev] Option to output polygons in size order<br>
> <br>
> 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<br>
> -element<br>
> order, mkgmap will chop up and change the processing order of<br>
> 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,<br>
> 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<br>
> 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<br>
> for<br>
> > the buildings. With cutting we have to calculate what<br>
> > remains of the village shape, this would be a very complex shape<br>
> 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<br>
> 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<br>
> 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<br>
> (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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> one<br>
> > > sub<br>
> > > > div"<br>
> > > > For details see first the imgformat-1.0.pdf from Mechalas:<br>
> > > > <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>
> > > > <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<br>
> 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,<br>
> 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<br>
> 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>
> _______________________________________________<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>