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

Sat Oct 29 06:08:02 BST 2016

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

Again:
All marine devices ( https://buy.garmin.com/en-US/US/cOnTheWater-c519-p1.html ) do NOT read anything from your TYP file. TYP _draworder is simply ignored. Please give us a method of controlling draworder that works on all modern Garmin devices.

TYP _draworder only works on handhelds and automotive units!

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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20161029/93168c70/attachment.html>