- mkgmap-dev - The mkgmap lists

Commit: r1280: Now subdivides if space required by extended type elements is too big.
by svn commit 15 Oct '09

15 Oct '09

Version 1280 was commited by markb on 2009-10-15 10:18:10 +0100 (Thu, 15 Oct 2009) Now subdivides if space required by extended type elements is too big. Real size limits for extended type elements are unknown at this time. Starting with 0xff00 for each of points/lines/shapes which has been tested as OK. Includes general revamp of size estimating code in MapArea.

2 1

test
by Mark Burton 15 Oct '09

15 Oct '09

hello world

1 1

Poor man's line draw order - mkgmap dropping extended type lines ?
by Ivan Kostoski 15 Oct '09

15 Oct '09

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

2 9

All current mb patches committed to trunk
by Mark Burton 15 Oct '09

15 Oct '09

Given that they have had some amount of testing and no reported breakage, I have committed my recent gaggle of patches to trunk so that it becomes easier to build. Apologies in advance if anything is now messed up (worse than before!) Hopefully, Steve will be able to merge in the mdr branch soon so that people who are tracking that stuff can also benefit from the updates on trunk. Mark

1 0

Anyone tried the arc tweezing patches?
by Mark Burton 15 Oct '09

15 Oct '09

I have received zero feedback on the recent arc tweezing patch. I believe that in its latest form (v4), it provides much improved routing instruction quality. In particular, it should give you fewer instructions to keep left/right or even turn left/right when you are continuing on a long road (like a motorway) that has various roads that branch off of it. So please do try it out if you can and report success/failure, etc. Thanks, Mark

3 12

Commit: r1279: Added --delete-tags-file option.
by svn commit 15 Oct '09

15 Oct '09

Version 1279 was commited by markb on 2009-10-15 09:49:30 +0100 (Thu, 15 Oct 2009) Added --delete-tags-file option. --delete-tags-file=FILENAME Names a file that should contain one or more lines of the form TAG=VALUE or TAG=*. Blank lines and lines that start with # or ; are ignored. All tag/value pairs in the OSM input are compared with these patterns and those that match are deleted.

2 1

Commit: r1277: Improve handling of arc headings.
by svn commit 15 Oct '09

15 Oct '09

Version 1277 was commited by markb on 2009-10-15 09:49:23 +0100 (Thu, 15 Oct 2009) Improve handling of arc headings. We now write curve data that conveys an arc's final heading - the format is fairly well understood but if this causes any breakage use the temporary option --no-arc-curves to disable the arc data. Added --adjust-turn-headings option that, wherever possible, ensures that turns off to side roads change heading sufficiently so that the GPS believes that a turn is required rather than a fork. This also avoids spurious instructions to "keep right/left" when the road doesn't actually fork. Added --report-similar-arcs option that will issue a warning if more than one arc exists between two nodes and the arcs follow similar (hopefully, identical) paths.

1 0

[PATCH v1] add --delete-tags-file option
by Mark Burton 15 Oct '09

15 Oct '09

Here's the thing we talked about earlier. I'm too tired to write about it now but the code should work well enough for people to evaluate. The option file blurb tells you how to use it. Feedback, etc. Mark

2 2

[PATCH v2] modify road speed and class from a POI
by Mark Burton 14 Oct '09

14 Oct '09

v2 - you can now have mkgmap:road-class-min and mkgmap:road-class-max tags (and the same for the road speed) that will limit the final value used. These can either be added to the POI (from whence they will be transferred to the way by mkgmap) or directly to the way. --------------------- This is something that was briefly discussed not too long ago and the idea is that a road's speed or class can be modified by the presence of a POI that defines new values for either/both of them. This, hopefully, will make ways that have stuff like traffic signals and crossings, etc. less attractive to route over. The values are specified using mkgmap:road-speed and mkgmap:road-class tags added to the POI. These tags expect an integer value, optionally preceded by a + or - which make the adjustment relative to the original value. For example, mkgmap:road-speed=3 sets the speed to 3 and mkgmap:road-speed=-1 reduces the speed by 1 from whatever value it had before. Here's some possible rules for the points file: highway=traffic_signals { add mkgmap:road-speed = '-1' } highway=crossing { add mkgmap:road-speed = '-1' } highway=mini_roundabout { add mkgmap:road-speed = '1' } The region of the way that has its speed/class modified is limited to the closest points either side of the POI. Not sure if that's the right thing to do yet. Needs playing with. You need to specify the --link-pois-to-ways option to enable this functionality. All feedback welcome. Mark

2 4

[PATCH v1] modify road speed and class from a POI
by Mark Burton 14 Oct '09

14 Oct '09

This is something that was briefly discussed not too long ago and the idea is that a road's speed or class can be modified by the presence of a POI that defines new values for either/both of them. This, hopefully, will make ways that have stuff like traffic signals and crossings, etc. less attractive to route over. The values are specified using mkgmap:road-speed and mkgmap:road-class tags added to the POI. These tags expect an integer value, optionally preceded by a + or - which make the adjustment relative to the original value. For example, mkgmap:road-speed=3 sets the speed to 3 and mkgmap:road-speed=-1 reduces the speed by 1 from whatever value it had before. Here's some possible rules for the points file: highway=traffic_signals { add mkgmap:road-speed = '-1' } highway=crossing { add mkgmap:road-speed = '-1' } highway=mini_roundabout { add mkgmap:road-speed = '1' } The region of the way that has its speed/class modified is limited to the closest points either side of the POI. Not sure if that's the right thing to do yet. Needs playing with. You need to specify the --link-pois-to-ways option to enable this functionality. All feedback welcome. Mark

5 9