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