Talk:Mkgmap/routing/Archive 1

Archived discussion

Open issues have been sorted into mkgmap/routing/issues

Comments/remarks 1

I've just tried it and it works !! Good work from mkgmap team and also lioshia for the osm2mp converter.

My comments :

• The file is bigger than without routing so france.osm.bz2 stopped to fit in one single img file (I'll try cutting things in pieces as suggested on the mkgmap page)
• Looks like highway=pedestrian is allowed for routing a car (maybe an osm2mp issue)
• Else, I had no crash, are there anything special to try that might push mkgmap to a "test fonctions" ?

( I got a garmin 60cx ) Sletuffe 17:52, 6 December 2008 (UTC)

* Routing across more than one tile will be difficult -- the boundary nodes will need to be marked in the .mp-file, and I don't think osm2mp does that. It's also entirely untested.

* 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.

* I'm not sure what you mean with the crash -- mkgmap shouldn't crash. You may want to enable asserts (pass -enableassertions to java).

Robx 18:05, 6 December 2008 (UTC)

Whoops I expressed myself badly : "I had NO crash at all" so every thing is fine, but If you want any help, just ask me to test "known risky actions" that could trigger a bug. Tanks for your answer I'll make some test and find a bounding box that fits my need and the max tile size Sletuffe 18:15, 6 December 2008 (UTC)

Thanks for trying it out. Problem is, I don't really know any ways to trigger obvious bugs. If it works for you, that's great, or maybe you'll run into something. Robx 20:52, 6 December 2008 (UTC)

Solved issues

Routes for Car/Motorcycle

• The garmin is calculating routes for cars/motorcycle with using tracks (grade1) and also avoiding using highways=unclassified. --FrauSuhrbier 14:05, 13 December 2008 (UTC)

That's due to osm2mp. You could edit poly.cfg to disallow tracks and include unclassified roads. Robx 14:52, 13 December 2008 (UTC)

Where can I find info on the options in poly.cfg?

You need to edit options in the end of line that looks like '1,0,0,0,0,1,1,1,1,0,0,1'. See cgpsmapper's manual for meaning of that digits (RouteParam). --Liosha 09:31, 14 December 2008 (UTC)

Bad file format .mp

How does one do correct osm2mp conversion? Tried "osm2mp.pl finland.osm > map.mp" followed by "java -jar mkgmap.jar -- route map.mp". That gave error: Bad file format map.mp. finland.osm downloaded from cloudmade.com --Japa-fi 18:15, 6 December 2008 (UTC)

The osm2mp command line looks correct, apart from the space in "-- route", but that would give a different error. Does the map.mp file look sensible? I tried to reproduce the error, but the extract is too large for my computer to handle. Perhaps try a smaller extract for now? Building the img will also take ages for a map that size... Thanks for your feedback! Robx 20:46, 6 December 2008 (UTC)

Most likely the problem is caused by my distribution / environment settings. Another fellow OSM user was able to get mkgmap to accept the map.mp he created with identical steps what I had tried. And yes, the space between -- and route is just a typo on this page. If you are interested, the file generated by osm2mp is available at http://d01.megashares.com/?d01=baacec2 (23Mb zip file) --Japa-fi 21:46, 6 December 2008 (UTC)

The file works ok here (well, mkgmap aborts because it's too large, but I don't get your error). Cheers, Robx 22:03, 6 December 2008 (UTC)

It was the most obvious reason: Wrong java version. Java 1.5 was used instead of 1.6. Testing now with 1.6 version and didn't get the "Bad file format" -error. I gave the java session 1512 megabytes and I have not yet got error about file beeing too big, but it's still going its thing. Sorry for the unnecessary hassle created.--Japa-fi 09:34, 7 December 2008 (UTC)

Don't worry. Did it work for you in the end? It's strange that java 1.5 should be a problem, I've been using it myself. But maybe it's because the jar was compiled with java 1.6? Robx 10:07, 8 December 2008 (UTC)

The java file worked. I didn't get routable file though, the output was still too big file. Using smaller source I was able to produce a routable map for my garmin. Tested today, and the routing works.

Not finishing

I've tried it on a very small file - just a few streets, and also on a file covering a medium size town - and these ran for over an hour before I cancelled them, but not completed. I think it's probably an error maybe. Surely shouldn't take that long?Richard B 12:32, 7 December 2008 (UTC)

An hour is too long... It takes 50% longer than without routing for me. On a fairly large chunk of london that comes to about 16 seconds on my machine. Is it possible for you to post the small .mp file you were using anywhere? --AcousticNewt 12:59, 7 December 2008 (UTC)

I'm pretty sure it was the mp file that was incorrect, because I then tried it with a 1º square area with an updated osm2mp converter - and it's fine - albeit with some wierd results - such as being routed along a footpath in a car. Didn't take too long at all. Richard B 19:44, 7 December 2008 (UTC)

new bug

The distances look ok now, but there is a new problem: For more complex routes, route calculation appears to fail and I get basemap routing only. I haven't been able to get a bicycle beyond 10 km or an auto route beyond 80 km with the current version. I didn't have that problem before. --abunai 20:53, 9 December 2008 (UTC)

The problem is maybe also not with the map. Depending on the unit there is allways a rater small amount of max road changes per autoroute. Also with City Navigator maps, if you route a longer distance you will allways be routed over motorways and big streets, even if you explicitely excluded them. --Extremecarver 21:23, 9 December 2008 (UTC)

It's definitely a problem with the map. This doesn't happen with IMGs generated from the same OSM dataset prior to -r788. --abunai 22:19, 9 December 2008 (UTC)

There's definitely a bug relating to the "destclass" -- it was being set naively before, and now it's being set incorrectly. Looking into it. Robx 07:26, 10 December 2008 (UTC)

The destination class is now being computed as intended (r795) -- better? Robx 07:39, 10 December 2008 (UTC)

Yes. Thanks. --abunai 17:51, 10 December 2008 (UTC)

Some worked, some complete junk

I generated maps for all of Australia, and it appears that some worked perfectly, while others when I load them onto my 60CSx, just show junk for the maps. The generation showed no major errors (osm2mp produced a few warnings and the like, but it seemed to complete ok). Can someone please try out the two maps and see if they work OK? Problem VIC map and the OK NSW one -- Gaffa 01:30, 10 December 2008 (UTC)

I suspect this is the same problem that Sletuffe and R kleineisel reported above. With "junk", you mean problems with the map display, or just with the routing? Robx 07:43, 10 December 2008 (UTC)

There's some bug in mkgmap here -- we're writing zero length bitstreams. (I fed VIC_route.img through test.display.RgnDisplay, which still crashes on the file.) Looking into it. Robx 07:57, 10 December 2008 (UTC)

I've tracked down an error in the bitstream for some part of Silver City Highway. Could you upload the .mp source also? I looked at parts of the highway in JOSM and fixed a few bugs (a double node, some overlapping ways), but I don't think those are the problem. My first guess was we're overflowing the bitlength size field, but that shouldn't happen before ways with around 20k nodes. Robx 09:46, 10 December 2008 (UTC)

I'm uploading the MP source as we speak - here. The problem was the map itself was all massively garbled. That said, some others have tried the same file, and it seems to work OK, although apparently they can't search for roads, can search for POIs though (on a Nuvi260) -- Gaffa 10:22, 10 December 2008 (UTC)

Oh yeah - it's a pretty big area physically (but fairly empty of roads for the most part). Probably 400km x 400km. Standard mkgmap has been working perfectly for months -- Gaffa 10:24, 10 December 2008 (UTC)

I hope this has been fixed in r798. Robx 12:58, 10 December 2008 (UTC)

I tried again with the 806 version of mkgmap and the latest osm2mp from svn (this is about 6 hours ago) and still had no luck. This time, the map was fine at low zoom (120m) on a 60CSx, but the map went to junk at 200m and beyond. I haven't even got anywhere near routing yet... IMG files are same link as abovem but the MP source is different - will get that tomorrow -- Gaffa 11:28, 11 December 2008 (UTC)

Have you been running mkgmap.jar with assertions? Just to make sure you're not running into some known limitation. I'll take a look at the IMG files. Robx 11:40, 11 December 2008 (UTC)

I haven't. Let me dial into work and give it a fly -- Gaffa 12:00, 11 December 2008 (UTC)

Yep - that seemed to sort things out OK (interestingly, there was about 4Meg difference in file size - from 13 Meg to 17 meg). Thanks for that -- Gaffa 12:26, 11 December 2008 (UTC)

That's kind of bizarre. A failed assertion should cause mkgmap to abort as far as I understand things. If no assertion fails, I'd expect it to produce identical output... Did you change anything else? Robx 12:45, 11 December 2008 (UTC)

Are you sure VIC_route.img.zip linked above is up-to-date? I'm seeing exactly the same error as yesterday... Robx 13:00, 11 December 2008 (UTC)

Regardless, r809 might help: Now we're writing certain routing-related data only at level 0 (maximal zoom), which would explain why the map looks bad when zooming out. It's strange that this error should show up only in some images, though. Robx 21:04, 11 December 2008 (UTC)

The assertions option didn't stop, or throw any extra messages when I ran it... wierd. It looks like my ftp script is playingh funny buggers and not overwriting the file. I'm uploading newer versions of the IMG file now using a different FTP client -- Gaffa 23:16, 11 December 2008 (UTC)

crash bug

When I run osm2mp with a patch as in [1] (with the syntax adjusted), mkgmap dies on one input file:

Exception in thread "main" java.lang.IllegalArgumentException
       at java.nio.Buffer.position(Buffer.java:235)
       at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.position(BufferedImgFileWriter.java:84)
       at uk.me.parabola.imgfmt.app.SectionWriter.position(SectionWriter.java:57)
       at uk.me.parabola.imgfmt.app.net.TableB.write(TableB.java:90)
       at uk.me.parabola.imgfmt.app.net.RouteCenter.write(RouteCenter.java:110)
       at uk.me.parabola.imgfmt.app.net.NODFile.writeNodes(NODFile.java:106)
       at uk.me.parabola.imgfmt.app.net.NODFile.write(NODFile.java:76)
       at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:117)
       at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:76)
       at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:45)
       at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:148)
       at uk.me.parabola.mkgmap.CommandArgs$Filename.processArg(CommandArgs.java:355)
       at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:114)
       at uk.me.parabola.mkgmap.main.Main.main(Main.java:90)

The last log messages are:

2008/12/07 14:28:34 FEIN (RouteArc): val is 3f66
2008/12/07 14:28:34 FEIN (RouteArc): val is bf66
2008/12/07 14:28:34 FEIN (RouteCenter): node pos 1587958
2008/12/07 14:28:34 FEIN (RouteCenter): rewrite taba offset 1587958 2
2008/12/07 14:28:34 FEIN (RouteArc): val is 39c7
2008/12/07 14:28:34 FEIN (RouteArc): val is 3629
2008/12/07 14:28:34 FEIN (RouteArc): val is bfcc
2008/12/07 14:28:34 FEIN (TableA): tab a offset 1588105 tab a size 1100

--abunai 13:34, 7 December 2008 (UTC)

Can you try the following patch? nio.Buffer.position can fail if the argument is less than zero or larger than its current limit. The former could occur if we overrun int, but I don't think that's happening.

Index: src/uk/me/parabola/imgfmt/app/net/TableA.java
===================================================================
--- src/uk/me/parabola/imgfmt/app/net/TableA.java	(revision 780)
+++ src/uk/me/parabola/imgfmt/app/net/TableA.java	(working copy)
@@ -147,7 +147,8 @@
 		int size = arcs.size() * ITEM_SIZE;		
 		log.debug("tab a offset", offset, "tab a size", size);
 	
-		writer.position(writer.position() + size);
+		for (int i = 0; i < size; i++)
+			writer.put((byte) 0);
 	}
 
 	/**
Index: src/uk/me/parabola/imgfmt/app/net/TableB.java
===================================================================
--- src/uk/me/parabola/imgfmt/app/net/TableB.java	(revision 780)
+++ src/uk/me/parabola/imgfmt/app/net/TableB.java	(working copy)
@@ -87,7 +87,8 @@
 	public void write(ImgFileWriter writer) {
 		offset = writer.position();
 		int size = nodes.size() * ITEM_SIZE;
-		writer.position(offset + size);
+		for (int i = 0; i < size; i++)
+			writer.put((byte) 0);
 	}
 
 	/**

Cheers, Robx 17:46, 7 December 2008 (UTC)

Works. --abunai 18:28, 7 December 2008 (UTC)

This is in SVN now. Thanks for reporting. Robx 09:53, 8 December 2008 (UTC)

unexpected crash, looks like the above

I ran this :

java -jar osmosis.jar --read-xml france.osm --bounding-box left=4.92 right=6.92 top=46.57 bottom=44.57 --write-xml test-2x2.osm
perl osm2mp.pl test-2x2.osm > test-2x2.mp
java -enableassertions -Xmx1512M -jar ./mkgmap-nod/mkgmap.jar  --route --gmapsupp test-2x2.mp

And mkgmap fails with :

Exception in thread "main" java.lang.AssertionError
        at uk.me.parabola.imgfmt.app.net.RoadIndex.write(RoadIndex.java:45)
        at uk.me.parabola.imgfmt.app.net.RoadDef.writeLevelDivs(RoadDef.java:158)
        at uk.me.parabola.imgfmt.app.net.RoadDef.writeNet1(RoadDef.java:114)
        at uk.me.parabola.imgfmt.app.net.NETFile.write(NETFile.java:61)
        at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:119)
        at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:76)
        at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:45)
        at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:148)
        at uk.me.parabola.mkgmap.CommandArgs$Filename.processArg(CommandArgs.java:355)
        at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:114)
        at uk.me.parabola.mkgmap.main.Main.main(Main.java:90)

I'm using the last svn version of... now the test mp file is located here (My sand box is here with files) I have no problem with the same center and a 1°x1° square, so something looks wrong somewhere around Sletuffe 20:12, 8 December 2008 (UTC)

This is a problem I thought I'd fixed... RoadIndex.write asserts that it's small enough to fit into a byte, which implies that we write at most 256 polylines in a subdivision elsewhere. I've copied to the mailing list since I don't know what's going wrong here. You might try reducing MAX_NUM_LINES in mkgmap/builder/MapSplitter.java. Cheers Robx 21:56, 8 December 2008 (UTC)

I don't know what this is supposed to do, but going from 0x100 to 0x50 solved the crash, I'll check the generated img file Sletuffe 23:57, 8 December 2008 (UTC)

Ok the 2°x2° img file is working well on my 60cx. But much bigger files (~20Mo) on a quarter of france generate buggy results such as vertical or horizontal roads, graphical strange things.Has anyone got good result in generating image file that big ? Sletuffe 14:31, 9 December 2008 (UTC)

I see the same effect: "--bounding-box left=9.6 right=11.1 bottom=49.3 top=50.1" works fine, "--bounding-box left=8.8 right=11 bottom=49 top=50.6" gives me a buggy map. --R kleineisel 15:25, 9 December 2008 (UTC)

There was an ugly bug causing parts of RGN to be overwritten once it grew above about 4MB. Should be fixed in r798. Robx 12:57, 10 December 2008 (UTC)

Yeah ! It's fixed, I'm now able to produce quite huge image file of up to 30Mo without crash or buggy effects (version of now).

Now we "just" need to be able to merge serveral image with routing to cover europe ;-) Sletuffe 17:14, 12 December 2008 (UTC)

Great!

Actually, merging several images shouldn't be that hard. All that's needed is something like osmcut that introduces marked extra nodes on the boundary. From my tests, these boundary nodes probably shouldn't coincide with junctions. It would then be easy to adapt osm2mp to write the required data to the .mp-file. Robx 18:48, 12 December 2008 (UTC)

My comments

Great work!

Some observations:

• The distance calculated for the routes is wrong. My 9 km commute is shown as 36 km.

I have the same problem with the Venture Cx. --Nils 09:50, 7 December 2008 (UTC)

A factor of 4, also? Robx 18:02, 7 December 2008 (UTC)

I noticed that my Legend HCx showed on the routing instructions page the longest leg to be some 28 kilometers. When looking the straight distance, it was about 7 kilometers. The factor of 4 would fit here also. --Japa-fi 06:57, 8 December 2008 (UTC)

SVN now has an updated factor. Does this fix route length for you? Robx 10:06, 9 December 2008 (UTC)

::::: In my quick test with the precompiled binary linked on main page (version 735-svn) seems to have correct distances. With the displayed figures I would not suspect there is any error. --Japa-fi 19:35, 11 December 2008 (UTC)

• access=no is not observed.

The access and codepage problems lie with osm2mp. You can fix the motorways easily by editing poly.cfg: the last six flags should probably be inverse to those for highway=pedestrian.

Finally, the distance problem is very interesting. I'm getting mostly correct distances here, but we've seen different units for encoding the distance. How large is your extract? Does the problem persist if you reduce it just cover your commute? Another possible source of error: are the roads involved mostly straight? There's some "curviness" data we don't quite understand and don't currently write.

Thanks for testing! Robx 08:46, 7 December 2008 (UTC)

The extract was a 1x1° tile, but I get the same result with smaller data sets. I just downloaded a small area with a .02x.02° bounding box, and it gives me a 3.4 km distance for a point about 1 km away. The route uses 7 pretty ordinary residentials. (Device is a Legend HCx.) --abunai 10:35, 7 December 2008 (UTC)

Switching maps on the StreetPilot i3

This may apply to other Garmin units - mybe people could investigate and contribute findings...

Basically, if you rewrite the µSD card to switch between Garmin's own maps and ones created by mkgmap, then the first time you try and use the new maps the Garmin forgets three system settings:

1) The timezone (reverts to one of the U.S. timezones - forget which one).
2) The 'time format' (reverts to U.S. style 12hr clock with am/pm indicator (yuk!)).
3) The 'measurement units' (reverts to U.S. style miles & feet (yuk!)).

Anyone else getting this? Strangely the other settings seem to stay as I set them. Steve Hosgood 10:12, 23 January 2009 (UTC)

OK, I'd just like to close this report as "Bogus"! What really happens is that the Streetpilot forgets the afore-mentioned settings *if* you power it on without the µSD card fitted and then plug the card in 'hot'. You don't have to change the maps on the card since the previous time you used the unit. Steve Hosgood 00:02, 7 February 2009 (UTC)

Building

- Bit more documentation for dummies please. I was able to follow the first step of obtaining the source. reading Makefile I understood that ant is required to build the mkgmap.jar. Running "ant" did something which by the messages I would assume being success, but did not produce mkgmap.jar . How to create mkgmap.jar?

There is a link to download an allready compiled version, that should save you time ! Sletuffe 18:12, 6 December 2008 (UTC)

Found that, run into problem with osm2mp as described on the routing main page --Japa-fi 19:29, 6 December 2008 (UTC)

Otherwise, you'd want to run ant dist, which should leave mkgmap.jar in dist/. Robx 20:20, 6 December 2008 (UTC)

Routing only supported in branch, not in current snapshots

Please make it really obvious that the --route option is only working in the special "-nod" subversion branch and not in the daily mkgmap snapshots. The problem is that the current snapshots actually accept the "--route" option without any error message, and they, too, can read .mp files but do not produce any useful output with them. --Wg1 18:10, 17 December 2008 (UTC)

Pink line of death

Notes

• cGPSmapper compiles the same .mp-files fine
• not caused by crossing city boundary
• not caused by errors in OSM data
• related to long polylines or lines with many nodes
• probably unrelated to oneway streets

Examples

Example by Carluti

I have generated a map from this area here of South West Spain and loaded it into a Garmin Nuvi 300. If I try to go from somewhere in this area here to this petrol station here GPS starts leading correctly, but after leaving a roundabout at this point here, GPS abandons the road and jumps in a straight line to a point back in the route more than 13 km away and finally GPS crashes. It happens if I simulate the route. When I drive the same route, GPS starts recalculating the route after passing the "conflict" point and finally it says "Error calculating the route". If I drive in the opposite direction, it also jumps from the same points.

In other cases, route is completely erratic, as you can see in example below

--Carluti 15:30, 21 January 2009 (UTC)

Broken-down sample .mp

Sorry I don't know which mailing list. Instead of it you can find it here User_talk:Papaluna Starting with polyline trackpart_26 the problem occurs if you try to route into this part. If you only route into trackpart_25 everything seems to be ok. --Papaluna 14:09, 6 February 2009 (UTC)

Erroneous routing

• (2) I drove here coming from east on the ST2260 and the route led me onto the A3 westbound. The left turn in Attelsdorf looked completely buggy: the eTrex' routing information text ("turn left ...") was correct, but the purple route drawing and the turn arrow were pointing to the right.

• (3) When driving on the A3 here eastbound the route suddenly pointed off the road. I continued on the motorway and the eTrex tried to recalculate the route again and again. --R kleineisel 09:11, 10 December 2008 (UTC)

• (5) At this road crossing routing from north to east will not go correct through the crossing.

• (6) Another strange thing: I entered a route starting near Tennenlohe, entering the A3 motorway on exit 84, north-west bound like this. I checked the purple route drawing before setting off, everything looked fine, the route ran along the motorway. After I had entered the motorway the eTrex recalculated the route and the result was a straight line between somewhere before the motorway exit 84 to a point on a small road near the destination. --R kleineisel 12:01, 17 December 2008 (UTC)

When driving along route (6) the route is calculated correctly as long as I'm still not on the motorway. As soon as I am on the motorway it recalculates and the result is buggy (straight line starting somewhere behind me). This persists until right before the motorway exit 78. After leaving the motorway everything is fine: It recalculated correctly right on the exit ramp. --R kleineisel 15:07, 19 December 2008 (UTC)

Turn Right Half Way Ferry Crossing

I have just tried routing from my home location to Fawley. The suggested route took me onto the Southampton to Cowes ferry, and then suggested I take a right turn when adjacent to Fawley. This may be the shortest/quickest route, but if I was going to swim, I may as well have swam the whole route directly accross Southampton Water. :-)

I suspect that it couldn't calculate a route to the destination, and just routed as close as it could get. You may want to try a current version (nod branch) -- there was some discussion about ferries on the mailing list. Robx 11:19, 11 February 2009 (UTC)

Routing across tiles

• The file is bigger than without routing so france.osm.bz2 stopped to fit in one single img file (I'll try cutting things in pieces as suggested on the mkgmap page)

* Routing across more than one tile will be difficult -- the boundary nodes will need to be marked in the .mp-file, and I don't think osm2mp does that. It's also entirely untested.

Some areas of the world are so densely mapped that using very small tiles is needed. I guess there is no support yet to provide routing across different tiles, effectively making any routing capability useless in these areas. But is there a roadmap towards solving this? Are there specific tasks to be addressed before this can happen? --Lambertus 14:59, 9 January 2009 (UTC)

It looks like the only thing that needs to be done is to be able to identify the nodes that are on the boundry [2]. I have a plan for doing this when we go to working with .osm files. I believe that it already works if the .mp files contain the right information, although I've not tried it myself. ..Steve

Thanks for the heads-up, that mailinglist contains a lot of valuable information. --Lambertus 18:57, 12 January 2009 (UTC)

Today, I tried splitting finland.osm.bz2 with splitter.jar and running mkgmap ... --gmapsupp --route -c template.args with mkgmap r901. The Edge 705 successfully routes within a tile, but unfortunately I live close to a tile boundary, and an attempt to route across the boundary to a place 10 km away will fail. The progress bar will grow to 100%, stay there for a few minutes, and finally the Edge will complain that it ran out of memory. A workaround might be to choose the tiles differently, but I couldn't find the splitter source repository to see how it might be done. Steve, I guess this is still work in progress in mkgmap? --Skela 20:30, 17 February 2009 (UTC)

It is being discussed on the mailing list at this very moment :) I am hopeful that it will work soon. --AcousticNewt 22:33, 17 February 2009 (UTC)

Turn restrictions

This patch implements turn restrictions from osm input. Robx 21:23, 24 February 2009 (UTC)

Relations Question

Have a lot at this relation here. Is there a way to procede this ? Can garmin route this ? --Flacus 09:06, 20 December 2008 (UTC)

Garmin should be able to do this. So far, we have only decoded simple from-via-to relations without on/off-times, but given a sample map that has time-based restrictions, it should be possible to work those out. There's untested code in SVN to write the simple relations, but they're not currently being created (the .mp-parser doesn't know about relations yet, for instance). Robx 18:05, 21 December 2008 (UTC)