Hello, Since at the moment it is not possible (not known how?) to do line draw order in .img/.typ file, I am trying to get around it. Basicly at least 0x10e00 - 0x10f1f lines have same draw order as far as Garmin is concerned, so i tried to use that with --preserve-element-order and it kind of works. On a good day, with small maps, it can do this: http://osm-mkd.vidi.mk/pics/uk-m4-m25.PNG Which is mapsource snapshot of very small map of UK M4/M25 interchange stack done with custom pre-processing of osm file (to order elements) and mkgmap. The same screen looks very similar (i.e. same draw order, same problems) on Garmin Mobile XT and I assume it will work on other GPSr. All drawn lines are extended types, including bridge lines, one-way overlays, etc... ordered in the osm file from lowest draw priority to highest (i.e. layers of bridges). Draw order works only with single color lines with no borders. If you want line border, you have to produce two lines, one for the border (wider, lower draw priority) and another one for the 'foreground' color. Garmin does the same drawing of two lines for each line with border but this disturbs order of elements in .img file so this type of lines cannot be used as than it is impossible to draw transparent bitmap lines over them (i.e. one-way arrows). Routable lines (i.e. 0x01-0x0b) have 'real' draw priority (both for border and foreground line) so it is irrelevant where they are in the .img file (relative to other lines) and they cannot be used with this method. However with bigger maps, lines go out-of-order (i.e. one-way overlay is drawn before the road-line) or are completely missing at various levels (resolution). In extreme case, when I added contour lines as extended types, i started missing residential roads, etc...Also some large polygons seem to disappear below certain resolution ? Pre-processing of osm file can only do so much. I assume that final ordering of elements in the .img file is done by mkgmap based on more things that order of appearance of elements in osm file. So I have several questions: - Is there any known garmin/mkgmap limit of how many extended lines (or polygons) can be in single level ? - Is there a way to tell (i.e. debug/info/warning) or influence when mkgmap drops lines or polygons from certain level of .img file ? - How strict is --preserve-element-order, i.e. what happens if line is internally split or nodes merged or is there anything that adds lines at the end of file ? - style/overlays ? Where are overlayed lines added (imediately after first line or at the end of file) ? - Is there any way to specifiy the style of the ends of the line (i.e. (no)rounded ends) into the img file. Garmin Mobile XT (in some cases, maybe Garmin bug) seems to draw rounded ends only on one side of the line (beginning or end, depending of line orientation) which will make some thing much simpler ? I don't know if this is possible/known-how-to in the .typ file ? And few proposals or feature requests: - Adding draworder statement in for each resulting line (i.e. [0x10e01 resolution x draworder y) - Sorting the elements based on that specified draworder before final .img output (instead of preserving element order of osm file) These features does not necessarily need to be compatible with --net or --route (i.e. either draworder processing or net/routing processing) as there is a way around that (mapsets) as we can use only extended type lines (or lines with same internal Garmin draworder) which are not routable anyway. This is more or less styling issue, so I guess it concerns mostly the style branch ? Thanks, Ivan