mkgmap:drawLevel and --order-by-decreasing-area
Here is a patch that implements mkgmap:drawLevel It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others. The higher the value, the later the polygon is written and hence should show over other areas. Values range from 1 to 100, 1..50 will be larger than any natural area and so output earlier. 51..100 will be smaller and written later. So, if you wanted the standard sea polygons to show, rather than any mapped area beyond the coastline, could have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=99 } [0x32 resolution 10] The default for sea is drawLevel=2 (drawLevel 1 might be needed for the map background / 0x4b). Nothing else has a default and so behaves as if between 50 and 51. The Garmin device will still respect any in-build or TYP specified _draworder. With --order-by-decreasing-area it works best if everything has the same _draworder. If your Garmin device has strange rules, like not showing City (0x01..0x03) or having green areas (0x14..0x21) at a lower _draworder than most other things, consider a TYP file giving 0x01..0x55 the same value (1) except 0x4b with a lower value (0). Ticker
Hi Ticker, have you tested it? I think sea object covers most of other polygons, regardless of sort order inside img. IMO there is a default draw order for maps without TYP and your patch can have only a limited application, within single level of default draw order. And this could even depend on device. -- Best regards, Andrzej
Hi Andrzej I've tested it on my Garmin Etrex Legend. As I said, it needs a TYP file giving equal _drawOrder to almost everything - except I forgot to mention that I think the in-build behavior of the Legend for Sea/0x32 is to show it on top, but this is fixed by TYP/_drawOrder, behaving as expected. Otherwise I agree with everything you say. Ticker On Tue, 2016-11-15 at 15:29 +0100, Andrzej Popowski wrote:
Hi Ticker,
have you tested it?
I think sea object covers most of other polygons, regardless of sort order inside img. IMO there is a default draw order for maps without TYP and your patch can have only a limited application, within single level of default draw order. And this could even depend on device.
Actually there are very few types that have a non-standard built in draw order (especially within extended types). So the new function will work for most cases. And the built in draw order does not depend on device. I use Homeport PC software for testing, and even there draw order behaviour is exactly the same than on all my devices. Von: Andrzej Popowski IMO there is a default draw order for maps without TYP and your patch can have only a limited application, within single level of default draw order. And this could even depend on device. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, I've created a binary based on r3702: http://files.mkgmap.org.uk/download/313/mkgmap.jar I'd like to get more feedback on this patch. Gerd Ticker Berkin wrote
Here is a patch that implements mkgmap:drawLevel
It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others.
The higher the value, the later the polygon is written and hence should show over other areas. Values range from 1 to 100, 1..50 will be larger than any natural area and so output earlier. 51..100 will be smaller and written later.
So, if you wanted the standard sea polygons to show, rather than any mapped area beyond the coastline, could have:
natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=99 } [0x32 resolution 10]
The default for sea is drawLevel=2 (drawLevel 1 might be needed for the map background / 0x4b). Nothing else has a default and so behaves as if between 50 and 51.
The Garmin device will still respect any in-build or TYP specified _draworder. With --order-by-decreasing-area it works best if everything has the same _draworder. If your Garmin device has strange rules, like not showing City (0x01..0x03) or having green areas (0x14..0x21) at a lower _draworder than most other things, consider a TYP file giving 0x01..0x55 the same value (1) except 0x4b with a lower value (0).
Ticker
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
drawLevel_v2.patch (7K) <http://gis.19327.n8.nabble.com/attachment/5885926/0/drawLevel_v2.patch>;
-- View this message in context: http://gis.19327.n8.nabble.com/mkgmap-drawLevel-and-order-by-decreasing-area... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi all, Ticker Berkin wrote
It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others.
in fact it also overrides the value returned by the style function area_size(), I don't know if that is a good idea. @Ticker: I assume you used this trick to avoid a new field like skipSizeFilter in MapLine? Gerd -- View this message in context: http://gis.19327.n8.nabble.com/mkgmap-drawLevel-and-order-by-decreasing-area... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd The messing with the area happens after style processing so doesn't effect the result of the area_size() function. Ticker On Wed, 2016-11-16 at 23:00 -0700, Gerd Petermann wrote:
Hi all,
Ticker Berkin wrote
It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others.
in fact it also overrides the value returned by the style function area_size(), I don't know if that is a good idea. @Ticker: I assume you used this trick to avoid a new field like skipSizeFilter in MapLine?
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/mkgmap-d rawLevel-and-order-by-decreasing-area-tp5885926p5886043.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
Hi Ticker, Ticker Berkin wrote
The messing with the area happens after style processing so doesn't effect the result of the area_size() function.
you are right, sorry for the noise. Gerd -- View this message in context: http://gis.19327.n8.nabble.com/mkgmap-drawLevel-and-order-by-decreasing-area... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
rheinskipper1000＠gmx.de -
Ticker Berkin