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

Fri Oct 28 23:30:54 BST 2016

order-by-decreasing-area solves most of these problems.

I don't think the concept of layers in the style has any advantage over
TYP _draworder.

Concerning inter-tidal areas, with order-by-decreasing-area and equal
_draworder for all polygon types (except 0x4b, which needs to be lower)
it shows them. To get the sea to show up to the coast-line, give 0x32 a
higher _draworder than everything else. Alternatively another option
could be introduced that changes the presumed size of sea polygons from
bigger than everything else to smaller.

On Fri, 2016-10-28 at 16:47 +0200, rheinskipper1000 at gmx.de wrote:
> My suggestion would be to have something like a layer command for the
> style language.
>  
> Example:
> seamark:type=fairway [0x10702 resolution 20 layer 3]
>  
> So polygons could be drawn sorted by layer for controlling draw-order
> on devices not supporting TYP.
>  
> Remember: All these recent devices need maps without TYP:
> https://buy.garmin.com/en-US/US/cOnTheWater-c519-p1.html
> Currently it is even very problematic to draw just simple buildings
> on those devices. Not to mention water depth areas or intertidal
> zones.
>  
> Jürgen
>  
>  
> Von: Ticker Berkin
> Gesendet: Freitag, 28. Oktober 2016 16:31
> An: mkgmap-dev at lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] patch to write polygons in decreasing order
>  
> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>  
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev