<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=DE link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-GB>My suggestion would be to have something like a layer command for the style language.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Example:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>seamark:type=fairway [0x10702 resolution 20 layer 3]<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>So polygons could be drawn sorted by layer for controlling draw-order on devices not supporting TYP.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Remember: All these recent devices need maps without TYP:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><a href="https://buy.garmin.com/en-US/US/cOnTheWater-c519-p1.html">https://buy.garmin.com/en-US/US/cOnTheWater-c519-p1.html</a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB>Currently it is even very problematic to draw just simple buildings on those devices. Not to mention water depth areas or intertidal zones.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-GB>Jürgen<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-GB><o:p> </o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>Von: </b><a href="mailto:rwb-mkgmap@jagit.co.uk">Ticker Berkin</a><br><b>Gesendet: </b>Freitag, 28. Oktober 2016 16:31<br><b>An: </b><a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br><b>Betreff: </b>Re: [mkgmap-dev] patch to write polygons in decreasing order</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I maintain that there isn't a universal _draworder that will render a</p><p class=MsoNormal>map from OpenStreetMap data on the Garmin device in a similar way to</p><p class=MsoNormal>how it is shown by www.openStreetMap.org - there are so many examples</p><p class=MsoNormal>of nested areas of pasture, woods, grass, playgrounds, etc in any order</p><p class=MsoNormal>of overlaying.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You could say that these should be expressed as inner/outer multi</p><p class=MsoNormal>-polygon relationships, but this is rarely done; it would be a lot of</p><p class=MsoNormal>effort and the resultant system would be very unwieldy. It would have</p><p class=MsoNormal>to be taken to its logical conclusion where, for any area, there is</p><p class=MsoNormal>only one (non-transparent) representation. This is because, even for</p><p class=MsoNormal>multi-polygon relationships, OpenStreetMap has the concept of the</p><p class=MsoNormal>background behind the outer polygon that shows in the inner holes. This</p><p class=MsoNormal>background seems to considered as such simply by being bigger than than</p><p class=MsoNormal>the area in question.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>If the display represention is reduced to a single layer, then</p><p class=MsoNormal>_draworder becomes irrelevant!</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On Sun, 2016-10-23 at 09:02 -0700, nwillink wrote:</p><p class=MsoNormal>> OK</p><p class=MsoNormal>> </p><p class=MsoNormal>> Point taken.</p><p class=MsoNormal>> </p><p class=MsoNormal>> There is a mystery about some if not most TOPO TYP files containing</p><p class=MsoNormal>> draworders which are not linked to polygon . </p><p class=MsoNormal>> </p><p class=MsoNormal>> Either they are left overs, which is very unusual, or they imply</p><p class=MsoNormal>> another</p><p class=MsoNormal>> purpose as yet undefined - the word container was used to describe</p><p class=MsoNormal>> such</p><p class=MsoNormal>> draworders but its unclear what they are grouping.</p><p class=MsoNormal>> </p><p class=MsoNormal>> </p><p class=MsoNormal>> </p><p class=MsoNormal>> --</p><p class=MsoNormal>> View this message in context: http://gis.19327.n8.nabble.com/patch-to</p><p class=MsoNormal>> -write-polygons-in-decreasing-order-tp5884038p5884816.html</p><p class=MsoNormal>> Sent from the Mkgmap Development mailing list archive at Nabble.com.</p><p class=MsoNormal>> _______________________________________________</p><p class=MsoNormal>> mkgmap-dev mailing list</p><p class=MsoNormal>> mkgmap-dev@lists.mkgmap.org.uk</p><p class=MsoNormal>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</p><p class=MsoNormal>_______________________________________________</p><p class=MsoNormal>mkgmap-dev mailing list</p><p class=MsoNormal>mkgmap-dev@lists.mkgmap.org.uk</p><p class=MsoNormal>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>