Hi,

a few more remarks:
1) the relation processing also adds ways (those with the fake ids like 4611686018427387918). These are added after the normal OSM ways and the order is
determined by algorithmns.
2) another possible solution might be to sort the lines by type before they are written to the img file. This would require an additional file giving the draw order of line types.

Gerd



From: gpetermann_muenchen@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Wed, 8 May 2013 10:09:21 +0200
Subject: [mkgmap-dev] order of lines / roads

Hi all,

beginning with r2448 I've committed changes which had an influence on the order of lines and and roads.
This was not intended, just a side effect. I was not aware that this has an effect on overlaid objects, see e.g.
http://gis.19327.n5.nabble.com/Commit-r2567-roads-first-v1-patch-Make-sure-that-roads-are-placed-before-other-lines-tp5756715p5759768.html

The problems occurs because we have to colllect all roads first and separate them from other lines.

Up to r2448 the option --preserve-element-order probably worked as expected: all objects were processed by the style in the
order of appearance and they were also written in this order.
Since r2448 the roads were either all written after the other lines or before. The "mkgmap:set_unconnected_type" feature is also
likely to mix the order.
Polygons were never effected by any of these changes.

It looks quite complicated to implement the behaviour of r2448 again (also because the housenumber code needs the separation),
so I wonder if it is acceptable to implement --preserve-element-order like this:
we keep the order of roads and we keep the order of other ways, and we make sure that roads are added
after the other ways. It would also be possible to add an option so that we add roads first if that is needed.

Is this limitation a problem for anybody?

Gerd






_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev