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
Danke für Deine Bemühungen, ich selbst bin leider nicht schlau genug, um
da mitreden zu können. Wundere mich nur, dass Anderen der Fehler bisher
nicht aufgefallen ist..
Thanks for your hint related java option - Xmx5000m. It is possible,
to load a 25 MB osm.pbf in JOSM. I see in JOSM, that
Hi Thomas,
Thomas Morgenstern wrote
> Hi gerd thanks for your tests. I am waiting for your solution...
I've found a few errors in splitter until now, but no solution so far. The
support of overlapping areas in split-file
is quite a brain teaser...
Gerd
--
View this message in context:
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
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
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
