Poor man's line draw order - mkgmap dropping extended type lines ?
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
On Mon, Oct 5, 2009 at 4:11 PM, Ivan Kostoski <ivan.kostoski@gmail.com>wrote:
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 ?
Hello Again, I think I found where my extended-type lines disappear. They are simply not taken into account when estimating subdivision size, i.e: MapArea.java, lines 389-394 private void addSize(MapElement p, int[] sizes, int kind) { -> if(p.hasExtendedType()) { -> // not applicable for elements with extended types -> return; -> } So subdivisions end up too big (and are not drawn correctly) if there are a lot of extended-type elements. I commented out above lines in MapArea.java, rebuilt mkgmap (r1274) and seems to work, i.e. extended lines are no longer dropped in i.e. MapSource. I am not sure if I am breaking anything else, so please, somebody who understands the code and implications more, please check this. Thanks. Ivan.
Hello Ivan,
I think I found where my extended-type lines disappear. They are simply not taken into account when estimating subdivision size, i.e:
MapArea.java, lines 389-394
private void addSize(MapElement p, int[] sizes, int kind) {
-> if(p.hasExtendedType()) { -> // not applicable for elements with extended types -> return; -> }
So subdivisions end up too big (and are not drawn correctly) if there are a lot of extended-type elements. I commented out above lines in MapArea.java, rebuilt mkgmap (r1274) and seems to work, i.e. extended lines are no longer dropped in i.e. MapSource.
I am not sure if I am breaking anything else, so please, somebody who understands the code and implications more, please check this.
Extended type elements are not stored in the subdivision in the same manner as the non-extended elements so it is not appropriate to take their sizes into account in the same way as the elements with non-extended types. However, there could well be some limit to the amount of extended type elements that a subdivision has. The offsets and sizes are 32 bit but that doesn't mean to say you can have huge amounts of those elements in a single subdivision. I could introduce some threshold that would cause a subdivision to be split if the extended type elements are larger than that. Cheers, Mark
On Wed, Oct 14, 2009 at 3:40 PM, Mark Burton <markb@ordern.com> wrote:
I could introduce some threshold that would cause a subdivision to be split if the extended type elements are larger than that.
I will try to play with small-area osm contour file (as lines are usually ordered by elevation) and map them via style to extended lines. There will be no subdivision split as there are no other elements that will cause it. Last lines drawn (i.e. certain elevation) would indicate certain threshold. I will inform you what it turns out. Thanks in advance. Ivan
Hi Ivan,
I will try to play with small-area osm contour file (as lines are usually ordered by elevation) and map them via style to extended lines. There will be no subdivision split as there are no other elements that will cause it. Last lines drawn (i.e. certain elevation) would indicate certain threshold. I will inform you what it turns out.
You could do that but what would probably be less effort for you is to wait until this evening when I can supply a patch that will split the subdivision when the amount of extended type elements is larger than some threshold and then you can just vary the threshold to see what works and what doesn't. Cheers, Mark
Hi Ivan, It took me a little longer than expected (as I decided to revamp what was there) but I have a patch for you to try (attached). This limits the size of the extended type elements to 32KB for each of the points/lines/shapes. I have no idea if that is a sensible limit but you can alter it by changing these lines in MapSplitter.java: // maximum allowed amounts of points/lines/shapes with extended types private static final int MAX_XT_POINTS_SIZE = 0x8000; private static final int MAX_XT_LINES_SIZE = 0x8000; private static final int MAX_XT_SHAPES_SIZE = 0x8000; I hope it solves the problem. Mark
On Wed, Oct 14, 2009 at 9:57 PM, Mark Burton <markb@ordern.com> wrote:
// maximum allowed amounts of points/lines/shapes with extended types private static final int MAX_XT_POINTS_SIZE = 0x8000; private static final int MAX_XT_LINES_SIZE = 0x8000; private static final int MAX_XT_SHAPES_SIZE = 0x8000;
I hope it solves the problem.
Mark
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mark, I does immediately solve the problem. I played a bit with increasing the above values and I started receiving 'holes' in the 'contour test' at highest zoom (resolution 24) after 0x1ff00 (i.e. 0x2ff00). So I backed off and left it at 0xff00, to be safe, and now it works fine with both my test file and actual map i was trying to create (i.e. I can't notice anything missing at various zoom levels). Thank you very much! Ivan
Hi Ivan,
I does immediately solve the problem. I played a bit with increasing the above values and I started receiving 'holes' in the 'contour test' at highest zoom (resolution 24) after 0x1ff00 (i.e. 0x2ff00). So I backed off and left it at 0xff00, to be safe, and now it works fine with both my test file and actual map i was trying to create (i.e. I can't notice anything missing at various zoom levels).
Thank you very much!
That's good news. So if I set all three MAX_XT_? levels to 0xff00, that should be OK for you? Also, what did you do your testing with? mapsource or a real GPS? Cheers, Mark
On Thu, Oct 15, 2009 at 12:35 AM, Mark Burton <markb@ordern.com> wrote:
So if I set all three MAX_XT_? levels to 0xff00, that should be OK for you?
Also, what did you do your testing with? mapsource or a real GPS?
Hi Mark, I tested mostly with MapSource but from previous experience, behavior is consistent (i.e. when things start to disappear) with at least Garmin Mobile XT. I tested today my map with Garmin Mobile XT and everything seems to be in place so MAX_XT_* values of 0xff00 should be safe and not cause too much unnecessary subdivisions I hope. I know this is rare case (a lot of extended lines) but simple test is mapping of contour lines to 0x10105 (instead of 0x20-0x22) which is also behaves like contour line. This now works fine. I see you already committed the patch, so Thank You again. Kind regards, Ivan
Hi Ivan,
I tested mostly with MapSource but from previous experience, behavior is consistent (i.e. when things start to disappear) with at least Garmin Mobile XT. I tested today my map with Garmin Mobile XT and everything seems to be in place so MAX_XT_* values of 0xff00 should be safe and not cause too much unnecessary subdivisions I hope. I know this is rare case (a lot of extended lines) but simple test is mapping of contour lines to 0x10105 (instead of 0x20-0x22) which is also behaves like contour line. This now works fine.
Very good. Even with the new limits in place, you won't get many subdivisions compared to what you would have if there was lots of POIs, lines, shapes so don't worry about that.
I see you already committed the patch, so Thank You again.
You're welcome. Cheers, Mark
participants (2)
-
Ivan Kostoski -
Mark Burton