Talk:Mkgmap/routing

Some open issues are in the process of being sorted into mkgmap/routing/issues.

POIs & Routing

Are POIs affecting to routing choices? Ie. if I edit osm2mp poi.cfg to exclude all highway traffic_signal, will it affect route generation? --Japa-fi 16:14, 26 December 2008 (UTC)

Missed this one, but also I don't know for sure. I suspect it wouldn't make a difference. Do you know if e.g. traffic lights are taken into account when routing via Garmin-produced maps? Robx 13:52, 27 January 2009 (UTC)

Why do we need OSM to MP Conversion ?

Why is there a need for conversion to Polish Map format? I have used a lot of time to write configuration files and corresponding typfiles for my maps for mkgmap. If I wan't autorouting support, I would need alot of time (and also maybe needing to drop some features) to create corresponding configuration files for osm2mp. If I use osm2mp than at least for my private maps I could also use cgpsmapper which is more advanced than mkgmap (for noncommercial maps). I use mkgmap primarily because I don't wan't to convert to mp. Is the goal in the long run to drop that need for conversion and have mkgmap support routing directly from Osm maps? (I'm writing this here instead of mailing list because I think that it's easier to discuss such things on wiki instead of mailinglist).--Extremecarver 16:42, 8 December 2008 (UTC)

It is the goal to support routing directly from OSM format, it is just not done yet. --AcousticNewt 17:16, 8 December 2008 (UTC) ..Steve

SVN (nod branch) now has initial support for this. Robx 08:18, 10 February 2009 (UTC)

Another one reason is that there are several navigation software (Navitel Navigator, GIS Russa..) that has their own map formats and converters from polish format. Dema 14:56, 5 March 2009 (UTC)

Actually since about two weeks there is no more need to convert to mp. It works as good or better without (normal trunk).--Extremecarver 18:30, 5 March 2009 (UTC)

Special codes in polyline Labels don't work

Moved to Talk:Mkgmap

Finding addresses

My 60CSx manual states:

If you downloaded optional detailed mapping data, use
the Addresses icon on the Find Menu to find an address.
When you enter the street number, street name, and city, the
find feature matches that data with addresses in the map
database.

However I see no such option in the Find menu when I create a routeable map. Even though the map data I'm working with has addresses both in the Karlsruhe Schema and of course street and town/city names. --Ævar Arnfjörð Bjarmason 13:42, 13 January 2009 (UTC)

In addition to what is said above, if I use the menu Where to? > Address in my Nuvi 300, I'm asked In what State/Province is the address?, with an option to spell the State/Province, but no State/Province is found in the database, so I can't continue introducing any address. I always use option --defaultcountry Spain when I generate mp file with osm2mp, but doesn't seem to work. Am I missing something?--Carluti 10:08, 21 January 2009 (UTC)

I don't know to what extent address data is even being written and how well the encoding is understood. I remember some related posts on the mailing list -- maybe you want to ask there? Robx 08:50, 26 January 2009 (UTC)

The 'tolerance' setting for following the expected route

I've noticed an oddity. If I use the standard Garmin mapping that came with my StreetPilot i3, then whilst I'm following the navigator, if I deviate more than 50 - 100 metres or so from the route on the screen then the machine declares "recalculating" and gives me a new route.

But if I happen to be running maps generated from mkgmap, the tolerance is much bigger. Way bigger - something like 300 metres - maybe even more than that. This is a total pain in a town where you were forced down a road different (but near to) the one the navigator suggested. It carries on giving you instructions relevant to the other road!! This can go on for quite a while if the two roads are parallel.

It looks like the machine measures the closest distance between 'you' and the route that it plotted. As long as you are less than this tolerance value, it assumes you're on its route.

Is there a 'tolerance' setting in the .IMG file somewhere that anyone has found? Is there already a way to control it when generating maps? Steve Hosgood 17:28, 22 January 2009 (UTC)

Facinating observation. I have no idea what might control it however. AcousticNewt 19:44, 22 January 2009 (UTC)

I've been thinking about this and I have a wild conjecture! Basically, Garmin must have designed the system so that people driving down a Californian 6-lane highway could switch from the right hand lane all the way to the left hand lane without the navigator thinking they've gone off-road and announce "recalculating". At the same time, they had to allow for European cities where two parallel streets would be closer together than that!

So - I reckon that Garmin have encoded a "width of carriageway" factor into every 'way'. My guess is that this is the real purpose of the obscure "curvyness of road" value mentioned in the .IMG format documents. I believe that the existing value of "curvyness of road" is just a constant that mkgmap puts into the files to make them work? I reckon that this value corresponds to a carriageway width of about 600m! Hence my observation about having to travel 300m off the centreline of the road before the machine announces "recalculating".

It might be nice to have a version of mkgmap where this constant is taken from the command-line so that we could play with it and see if it affects the "off route" tolerance. If it does we should be able to calibrate for it, and in future to autogenerate values for it based on how many lanes OSM claims for ways. Steve Hosgood 11:04, 25 January 2009 (UTC)

If you want to do some experiments, the relevant source file is src/uk/me/parabola/imgfmt/app/net/RouteArc.java. Note that currently, we're not writing the curve data at all. Robx 08:55, 26 January 2009 (UTC)

Four questions please:

1) Does anyone have a non-encrypted, routable Garmin .img file that I can use to try and decipher the 'curvyness' stuff?

2) Is imgdecode-1.1 (by John Mechalas dated 2005) the latest known interpreter program for the .img file format?

3) Is imgformat-1.0.pdf (also by John Mechalas dated 2005) the latest known document on the file format?

4) Is nod.txt the latest known document on the '.nod' subfile format?

Thanks in advance anyone. Steve Hosgood 11:22, 27 January 2009 (UTC)

1) There are some such maps on mapcenter, including .mp sources. Last I checked, the conditions didn't prohibit decompiling. Also perhaps the OSM-based Garmin maps compiled through cGPSmapper?

2) No, there's the display programs in http://svn.parabola.me.uk/display/ and something in navit -- see also OSM_Map_On_Garmin/Format.

3/4) Yes. There's some info in the libgarmin wiki, and the display programs know a little more than is written down in nod.txt. Note that test.display.NodDisplay still fails on some IMG files for me.

If you have further questions, in particular regarding the format, please consider posting to the mkgmap mailing list (easier discussion, and more readers that might know something). Robx 13:49, 27 January 2009 (UTC)

My experience on recalculating the route is that it's less than above mentioned 600 meters. More likely 50 meters or so... --Japa-fi 18:04, 27 January 2009 (UTC)

I'll agree that 50 or so metres is a typical recalculate-distance for Garmin's own maps, but mkgmap's maps definately seem not to agree. There's a comment in a topic below from a walker claiming similar issues. If you have a home-made map giving you 50 metres tolerance, can I have a copy please? And how did you generate it? Mkgmap? cGPSMapper? Via the Mapcenter map-compiler page (which may be cGPSMapper wrapped in a web page)? Steve Hosgood 11:22, 28 January 2009 (UTC)

Testing though the results may not be reliable as routes in general were bit flakey (Unit thinking I was driving on cycleway next to the road etc). I noticed that recalculation took place earliest at 190m past the turn and no later than 250m past the turn. This result was not affected by selected zoom level. The result was not dependant on time (some stops before reaching 200m), though most of the time while in move, the speed was 40-50km/h. Road travelled was most of the time highway=tertiary class road.

--Japa-fi 17:15, 1 February 2009 (UTC)

Where do I find the latest routeable version of Mkgmap?

I ran Mkgmap r806, with the --route option, on a small network of hiking trails I have established in GPSmapedit. The saved MP file has options for Transparent=Y and an MG check box checked. (MG checks for intersections, and presumably tells my GPSmap60csx to beep when approaching a turn.)When I open the Mkgmap compiled IMG file in GPSmapedit, the Transparent setting has been switched to "N" and the MG checkbox is unchecked. When I find "following road" in the field, the 60CSX routes correctly and provides correct written directions, but doesn't flag intersections and only starts recalculating when I have passed my "find" point by 500m.

Is r806 the last routable version? If not, where can I find it?

Since r842, mkgmap trunk includes the routing feature. Before that, you need to use branches/nod. Also note that mkgmap doesn't understand the entire .mp-format. Robx 08:57, 26 January 2009 (UTC)

Error when compiling the mp file with asian language

When I am trying to compiling the mp file with asian language using the latest built, the below error appear, not sure if it is because of the language of the map??? Thanks a lot

       Exception in thread "main" java.lang.NumberFormatException: For input string: "es1"
       at java.lang.NumberFormatException.forInputString(Unknown Source)
       at java.lang.Integer.parseInt(Unknown Source)
       at java.lang.Integer.parseInt(Unknown Source)
       at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.line(PolishMapDataSource.java:278)
       at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.processLine(PolishMapDataSource.java:218)
       at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.load(PolishMapDataSource.java:97)
       at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:128)
       at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:44)
       at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:148)
       at uk.me.parabola.mkgmap.CommandArgs$Filename.processArg(CommandArgs.java:359)
       at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:118)
       at uk.me.parabola.mkgmap.main.Main.main(Main.java:90)

Looks like a broken .mp-file, but it's really hard to tell from a distance. It appears there's a Data= line which should contain just coordinates of points but which actually contains other strings. Robx 11:46, 5 February 2009 (UTC)

Thanks, I tried another file, it works, however lables are all in "???" as before, also tried using --code-page=936, still the same, not sure how to make this work for asian language. Thanks boyamyxia

There's been talk on similar issues on the mkgmap mailing list, so you may want to check the archive. You may have to pass a codepage option to osm2mp. Robx 17:59, 8 February 2009 (UTC)

I've run into this with some of my maps. I found that deleting all of the lines from the .mp file that start with "Nodes" fixes the problem. To be more specific, the regex to match problem lines is ^Nodes\d+.+\n

akh

New issues page, possible bug fix

I've tried to sort the existing discussion on various problems into mkgmap/routing/issues. Feel free to edit that page, and add issues there if you like!

Also, there's a recent change by Mark Burton in SVN that hopefully fixes the main routing bug people are experiencing -- please let us know if it works for you. Robx 20:15, 8 February 2009 (UTC)