[mkgmap-dev] patch to write polygons in decreasing order

Fri Oct 28 15:31:44 BST 2016

I maintain that there isn't a universal _draworder that will render a
map from OpenStreetMap data on the Garmin device in a similar way to
how it is shown by www.openStreetMap.org - there are so many examples
of nested areas of pasture, woods, grass, playgrounds, etc in any order
of overlaying.

You could say that these should be expressed as inner/outer multi
-polygon relationships, but this is rarely done; it would be a lot of
effort and the resultant system would be very unwieldy.  It would have
to be taken to its logical conclusion where, for any area, there is
only one (non-transparent) representation. This is because, even for
multi-polygon relationships, OpenStreetMap has the concept of the
background behind the outer polygon that shows in the inner holes. This
background seems to considered as such simply by being bigger than than
the area in question.

If the display represention is reduced to a single layer, then
_draworder becomes irrelevant!

On Sun, 2016-10-23 at 09:02 -0700, nwillink wrote:
> OK
> 
> Point taken.
> 
> There is a mystery about some if not most TOPO TYP files containing
> draworders which are not linked to polygon . 
> 
> Either they are left overs, which is very unusual, or they imply
> another
> purpose as yet undefined - the word container was used to describe
> such
> draworders but its unclear what they are grouping.
> 
> 
> 
> --
> View this message in context: http://gis.19327.n8.nabble.com/patch-to
> -write-polygons-in-decreasing-order-tp5884038p5884816.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev