[mkgmap-dev] Poor man's line draw order - mkgmap dropping extended type lines ?

Mon Oct 5 15:11:01 BST 2009

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20091005/ea14de77/attachment.html 