<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="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>When i see any errors they are consistent, by consistent I mean, the final result is always the same, whatever the visible error is.
<br>
</p>
<p><br>
</p>
<p>when I see them, I check them out on OSM, to see how things are related on there.</p>
<p><br>
</p>
<p>There are some tricky ones, and I am not sure what the "best practice" approach should be,.</p>
<p><br>
</p>
<p>Imagine a residential area, within that area is a golf course, on the golf course there are bunkers, also a lake and in the middle of the lake is an island which has a wood on it, and a pond and also more sand( bunkers ), I am not sure what the relationships
on OSM are meant to be, but from what I have seen that is where most of the problems lie, it is a lack of that consistent approach that causes the problems,</p>
<p><br>
</p>
<p>Regards</p>
<p><br>
</p>
<p>Gary<br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>From:</b> mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on behalf of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
<b>Sent:</b> 24 July 2016 17:59<br>
<b>To:</b> mkgmap-dev@lists.mkgmap.org.uk<br>
<b>Subject:</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 Gary<br>
<br>
I wasn't proposing to change priority of anything or make rendering<br>
priority lists, just to change the order of polygons in the output<br>
file. I don't see that this would make any difference to the map size.<br>
<br>
You mention the "existing system" and the occasional problems you find<br>
when you have to correct the OSM data. How does this system work<br>
correctly most of the time, showing, say, lakes in marshland correctly,<br>
except, just occasionally, the rendering of the lake flashes briefly<br>
before being hidden by the rendering of the marshland.<br>
<br>
Ticker<br>
<br>
On Sun, 2016-07-24 at 05:44 +0000, Gary Bamford wrote:<br>
> Hi Ticker.<br>
> <br>
> I have been think about this, and changing the priority to be based<br>
> on polygon size would not only slowdown the gps rendering it would<br>
> also increase the memory size of the final map. I am also not sure it<br>
> would work correctly.<br>
> <br>
> Imagine a scenario whereby you have a series of partially overlapping<br>
> polygons, with some polygons fully inside another polygon, some of<br>
> the overlapping polygons could be the same size, but given they<br>
> aren't using size as a guide you would end up having to reference<br>
> each polygon individually in a rendering priority list, this could<br>
> easily end up being a massive list, taking a huge amount of time to<br>
> process.<br>
> <br>
> I do think the existing system works, but I also know that some of<br>
> the existing base data on OSM needs to be corrected. so that multi<br>
> polygons have been set up correctly.<br>
> <br>
> All my maps are of the UK, and I have no real problems with polygons,<br>
> except for where I find the base data to be incorrect, and to find<br>
> these errors, you have to go them them individually. I am sure Gerd<br>
> will correct me on this, but if you don't specify a typ/style file<br>
> then it will use the default typ/style. <br>
> <br>
> A very useful change in mkgmap would be to indicate a a multipolygon<br>
> that would never be visible due to draw order and or bad multipolygon<br>
> data, but this is more about data integrity than it is about<br>
> rendering a map. So I am not sure if it fits within the mkgmap remit.<br>
> <br>
> Regards<br>
> <br>
> Gary<br>
> <br>
> <br>
> <br>
> <br>
> From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on behalf<br>
> of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> Sent: 23 July 2016 19:44<br>
> To: mkgmap-dev@lists.mkgmap.org.uk<br>
> Subject: Re: [mkgmap-dev] Option to output polygons in size order<br>
> <br>
> Hi Gary<br>
> <br>
> Experimenting with my device, using the in-build area representations<br>
> (ie no TYP section in my map) it seems as if different areas don't<br>
> have<br>
> a particular priority; it just draws things as they arrive,<br>
> overwriting<br>
> as it goes along.<br>
> <br>
> What I'm hoping for, as a new option, is that (individual) polygons<br>
> are<br>
> output in size order, big to small. Then all your examples work<br>
> perfectly, regardless of any order that OSM generates.<br>
> <br>
> I'm just guessing that splitter effects the order of polygons that<br>
> cross tile boundaries, because the big islands in the input map that<br>
> are getting split mask all the land features, but for other islands I<br>
> am getting greenery, lakes...<br>
> <br>
> Ticker<br>
> <br>
> On Sat, 2016-07-23 at 18:52 +0000, Gary Bamford wrote:<br>
> > Hi Ticker,<br>
> > <br>
> > The draw order dies have an effect, the Legend is a pretty slow<br>
> > device ( I can see mine drawing and then overwriting ), but this<br>
> can<br>
> > only work correctly if the data on OSM is correct, the Multi<br>
> polygons<br>
> > is the base effect, if this is wrong, then it doesn't matter what<br>
> the<br>
> > Garmin device tries to do,.<br>
> > <br>
> > let's assume the multi polygons are not correct, and they don't<br>
> refer<br>
> > to each other.<br>
> > <br>
> > Think about it, imagine a big wood and within it a lake, lets say<br>
> the<br>
> > wood is defined by an area, and so is the lake, in this case you<br>
> > would want the lake to have a higher draw order than the forest,.<br>
> > <br>
> > now imagine a lake with a forest in the middle of it, in this case<br>
> > you would want the forest to have a higher draw order than the<br>
> lake.<br>
> > <br>
> > Basically you can't have both, the multiploygon has to be correct<br>
> > with it's relationships,.<br>
> > <br>
> > if the OSM information is correct draw order works fine.<br>
> > <br>
> > Not sure what you mean by splitter delaying things.<br>
> > <br>
> > Gary<br>
> > <br>
> > From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on behalf<br>
> > of Ticker Berkin <rwb-mkgmap@jagit.co.uk><br>
> > Sent: 23 July 2016 18:42<br>
> > To: mkgmap-dev@lists.mkgmap.org.uk<br>
> > Subject: Re: [mkgmap-dev] Option to output polygons in size order<br>
> > <br>
> > Hi<br>
> > <br>
> > I'm sure that the order in the map has some effect on the Legend;<br>
> as<br>
> > I<br>
> > zoom in or scroll across areas with greenery they appear briefly<br>
> and<br>
> > are then cleared, by the island polygon that covers everything, as<br>
> it<br>
> > starts drawing the ways...<br>
> > <br>
> > Generally, the openStreetMap data order is OK, but I have found<br>
> > examples where there are lakes, within the same meadow, that occur<br>
> > both<br>
> > before and after it. Not sure if this is related to multi-polygons,<br>
> > but<br>
> > if sorting was performed on the individual polygons there wouldn't<br>
> be<br>
> > any problem.<br>
> > <br>
> > Also it looks like splitter is delaying the British Isles (and<br>
> other<br>
> > large) polygons because they occurs on multiple tiles.<br>
> > <br>
> > Typ _drawOrder cannot solve the problem when there are nested<br>
> > polygons<br>
> > with more that one instance of the same type, whereas drawing outer<br>
> > ones first solves it completely.<br>
> > <br>
> > I have seen mention somewhere that areas with the same _draworder<br>
> are<br>
> > rendered in file order<br>
> > <br>
> > Ticker<br>
> > <br>
> > On Sat, 2016-07-23 at 17:17 +0000, Gary Bamford wrote:<br>
> > > Hi Ticker/Gerd<br>
> > > <br>
> > > The draw order does work for the Legend ( it is the device I have<br>
> > ).<br>
> > > I also came across problems with multiple polygons, the problem<br>
> can<br>
> > > be one of several things, not all multi polygons are correct on<br>
> > > openstreetmap, I cam across one today "fairhaven lake" golf<br>
> > course,<br>
> > > was hiding, due to draw order, but the problem was, it is<br>
> contained<br>
> > > within a polygon for a residential area, so I had to change the<br>
> > data<br>
> > > on openstreetmap, to make it an inner polygon. when i download<br>
> the<br>
> > > new OSM data I expect it to work correctly.<br>
> > > <br>
> > > if the polygons are set correctly on openstreetmap, then draw<br>
> order<br>
> > > will will as you expect. <br>
> > > <br>
> > > Gary<br>
> > > <br>
> > > From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> on<br>
> behalf<br>
> > > of Gerd Petermann <GPetermann_muenchen@hotmail.com><br>
> > > Sent: 23 July 2016 17:05<br>
> > > To: Development list for mkgmap<br>
> > > Subject: Re: [mkgmap-dev] Option to output polygons in size order<br>
> > > <br>
> > > Hi Ticker,<br>
> > > <br>
> > > are you sure that the order matters? I've never heard that theory<br>
> > > and I would be surprised when that is true.<br>
> > > The normal way to handle the draw order is to use a typ file, not<br>
> > > sure<br>
> > > if this works on your device, but it seems to work well for<br>
> others.<br>
> > > <br>
> > > Gerd<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: Samstag, 23. Juli 2016 18:45:59<br>
> > > An: mkgmap development<br>
> > > Betreff: [mkgmap-dev] Option to output polygons in size order<br>
> > > <br>
> > > Hi<br>
> > > <br>
> > > I'm using splitter-r437/mkgmap-r3676 to make a map for Etrex<br>
> Legend<br>
> > > from british-isles-latest.osm.pbf from geofabric.de.<br>
> > > <br>
> > > Using "default" style and not using a TYP file, no land features<br>
> > > (woods,marsh,green) show because an island polygon for "British<br>
> > > Isles"<br>
> > > is rendered near the end, on top of everything else. I guess that<br>
> > the<br>
> > > Etrex has all area types as the same draworder and renders them<br>
> in<br>
> > > file<br>
> > > order.<br>
> > > <br>
> > > I presume I could use TYP / _DrawOrder to change this behaviour<br>
> > > slightly but I keep finding examples of woods in islands in lakes<br>
> > in<br>
> > > marsh in islands etc etc, so _DrawOrder can't solve the problem.<br>
> > > <br>
> > > What would make everything show correctly would be to output<br>
> > polygons<br>
> > > in size order, largest to smallest. Could this be done easily?<br>
> > either<br>
> > > in splitter then --preserve-element-order, or in mkgmap, possibly<br>
> > > after<br>
> > > style processing because there will be a lot fewer polygons at<br>
> this<br>
> > > point.<br>
> > > <br>
> > > Regards<br>
> > > Ticker Berkin<br>
> > > <br>
> > > _______________________________________________<br>
> > > mkgmap-dev mailing list<br>
> > > mkgmap-dev@lists.mkgmap.org.uk<br>
> > > <a id="LPlnk317423" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a>
<div style="margin-bottom: 20px; overflow: auto; width: 100%; text-indent: 0px;" id="LPBorder_GT_14697111496250.5339547740801199">
<table style="width: 90%; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);" id="LPContainer_14697111496170.07073034632798558" cellspacing="0">
<tbody>
<tr style="border-spacing: 0px;" valign="top">
<td colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;" id="TextCell_14697111496190.1326677741133344">
<div id="LPRemovePreviewContainer_14697111496190.41799215305259474"></div>
<div style="top: 0px; color: rgb(0, 75, 139); font-weight: 400; font-size: 21px; font-family: "wf_segoe-ui_light","Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; line-height: 21px;" id="LPTitle_14697111496190.33671279344155436">
<a target="_blank" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" style="text-decoration: none;" id="LPUrlAnchor_14697111496210.9943013654315342">mkgmap-dev Info Page</a></div>
<div style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: "wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size: 14px; line-height: 14px;" id="LPMetadata_14697111496220.029341896863507078">
www.mkgmap.org.uk</div>
<div style="display: block; color: rgb(102, 102, 102); font-weight: 400; font-family: "wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;" id="LPDescription_14697111496230.4004600278121041">
This is a general development list for mkgmap. To see the collection of prior postings to the list, visit the mkgmap-dev Archives.</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
> mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> This is a general development list for mkgmap. To see the collection<br>
> of prior postings to the list, visit the mkgmap-dev Archives.<br>
> <br>
> > mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> > This is a general development list for mkgmap. To see the<br>
> collection<br>
> > of prior postings to the list, visit the mkgmap-dev Archives.<br>
> > <br>
> > > mkgmap-dev Info Page <a href="http://www.mkgmap.org.uk">www.mkgmap.org.uk</a><br>
> > > This is a general development list for mkgmap. To see the<br>
> > collection<br>
> > > of prior postings to the list, visit the mkgmap-dev Archives.<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>
> _______________________________________________<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></div>
</div>
</body>
</html>