Mkgmap/routing/issues

From OpenStreetMap Wiki
Jump to navigation Jump to search

The point of this page is to keep track of open issues with the routing support in mkgmap, since the talk page was getting unwieldy. Feel free to condense the comments, deleting irrelevant content or moving it to new "issues", and archiving solved issues to Talk:Mkgmap/routing/archive.

Buggy routing

Pink line of death

SVN trunk r863 has a possible fix for this issue. Old discussion archived at Talk:mkgmap/routing/archive
  • Tested with Garmin eTrex Legend HCx in demo mode map compiled from .osm: 3 routes that previously had problems didn't show problems. Also tested in demo mode one route with same map but source being .mp, no problem detected either. mkgmap nod - version 869. --Japa-fi 20:43, 10 February 2009 (UTC)

Bug in roundabout exit-counting.

This might be mkgmap, or it might be in the Garmin StreetPilot i3 route-finder firmware. Basically, if you have an exit on a roundabout which shares its start-node with the end-node of an entry to that roundabout, then the exit won't get counted. This is certainly true if the afore-mentioned entry to the roundabout is a 'no candidate' for exit counting (like it's one-way onto the roundabout). Not sure what happens if it was bidirectional.

I've seen this happen twice now. A workaround is to edit the roundabout in OSM so that the entry and exit don't meet the roundabout at the same node. Steve Hosgood 09:42, 23 January 2009 (UTC)

I think editing the data would be the way to go -- not necessarily in OSM if that wouldn't reflect reality any better, but as a preprocessing step when generating the routing graph. Robx 08:49, 26 January 2009 (UTC)

There's an option --frig-roundabouts in current SVN that does something to roundabouts to improve routing. I don't think it splits nodes with two exits, however. Robx 11:23, 19 February 2009 (UTC)


Weird roundabout routing.

If you enter this roundabout from the west on the A48 primary route and your navigator is taking you eastwards, then you'll be sent south on the B4265 for a couple of km, then east on another 'B' road to rejoin the A48 about 5km east of the rogue roundabout. That doesn't seem to be the logical route!! If you tell the navigator (Streetpilot i3) to reconsider whilst still approaching the roundabout, it will instead take you *north* on Ewenny Road into southern Bridgend then out again to rejoin the A48 to the east.

To add to the fun, if you approach that roundabout from the south on the B4265, navigating to places logically off to the west on the A48, it instead routes you *north* into Bridgend again rather than west onto the A48. This time however, on the approach, you can get away with telling the machine to reconsider and then it does spot the left turn on the A48 as an option.

What's wrong with the roundabout? I've checked all the ways and nodes. Nothing wrong that I can see. There's quite a lot of traffic-light nodes, but that's nothing unusual around here. I saw some comment on the mailing-list archive about routing nodes having to be more than 5.4m apart, but these ones seem further apart than that. Any ideas please?? Steve Hosgood 15:25, 27 February 2009 (UTC)

Bad bicycle routing

The bicycle routing is improved.

The following comments are outdated. I suggest to remove it.
This may be a limitation in the Garmin units.
  • Most of the routes are reasonable, but (as with Garmin city navigator) there is a bias towards major roads in bicycle mode. The bicycle routes from OpenRouteService are somewhat shorter and a lot nicer.
  • I'm not even sure that Garmin itself has integrated all of the settings shown on the unit. I do assume that the only difference between routing by foot and routing on a bicycle is that "foot" aoutoroutes you against one-way streets. It is impossible however AFAIK to create maps that would guide "foot" on footways and bicycle on bicycleways and pathes..... Garmin possibilities are quite hard to understand here. You could try 0x00 to 0x0f to see on which kind which vehicle type is autorouted. Testing this would be the smartest thing for the beginning (and creating a table to document your findings).
  • Once you have done this, you should think about how to implement it to the existing tag ranges. Don't expect too much. Nearly all Garmin units don't even respect the "avoid highways" tick if you calculate longer distances! (only some motorbike units, mainly only the BMW units do this correctly - so it depends not only on the map, but also on the unit and it's respective firmware). Also don't expect Mapsource to do the same as your unit, both have different routing engines (probabely 6.14.1 has different routing engine form 6.13.7 too)--Extremecarver 22:53, 15 December 2008 (UTC)

--abunai

  • I also find the bicycle routes strange, but if the Garmin maps show that, too, I guess it's more a problem with the routing algorithm they use. Once we're confident the format is correct, we could try to artificially increase the length of major roads to get a bias in the other direction, but that's some way off. --Robx
  • It seems like selecting bicycle routing produced the route that would be the fastest if one could drive the speed specified by the speedlimits, without going to the motorway. Not 100% sure, but that is the first impression I got by looking at proposed route to my office. Same applies even to pedestrian. What makes it strange is that I selected "Shortest route" from Garmin. --Japa-fi 20:21, 8 December 2008 (UTC)
  • Apparently, "shortest route" just doesn't work in general. Robx 10:43, 10 December 2008 (UTC)
  • version 735-svn created a bicycle route that made ore sense than that created with previous version. There is still a part in the route which I don't agree to, but I have to investigate how some parts are mapped. --Japa-fi 19:33, 11 December 2008 (UTC)
  • For bicycle routes that are longer than some 20 km in urban areas, Garmin Edge 705 seems to ignore cycleways in the middle of the route. That is, you will get better route suggestions when you re-route every 20 km or so. This is less severe in rural areas with few cycleways, but the problem exists.--Skela 20:10, 25 August 2009 (UTC)
  • Sometimes, a route from A to C is much longer than the routes from A to B and B to C. The following occurred with mkgmap r1141 and Geofabrik’s finland.osm.bz2 from 2009-08-21. I reviewed and validated all the data along the route, based on track logs from my bicycle ride. All routes are within a single map tile, and no assertion failed in mkgmap.
  • The bicycle route from Jokivarsi to Heinola is close to ideal (112.2 km), as is the route from Heinola to Kuortti.
  • The bicycle route from Jokivarsi, Vantaa, Finland to Kuortti, Pertunmaa, Finland suggests a detour of about 40 km, turning from highway 140 (the most logical route) to highway 363 at 99.8 km, before entering Heinola.
  • The following settings did not affect the route suggestion:
  • Ticking or unticking the “avoid highways” setting of the Garmin Edge 705
  • Raising the resolution of highway=cycleway from 23 to 19
  • The cycleways will be displayed on lower zoom levels, but
  • it does not affect the suggested bicycle routes.--Skela 20:10, 25 August 2009 (UTC)

Wrong roundabout direction

mkgmap-r828: Routing in Roundabouts always results in a left turn, instead of right. (Tags are ok with junction=roundabout in the correct direction). I tested this with C550.--Pierrelu 09:34, 29 December 2008 (UTC)

Errors calculating long inter-tile routes

Calculating long routes across multiple tiles sometimes fails. It's not yet clear whether this could also occur for long routes within large tiles. May be related to the lack of links.

I can confirm that I'm getting this error in r1067 (and earlier). It doesn't seem to be the distance that is the problem as I can calculate long routes over the whole of a tile without problem. I also usually don't have any problems with routes crossing from one tile to another. The problem seems to occur where you have three or more tiles involved in the route (ie. start tile, finish tile and intermediate tile). On a map I downloaded today four tiles meet at a single location which gave a good chance to test this and routing over just a few hundred yards doesn't work if the start and end are on opposite corners (because it must go through an intermediate tile). However, if the route stays within a tile or just crosses one of the tile boundaries then there isn't a problem (regardless of distance). So it doesn't seem to be a problem with the individual tiles or even the joins between individual tiles it something else. Note: I don't know if this is a problem with mkgmap or a limitation with the garmin format itself. --MarkS 16:34, 1 July 2009 (UTC)

gmapsupp.img does not load (too big tiles?)

If I generate finland.osm (470,980,101 bytes, Feb 25 06:47 UTC) in two tiles, my Garmin Edge 705 will pretend that the gmapsupp.img does not exist (it will only display the base map). I assume that it is related to too big tile size. Last time, I used these commands:

java -enableassertions -Xmx1024m -jar splitter.jar --max-nodes=2400000 finland.osm

java -enableassertions -Xmx1024m -jar mkgmap.jar --country-abbr=FIN --country-name=Finland --family-name=OSM --area-name=Finland --latin1 --gmapsupp --route -c template.args

This was with mkgmap r929 and splitter.jar (35,623 bytes, Feb 23 19:58 UTC). (Where can I find the splitter.jar source?) With mkgmap r901, the two-tile map of Finland worked. A three-tile Finland does work with r929. --Skela 09:33, 26 February 2009 (UTC)

Bicycle routing over motorway

I tried to route from chemnitz to dresden (via bicycle routing) using eTrex Vista HCx on the "new routable map" http://openstreetmap.teddynetz.de/latest/de_rout_gmapsupp.img.gz and it tries to route me over A4 (which is marked as motorway. It is not allowed in germany to use the motorway by bicycle (and it is dangerous too). Is there a way to test if bicycles are allowed on that way on the garminsupp.img or if it is a bug on the garmin device?--Moshroum 19:43, 23 April 2009 (UTC)


I don't exactly know Computertedd's style, but the mkgmap-default should not send you onto motorways - but there's another "issue" I noticed with highway=trunk in the default-style. You'll be sent there by bike, even if there's a motorroad=yes; so I would appreciate that patch to resources/styles/default/lines: 

 highway=track [0x0a road_class=0 road_speed=1 resolution 21]
+highway=trunk & motorroad=yes {add bicycle=no; add foot=no} [0x02 road_class=3 road_speed=5 resolution 16]
 highway=trunk  [0x02 road_class=3 road_speed=5 resolution 16]
+highway=trunk_link & motorroad=yes {add bicycle=no; add foot=no} [0x08 road_class=3 road_speed=3 resolution 16]
 highway=trunk_link [0x08 road_class=3 road_speed=3 resolution 16]
 highway=unclassified [0x06 road_class=1 road_speed=2 resolution 21]

matt_gnu 30.4.2009, 13:45

Data format unknowns

RouteParams and routing options

It's not quite clear how certain things are encoded: unpaved roads, carpool lanes. It may be that the Garmin type of the polyline comes in in addition to the routing parameters in NOD.

Routing options

  • vehicle type
  • avoid carpool/toll/unpaved

RouteParams

The RouteParams line is of the form 

RouteParams=speed,class,oneway,toll,emergency,delivery,car,bus,taxi,foot,bike,truck

speed and class are values from 0 to 7, while the others are 0 or 1. The names above are from the cGPSmapper documentation. The last six simply specify whether you're allowed along the road with that vehicle (1 == no access). The first four are also mostly clear, though I haven't tested whether toll actually works. But emergency and delivery don't function as the other vehicle types.

Discussion

Possibly, the naming is wrong, and one of these should be called unpaved.

Actually they do. emergeny uses roads that are usable by emergency services but otherwise closed to motor traffic. I'm not sure about delivery, but I guess it's something between car and truck. --abunai 21:51, 15 December 2008 (UTC)
Hmm, I tried setting each flag separately at some point and switching through the vehicle types on my Vista HCx, and none of the bits caused the road to be avoided as delivery or emergency... Does emergency=1 and car=1 mean that a car can't go, but emergency can? Robx 22:30, 15 December 2008 (UTC)
I don't know about the flags, but with city navigator, the emergency option works as I would have expected. --abunai 23:34, 15 December 2008 (UTC)
Did some testing by hand-editing a trail with "RouteParams=0,0,0,0,0,1,1,1,1,0,0,1". Car, foot and bike params worked as they should. Toll=1 avoided the trail for both bike and foot. For other params I did not observe any effect. Even changing the polyline type from 0x16 "Track/trail" to 0x0a "Unpaved Road-thin" did not change anything. Toggling "Avoid unpaved roads" did not alter the route in any case. I do not know does in Garmin speak "avoid" mean "try to avoid", as I do not have commercial maps. --Jaakkor2 22:09, 15 December 2008 (UTC)
I own City Navigator. With MapSource on the PC I have the following option: Vehicle type: Bus/Truck/Car/Bike/Delivery/Emergency/Foot/Taxi; Avoid toll; Avoid unpaved roads; Avoid U-turn; Avoid carpool lanes. Therefore it seems that the known flags do what they are supposed to do.
The carpool setting is also missing... It seems quite likely that emergency/delivery should be unpaved/carpool. Robx 07:46, 15 December 2008 (UTC)

Paved/unpaved

On Garmin GPS, there is a routing option "Avoid unpaved roads". It is unclear what data this depends on.

By User:7503146's tests, this is encoded in the road class, which is part of the RouteParams field in .mp-files:

As http://www.digitalmobilemap.com/index.php?slug=mapmaker-getting-started5 suggests the usage of road class value 0 for "unpaved" roads, I made some tests and modified the poly.cfg in osm2mp. I added following lines to poly.cfg:
surface         paved                   r       0x0a,2          0       2       1,1,0,0,0,0,0,1,0,0,0,0
and
surface         unpaved                 r       0x0a,2          0       2       1,0,0,0,0,0,0,1,0,0,0,0
With these settings my Garmin Edge 705 does compute different routes, depending if "avoid unpaved roads" is switched on or off. --7503146 10:13, 6 January 2009 (UTC)
I still don't believe that road class makes a road paved/unpaved. According to cgpsmapper docs, at least 60% of ways should be road class = 0, and this contradicts road class = 0 being unpaved roads. I still believe that roads are "unpaved" according to their Garmin types ("unpaved road" & "walkway/trail"). FedericoCozzi 15:15, 7 February 2009 (UTC)

Older discussion

Possible encodings for paved/unpaved that I see are:

  • specific low values of class (or maybe speed)
  • one of the flags emergency, delivery or (unlikely) toll
  • something else entirely -- perhaps this information is deduced from the feature type of the corresponding polyline?

Robx 07:39, 15 December 2008 (UTC)

Moreover, "avoid unpaved roads" is more "try to avoid": if I ask for a route between two point and the only possible route is unpaved, it shows the unpaved route. If there is an option, it shows the paved one. FedericoCozzi 08:12, 23 December 2008 (UTC)

Curviness

Arcs (edges between routing nodes) contain optional "curviness" information that we're not writing and that is not completely understood.

Possibly, the pink line is drawn using the polylines in TRE/RGN at zoom level 0, and using the data in NOD/NET for lower zoom levels. In that case, the curviness data would be used for drawing curved edges in the routing graph correctly at low zoom levels. Is anybody seeing this? It should occur on long curvy roads with few routing nodes, say overland roads.

Links

Currently, mkgmap only writes arcs to NOD: direct edges between routing nodes. The format also allows links, which provide some kind of short cut. It appears that links can only go along a road, and that they usually point to intersections with roads of higher class. It may be that links make the routing algorithm more efficient. It may also be that they're necessary for calculating very long routes (in terms of number of legs, not in terms of distance).

Links may also have length and curviness data, but it's not encoded in quite the same way.

Missing routing features

Inter-tile routing

SVN now supports inter-tile routing if the tiles are split using the splitter.

Verified with mkgmap r929, using the default tiling of finland.osm.bz2 (SW/SE tile boundary running almost parallel to Lahdentie). Alas, the routing with the Garmin Edge 705 is worse with that tiling than with mkgmap r901 using a single tile of South Finland (splitter.jar --max-nodes=2400000 finland.osm). The optimal route (obtained on the single tile) is NW-bound. With two tiles, the Edge tells me to go Lahdentie norhtbound and then taking a road westbound. Maybe this is a design issue with the routing algorithm? Maybe something to consider in splitter.jar: avoid splitting near a primary or secondary road? Or maybe the tiles should be configured manually? --Skela 22:40, 24 February 2009 (UTC)

Could you provide some more details, say a link to the area?
As I understand, the optimal route crosses the tile boundary at a different place than what the Edge computes. Could you try routing just over the boundary along the optimal route, to check whether there's a bug in the boundary data we're writing? It's possible that the routing algorithm is limited, but at this point my first guess is that we're writing buggy data. Robx 07:53, 25 February 2009 (UTC)
The problematic tile boundary is at longitude 1167360 (25.048828 degrees east). I'm computing a route from Jokivarsi to Loppi with the Garmin Edge 705. When using a single tile of the area, it will tell me to go NW. With the tile boundary at lon=25.048828, it will tell me to go east to Lahdentie, follow it north, and eventually turn west, a 20km (25%) longer route. I already implemented a workaround: define two splits by latitude in areas.list, so that Southern Finland (the most densely populated area) will be one part. --Skela

Restrictions

"Simple" turn restrictions are implemented since r935.

Lack of prompts

  • (4) On this motorway exit I came on the A3 south-east bound and the route led me correctly onto the primary road northbound. The complete 270 degree turn in the motorway exit was correct in the eTrex' purple route indicator but there were no turn arrows or routing information text at all. --R kleineisel 08:55, 16 December 2008 (UTC)
I've seen something like Problem (4), too. A rather wild guess is that it has to do with unlabeled roads, i.e., that the eTrex only gives you directions if there's a name on the road. It seems osm2mp doesn't substitute ref for name if there's no name at the moment. Robx 12:20, 16 December 2008 (UTC)
If this is the case I suggest to fill the otherwise empty name field with something like the road type (motorway, road) just for the GPS to have something to use. --R kleineisel 13:48, 17 December 2008 (UTC)
I've been seeing the same thing, and tried this suggestion of naming things like motorway entry and exit ramps. It does make things better, but isn't quite right. For instance, with an unnamed exit sliproad where I get off the M4 in the mornings, my Streetpilot i3 will announce things like "in 1.3km, enter roundabout" whilst I'm still on the motorway. There's no mention of getting off the motorway first! With the sliproad named something like "exit slip north", the announcement now goes "in 900m keep left" at that same point on the motorway (because the sliproad is 400m long) then as I start on the sliproad itself, I hear "in 400m enter roundabout". So it's certainly better with a named sliproad. However, the official Garmin map that came with the unit announces "in 900m exit left" not "in 900m keep left", so evidently there's still some sort of markup that we're missing on motorway exits. Steve Hosgood 17:04, 9 February 2009 (UTC)

There's a hack that artificially changes some of the turn angles that could use some feedback. As is, it should make the angles of motorway exits in left-road countries larger and may provide better prompts in those cases. For experimenting with the labelling, the style support in osm-based mkgmap should allow modifying the name field based on the road type. Robx 07:50, 26 February 2009 (UTC) could use some feedback. As is, it should make the angles of motorway exits in left-road countries larger and may provide better prompts in those cases. For experimenting with the labelling, the style support in osm-based mkgmap should allow modifying the name field based on the road type. Robx 07:50, 26 February 2009 (UTC)

I manually added a node to this exit of the M4 in my area. It makes the angle between the motorway and the (named) exit road be 90° just for an experiment. Normally, approaching that exit, I am prompted with "in 600m keep left". With the 90° hack I am told "in 600m turn left". Still not as good as Garmin's own maps that say "in 600m exit left". However - when driving big roundabouts with mkgmap-created maps I do get the prompt "exit left" as I approach my exit. Is there anything special about roundabout exits that can be applied to motorway exits? Steve Hosgood 11:33, 2 March 2009 (UTC)

Having been the author of several observations and grumbles about this problem above, I'm really happy to state that as of r984 it looks like the problem is solved! Great work everyone who've been struggling to sort out this issue. It's also noticeable that (at least with a StreetPilot i3) if you watch the scrolling map display when the unit is *not* in navigation mode, the top line of the display offers a useful summary of what's coming next on your road - things like "5.2km: J36 - A4061 Bridgend,Maesteg" whilst driving the M4 motorway in South Wales this morning. Steve Hosgood 10:16, 20 March 2009 (UTC)

Several more questions about turn warnings:

' I use a GPSMap60CSX Software Version 3.70, GPS Software Version 3.00. 1) Final turn warnings work well when driving with my map, but I never get early turn warnings. 2) I only get turn warnings intermittently when hiking. When hiking I notice that when pass through a turn, the turn doesn't transition to the next turn on the turn by turn navigation screen until I've walked perhaps 100 meters. Is this a speed issue? Last test was compiled with mkgmap r987--Seldom 21:44, 29 March 2009 (UTC)

Interpretation of OSM data

pedestrian

It looks like that my garmin wants to route me right through a pedestrian-way. (Schlosstraße here)

Have you checked whether the .mp-file has correct routing parameters? Is your Garmin vehicle type set correctly? Robx 18:34, 25 December 2008 (UTC)
I'm getting this too. The .mp file claims "0,0,0,0,0,1,1,1,1,0,0,1" which should be emergency services,foot and bicycle only. But I'm getting routed that way (by car) with a Streetpilot i3. Yes, I've set the vehicle type correctly! It would seem to indicate in favour of the conjecture that the "emergency services" bit is more of a "use this route only if you have to" bit. When I'm routed this way, there *is* an alternative but it involves driving at least 500m on 'unclassified' or 'tertiary' roads. The other side of the footway connects to a "Class B" road which is obviously a juicy bit of bait in comparison. Steve Hosgood 14:32, 2 March 2009 (UTC)
Update: I'm still getting the above bad routing here (the lane between Orchard Street and the B4489, that runs beside the Kings Arms Tavern). Most of it is now highway=pedestrian (changed from highway=footway) and the OSM data has even got a bollard in the middle! But I still get routed down there in a car if I approach from Pleasant Street. This is certainly not what I'd call useful driving instructions! Steve Hosgood 17:17, 10 March 2009 (UTC)
There have been changes to the routing restrictions in trunk lately. In particular, emergency/delivery were written to the wrong places. Does the above occur with a recent trunk version? Does it also happen if you run mkgmap directly on the .osm? Robx 12:20, 11 March 2009 (UTC)
The problem was still there this morning using this map from here created with mkgmap r984 yesterday directly from the .osm files. I had altered the road layout slightly hoping to make it less likely that the machine would route me that way, but it still did it. Take a look here. I was routed along Pleasant St. (fine) then across Orchard St. into the bus lane (not good - flagged access=no, psv=yes), then immediately turn right into the un-named "highway=pedestrian,surface=paved,foot=yes" section (not good), then through a node flagged as "barrier=bollard" (yikes!) then down the short bit of service road and turn right onto High St. (highway=secondary,ref=B4489). I would have expected to turn right at the end of Pleasant St. into Orchard St. Steve Hosgood 10:05, 20 March 2009 (UTC)
It appears to be that pedestrian streets just don't get the nocar bit set. Compare the lines for highway=footway and highway=pedestrian in styles/default/lines -- r985 has a likely fix for this. I don't think barrier=* is currently interpreted. Regarding the bus lane, no idea why it doesn't honour the access=no. Robx 10:32, 20 March 2009 (UTC)

access and gates

How do I configure the map to avoid gated subdivisions mostly tagged with access=private and barrier=gate?

For the moment, this is a matter of configuring/modifying osm2mp to write an appropriate .mp-file. Once the .mp-file is correct, let us know if the map mkgmap generates from this still has the problem. Robx 12:29, 14 January 2009 (UTC)

bicycles and oneway

  • Support for routing opposite to oneway for cycleway=opposite_lane

Currently routing for bicycles opposite to oneways is not supported. The Garmin MAP format does not seem to allow the definition. Are there any possiblities? One option would be to generate bicylce specific Garmin maps, but this does not look nice. --7503146 18:49, 6 January 2009 (UTC)

That is not too difficult. You need to create a copy of the way and have the opposite lane as own street. As cycleway opposite lane usually is allways a lane for both directions you wouldn't even need to reverse the direction of a way. Is oneway=-1 already supported by the way? If yes you could simply exchange it before processing. Off course that opposite lane will be visible too for caruse. You could however exclude it via a typfile so that it's at least not displayed.--Extremecarver 19:30, 6 January 2009 (UTC)

access restrictions

  • Cyclists should not be sent onto the autobahn.
  • Looks like highway=pedestrian is allowed for routing a car (maybe an osm2mp issue)
* Regarding the pedestrian issue, you can check the RouteParams=-line in the corresponding Polyline entry in the .mp-file. The seventh flag is NO_CAR.


various

First of all, great job, I made several tests with maps generated with mkgmap-r828, Gpsmapedit and mkgmap-r806 on Garmin 60Csx and C550. Mkgmap-r806 was used with enableassertions. Both of them are in motorcar mode with shortest time, avoiding unpaved roads. Both want to route on cycleways, pedestrian, and do not observe access=no. Sometimes it does not observe oneways in order to route on the shortest way, tags are correct. Distances are all ok, time indications not, it less important for me at the moment.

Character encodings

Latest status (11:24, 11 February 2009 (UTC)) is: osm2mp --nocodepage should work with mkgmap again (with default UTF8 encoding). Otherwise, osm2mp writes a CodePage line to the .mp-file, which mkgmap should honour.

Umlauts

Old discussion removed by --Japa-fi 16:14, 26 December 2008 (UTC). Summary:

  • Use the latest revision of osm2mp from svn with the "--nocodepage" option, and mkgmap with "--latin1". --abunai 09:37, 8 December 2008 (UTC)
  • Apparently you need to put the option before the file name. Try java -Xmx384m -enableassertions -jar mkgmap.jar --route --gmapsupp --latin1 inputfile.mp  :) --abunai 21:22, 12 December 2008 (UTC)

äöüß ?

Is there a way to get german Umlaute in the garmin maps ?--Flacus 09:06, 20 December 2008 (UTC)

In mkgmap you need the --latin1 flag. Make sure the flag is before the file names.
I use "--codepage 1252" on osm2mp.pl and "--latin1" on mkgmap works for me on my Legend Cx. See my Düsseldorf map
Your Düsseldorf-Map shows ? instead of ß on my 60CSX. What about my Maps, they also show ? on my 60CSX do they work on your Legend Cx ? --Flacus 13:21, 23 December 2008 (UTC)
I had the same problem and tried different options. You have to create the .mp file in utf8 encoding. To do that you can use "osm2mp.pl --nocodepage". Then you use "--latin1" option with mkgmap and it works. I have tested it on a garmin 60 CSx. --Master 21:27, 27 December 2008 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Mkgmap/routing/issues&oldid=599550"