<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>Garmins approach to maps is layered, OSM is built on relationships, both have their flaws, and converting from relationships to layers is problematic at best.</p>
<p><br>
</p>
<p>Point me to an area you are having problems with and i will check it out to see what my set up shows,</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 <ticker@jagIT.co.uk><br>
<b>Sent:</b> 28 July 2016 16:41<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>
For my problem areas I'll look at the OSM relationships in exact detail<br>
- I'm only just working out how to do this.<br>
<br>
Judging by how OpenStreetMap.org displays an area with overlapping<br>
polygons not in a relationship, it is making a consistent choice about<br>
how to show them. I haven't been able to find anything in the OSM data<br>
structures that defines what hides what, but, since Gerd's patch to<br>
sort by size, I'm seeing a lot more that matches OpenStreetMap, but not<br>
completely.<br>
<br>
The type of scenario you describe could be specified with nested<br>
multi-polygon relationships (ie the hole/inner of one relationship is<br>
the outer of another relationship) but this would be complicated and<br>
error-prone and, when taken to its conclusion (eg every building<br>
punching a hole in its area, etc etc) would be totally unwieldy.<br>
<br>
Ticker<br>
<br>
On Thu, 2016-07-28 at 13:11 +0000, Gary Bamford wrote:<br>
> Hi Ticker.<br>
> <br>
> When i see any errors they are consistent, by consistent I mean, the<br>
> final result is always the same, whatever the visible error is. <br>
> <br>
> when I see them, I check them out on OSM, to see how things are<br>
> related on there.<br>
> <br>
> There are some tricky ones, and I am not sure what the "best<br>
> practice" approach should be,.<br>
> <br>
> Imagine a residential area, within that area is a golf course, on the<br>
> golf course there are bunkers, also a lake and in the middle of the<br>
> lake is an island which has a wood on it, and a pond and also more<br>
> sand( bunkers ), I am not sure what the relationships on OSM are<br>
> meant to be, but from what I have seen that is where most of the<br>
> problems lie, it is a lack of that consistent approach that causes<br>
> the problems,<br>
> <br>
> Regards<br>
> <br>
> Gary<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: 24 July 2016 17:59<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>
> 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<br>
> size.<br>
> <br>
> You mention the "existing system" and the occasional problems you<br>
> 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<br>
> 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<br>
> it<br>
> > would work correctly.<br>
> > <br>
> > Imagine a scenario whereby you have a series of partially<br>
> 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<br>
> 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<br>
> multipolygon<br>
> > that would never be visible due to draw order and or bad<br>
> 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<br>
> 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<br>
> 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<br>
> that<br>
> > are getting split mask all the land features, but for other islands<br>
> 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<br>
> 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<br>
> 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,<br>
> 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<br>
> occur<br>
> > > both<br>
> > > before and after it. Not sure if this is related to multi<br>
> -polygons,<br>
> > > but<br>
> > > if sorting was performed on the individual polygons there<br>
> 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<br>
> 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<br>
> 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<br>
> order<br>
> > > > <br>
> > > > Hi Ticker,<br>
> > > > <br>
> > > > are you sure that the order matters? I've never heard that<br>
> 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,<br>
> 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<br>
> 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<br>
> 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<br>
> lakes<br>
> > > in<br>
> > > > marsh in islands etc etc, so _DrawOrder can't solve the<br>
> 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,<br>
> 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="LPlnk649145" 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_14699729986660.6004062741217112">
<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_14699729986580.5247214577547173" 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_14699729986610.6397081416887438">
<div id="LPRemovePreviewContainer_14699729986610.2305588800975762"></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_14699729986610.7492799359659075">
<a target="_blank" href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" style="text-decoration: none;" id="LPUrlAnchor_14699729986630.9384309801627383">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_14699729986630.755146896649571">
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_14699729986650.6912837346495001">
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>
> > > > 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>
> _______________________________________________<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>