gpx track files do not work on routable maps
Hi, I have an issue with OSM maps converted using --route and GPX track files, on an Edge 705. When reloading a "Saved Ride" (a GPX track file) on the GPS, the Begin and End points are superimposed (at the location of the End point on the map). I tried with many GPX files, some created on GPsies, some on Bikehike, using various routes (some with cycle ways, some others with only main roads) with the same result. This does not occur with the stock Garmin City Navigator NT maps, or with OSM maps compiled without the --route option (I guess this is normal, it does not do a proper routing in that case). The strange thing is that the routing "on the fly" (using "Where to?" of the GPS unit) works well and uses cycleways as legitimate routes. But using a saved GPX track file fails. This happens with maps compiled using "java -jar mkgmap-r2226/mkgmap.jar --route --gmapsupp -c template.args", no other options are used. Is it a problem with the routing building? Or am I doing something wrong? Thanks, Eric
I have been able to do further testing on my Edge 705. Although the routing "on the fly" works on the unit, I cannot reliably use a GPX track file, either created from a mapping website or using a previous ride in the device history. Either the Begin and End points merge, either the pink line is truncated at some point and goes directly to the end (a bit like a ferry or tunnel transit). Reverting to Garmin City Navigator gmapsupp.img map, none of this happens: routing works correctly, even on cycle lanes that do not appear on the City Navigator map (the pink line just goes through the ground until it reaches another road - correctly). Could it be a problem in the route building in mkgmap? I had a look at the code, and identified some files where the route are built, but I would like to know more how this works. Is there any way I can help improve it? Eric
I have been able to do further testing on my Edge 705. Although the routing "on the fly" works on the unit, I cannot reliably use a GPX track file, either created from a mapping website or using a previous ride in the device history. Either the Begin and End points merge,
That is very strange, does anyone else see that on any other device?
Could it be a problem in the route building in mkgmap? I had a look at the code, and identified some files where the route are built, but I would like to know more how this works. Is there any way I can help improve it?
The routing network that is produced is like a simplified version of the roads in the map, with only links between the different roads. There is extra information about the kind of road, expected speed, various restrictions etc. There are two stages, first to get the information from the OSM data, which is in some ways the hardest part. There is then how it is represented in the map tile, which is of course complicated by the fact that the format is only partially understood. The only documentation of what is known about this format apart from the code is at: http://svn.parabola.me.uk/display/trunk/doc/nod.txt Actual routing is done by the device, so is entirely out of our control. ..Steve
Hi Steve, Thank you for your detailed anser. 2012/3/4 Steve Ratcliffe <steve@parabola.me.uk>:
That is very strange, does anyone else see that on any other device?
To help track down the issue, I am uploading a map of oxfordshire created today at http://files.mkgmap.org.uk/. The gmapsupp.img was generated using: java -jar mkgmap-r2235/mkgmap.jar --route --remove-short-arcs --gmapsupp oxfordshire.osm.pbf. I also upload two GPX track files for testing, one is very short but leads to having Begin and End at the same place, the other one is a GPX track downloaded from http://www.bikemap.net/route/609987 (Saturday evening sprint). Can you please let me know if they do route correctly on your device?
Actual routing is done by the device, so is entirely out of our control.
I reckon that, but the thing is, routing with these GPX files works properly (with the two GPX files I uploaded) with the City Navigator map from Garmin, and despite all routes (such as Cycleways) are not displayed! This suggests the routing build routine must be missing something? Eric
I reckon, you don't really understand the difference between a route and a track. Routing never works on GPX files. And if routing on city navigator works on ways that are invisible, then that routing actually happens on another map, but not on city Navigator. (and also don't confuse searching for addresses with routing). And note, round-routes are not working on Garmin GPS. Leave at least 100m between Start and Finish distance. Maybe on OSM maps, there are more roads/highways there - so the GPS directly goes from Start to Finish, instead of stickign to the route, whereas with City Navigator - missing highways lead the GPS to go the intended way. General rule: don't activate more than 1 routable map of the same area, and leave at least 100m, better 200-300m distance between Start and Finish of a route // track for trackback. On 05.03.2012 12:06, Eric Fernandez wrote:
Hi Steve,
Thank you for your detailed anser.
2012/3/4 Steve Ratcliffe<steve@parabola.me.uk>:
That is very strange, does anyone else see that on any other device?
To help track down the issue, I am uploading a map of oxfordshire created today at http://files.mkgmap.org.uk/. The gmapsupp.img was generated using: java -jar mkgmap-r2235/mkgmap.jar --route --remove-short-arcs --gmapsupp oxfordshire.osm.pbf. I also upload two GPX track files for testing, one is very short but leads to having Begin and End at the same place, the other one is a GPX track downloaded from http://www.bikemap.net/route/609987 (Saturday evening sprint). Can you please let me know if they do route correctly on your device?
Actual routing is done by the device, so is entirely out of our control. I reckon that, but the thing is, routing with these GPX files works properly (with the two GPX files I uploaded) with the City Navigator map from Garmin, and despite all routes (such as Cycleways) are not displayed! This suggests the routing build routine must be missing something?
Eric _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
2012/3/5 Felix Hartmann <extremecarver@gmail.com>:
I reckon, you don't really understand the difference between a route and a track. Routing never works on GPX files.
GPX track and GPX route should both allow navigation on the Edge, as explained here: http://ridewithgps.com/edge_705. The problem with GPX route is that it is limited in number of points. GPX track is preferable. It is a course file (TCX) which does not allow navigation actually.
And if routing on city navigator works on ways that are invisible, then that routing actually happens on another map, but not on city Navigator. (and also don't confuse searching for addresses with routing). And note, round-routes are not working on Garmin GPS. Leave at least 100m between Start and Finish distance.
This does not change anything, I have an Oxford to Blenheim palace GPX track which behaves the same way (the begin overlays the end point at Blenheim palace). This is puzzling indeed. Thanks for your advice, Eric
Hi
To help track down the issue, I am uploading a map of oxfordshire created today at http://files.mkgmap.org.uk/. The gmapsupp.img was generated using: java -jar mkgmap-r2235/mkgmap.jar --route --remove-short-arcs --gmapsupp oxfordshire.osm.pbf. I also upload two GPX track files for testing, one is very short but leads to having Begin and End at the same place, the other one is a GPX track downloaded from http://www.bikemap.net/route/609987 (Saturday evening sprint). Can you please let me know if they do route correctly on your device?
Thanks. On my device they are just tracks and not routes. I've seen Felix's message and your reply, so perhaps the Edge is just different in that way. The track looked fine and was the same as the website map at first glance. The only way to get more clues is to find the shortest track that doesn't work and a very similar one that does and see if there is anything strange about the difference. And you might have to find lots of working/not working pairs to see if there is anything common between the differences. If it doesn't work for any track at all, then I would have no idea about how to even find out what is happing. ..Steve
Hi,
Thanks. On my device they are just tracks and not routes. I've seen Felix's message and your reply, so perhaps the Edge is just different in that way.
The track looked fine and was the same as the website map at first glance.
Many thanks Steve for looking into it. Indeed, the Edge can accept both GPX track and GPX route formats (as described in http://cycleseven.org/gps-waypoints-routes-and-tracks-the-difference). They are almost the same, but GPX track offers better navigation on the Edge. As you say, this could be a peculiarity with the the Edge, although the Garmin maps work fine, suggesting there may be something missing in the routing format. The funny thing is that I can display the track correctly on the map (as a dotted line), showing that the Edge correctly reads the file itself. But the routing fails when using an OSM generated with mkgmap.
The only way to get more clues is to find the shortest track that doesn't work and a very similar one that does and see if there is anything strange about the difference. And you might have to find lots of working/not working pairs to see if there is anything common between the differences.
I have started to do that, but have a lot of trouble in finding a GPX that works. "Where to" navigation does work, but there seem to be some issue in recording the route. I also tried several firmware versions with the same result. It is a pity we do not know how the edge works internally to calculate routes! I'll try to find a case study with working and not working tracks then. Thank you, Eric
Steve, Can you please let me know which files/functions in mkgmap source code are responsible for building the route code? I had a look at the code and am prepared to try playing with the code too, but would need a (very brief) pointer on where to start. Many thanks in advance, Eric
On 05/03/12 16:31, Eric Fernandez wrote:
The funny thing is that I can display the track correctly on the map (as a dotted line), showing that the Edge correctly reads the file itself. But the routing fails when using an OSM generated with mkgmap.
Do you mean that on the edge you can use the track as a route and that fails, or that any route you try to follow is broken by the presence of the track? ..Steve
Do you mean that on the edge you can use the track as a route and that fails, or that any route you try to follow is broken by the presence of the track?
No. When you want to navigate a GPX trak file, you have the possibility to show it on the map as track points, without navigation. This works. But when you selet "naigate" after you select that GPX tack file then the routing fails: the pink line that represents the calculated route is wrong (either Begin overlays End, or there is a bit of route but it is interupted). Also, I can record a path using the Edge. When I try to renavigate the same path (stored in history) the navigation is wrong too. But if I switch back to Garmin City map, then it navigates properly. Have you some navigation function on your device? Are there other Edge users on this ML? Eric
On Mon, Mar 05, 2012 at 07:38:36PM +0000, Steve Ratcliffe wrote:
Do you mean that on the edge you can use the track as a route and that fails, or that any route you try to follow is broken by the presence of the track?
The Edge 705 can 'navigate' or 'display' a GPX track. I have usually used the 'display' setting. I do not remember that 'navigate' would be broken. It just takes some time to calculate the route along the track. Could it be that some way segment is missing or unrouteable on the map? The Edge 705 can also display a 'virtual partner' and a 'activity tcx' (or was it 'course tcx'?) on the map. That one would use turning prompts that are embedded in the file, as far as I understand. I have used this TCX feature only a couple of times. On longer bicycle trips, I had the Edge display a downloaded GPX route on the map and let it calculate a route (car, shortest distance), mainly out of curiosity. The bicycle routing only works well for a few kilometers of distance. The Edge 705 is my only Garmin device. Its main use case was recording routes. Last November, the USB interface broke, and I could not figure out how to save routes directly to the SD card. I got a SonyEricsson Xperia Active as a replacement. The GPS sensor feels a little less accurate, and the offline routing on OsmAnd has a long way to go. Once the snow melts and I can do longer bicycle trips, I might still use the Edge for navigation. Best regards, Marko
Once the snow melts and I can do longer bicycle trips, I might still use the Edge for navigation.
Best regards,
Marko
Hi Marko, Would you mind trying the map and GPX I uploaded at http://files.mkgmap.org.uk/ and let me know if you observe the same issue? Do you build your own OSM maps with mkgmap too? If yes, which options are you using? Many thanks. Eric
Hi, I have another question regarding this problem: could the navigation issue on the Edge come from the (default) style instead of the NOD building algorithm? Thanks, Eric
Hi Eric,
Would you mind trying the map and GPX I uploaded at http://files.mkgmap.org.uk/ and let me know if you observe the same issue?
I am a bit busy at work currently. It might be easier for me to try it with a GPX file that is near my place (Finland). I know I can fake the location by keeping the Edge out of satellite view, setting the location when the dialog pops up, and then switching to demo mode. I guess that you are referring to the file bh_road3.gpx <http://files.mkgmap.org.uk/detail/57>. How did you create it?
Do you build your own OSM maps with mkgmap too? If yes, which options are you using?
I am using the default style. Currently, I only use one map layer, because multiple layers do not work with --index. My scripts and map are at http://www.polkupyoraily.net/osm/.
I have another question regarding this problem: could the navigation issue on the Edge come from the (default) style instead of the NOD building algorithm?
It is of course possible. The Edge 705 bicycle routing algorithm is corners. It will only route the first and last mile or two via cycleways. For the middle part of the route, it will ignore the cycleways. If the 'car roads' say bicycle=no (because there is a cycleway next to them), then the Edge could send me to a very long detour (100 km or 60 miles at least) along less busy roads. Best regards, Marko
Hi Marko, Many thanks for your input and your help. The bh_road3.gpx file was generated using bikehike and downloaded as a GPX track file. It is a very short section in Oxford. I have now tested other GPX files from bikemap.net with the same issue. I found one interesting: http://www.bikemap.net/route/940030. The routing almost work perfectly (using cycleways) until the very last end: at around N55 degrees 27.922' / W003 degrees 39.085' then the navigation jumps in a straight line to the end (going through fields/unmarked areas). I have uploaded the file at http://files.mkgmap.org.uk/detail/59 . I also tried plenty of GPX generated in London with the same issue: on Garmin map, they work fine, on OSM they are broken and go through buildings. When you have the time, can you try use http://www.bikemap.net and find routes in Finland, and see if the exported GPX versions works properly on OSM? Many thanks, Eric
Hi, This may be a stupid question, but is there any way to extract Garmin's default styles from their gmapsupp.img file? This would allow me distinguish between style problems and NOD building issue. Thanks, Eric
Am 07.03.2012 13:21, schrieb Eric Fernandez:
Hi,
This may be a stupid question, but is there any way to extract Garmin's default styles from their gmapsupp.img file? This would allow me distinguish between style problems and NOD building issue.
Thanks, Eric _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, you could extract the style from mkgmap.jar Henning
2012/3/6 aighes <osm@aighes.de>:
Am 07.03.2012 13:21, schrieb Eric Fernandez:
Hi,
This may be a stupid question, but is there any way to extract Garmin's default styles from their gmapsupp.img file? This would allow me distinguish between style problems and NOD building issue.
Thanks, Eric _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, you could extract the style from mkgmap.jar
Henning
Hi, I meant extracting the style used by Garmin to create their City Navigator img map file, not from the mkgmap default. Is that what you mean? Thanks, Eric
Ok,, so I missunderstood you. You can extract the TYP-File and get information about which ID is rendered eg. as residential. This should be possible with gmt.exe or so. Henning
On Wed, Mar 07, Eric Fernandez wrote:
2012/3/6 aighes <osm@aighes.de>:
Am 07.03.2012 13:21, schrieb Eric Fernandez:
Hi,
This may be a stupid question, but is there any way to extract Garmin's default styles from their gmapsupp.img file? This would allow me distinguish between style problems and NOD building issue.
Thanks, Eric _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, you could extract the style from mkgmap.jar
Henning
Hi,
I meant extracting the style used by Garmin to create their City Navigator img map file, not from the mkgmap default. Is that what you mean?
Garmin is not using mkgmap to create their City Navigator maps. Which means that such a style does not exist. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Wed, Mar 07, 2012 at 11:15:33AM +0000, Eric Fernandez wrote:
The routing almost work perfectly (using cycleways) until the very last end: at around N55 degrees 27.922' / W003 degrees 39.085' then the navigation jumps in a straight line to the end (going through fields/unmarked areas).
That one does ring a bell. If you disable or remove the gmapsupp.img (Settings/Map, uncheck the box, or remove or rename the file), do you see a way on the base map (gmapbmap.img) where the straight line is? Or, if you rename the gmapbmap.img to something else, do you get a 'route calculation error' instead of the straight line? One possible explanation is that there is an unconnected junction (two fully or almost overlapping nodes in the junction, or missing connection in a T junction) or that there is a highway=pedestrian area that is not being translated as a routeable way, but only as a polygon.
This may be a stupid question, but is there any way to extract Garmin's default styles from their gmapsupp.img file? This would allow me distinguish between style problems and NOD building issue.
You mean, reverse engineer the style definitions from Garmin's commercial maps? It should be about as easy as unscrambling an egg. :-) Have you tried different routing options? Instead of bicycling, try car (shortest route). Then it should ignore any cycleways or plazas that might be broken in the OSM data. I should have a little more time in a week or two. Marko
2012/3/7 Marko Mäkelä <marko.makela@iki.fi>:
On Wed, Mar 07, 2012 at 11:15:33AM +0000, Eric Fernandez wrote:
The routing almost work perfectly (using cycleways) until the very last end: at around N55 degrees 27.922' / W003 degrees 39.085' then the navigation jumps in a straight line to the end (going through fields/unmarked areas).
That one does ring a bell. If you disable or remove the gmapsupp.img (Settings/Map, uncheck the box, or remove or rename the file), do you see a way on the base map (gmapbmap.img) where the straight line is?
No, there is an empty field on the basemap when it breaks navigation. If I recalculate using the basemap only, then the straight line starts a bit before. Note that my lock on road option is "off". Is that a problem?
Or, if you rename the gmapbmap.img to something else, do you get a 'route calculation error' instead of the straight line?
Now that is interesting ! Without a basemap at all, but using the the OSM/gmapsupp.img map, then navigation is a lot better! Indeed there are still some glitches and break lines (unconnected junctions?), but not as dramatic as before. bh_road3.gpx is still broken (Begin and End overlap) but for many other longer ways, the navigation is a lot more accurate and go through GPX track points. I still spotted broken lines, but they were vary rare now. This might suggest some kid of interference betwen the stock Garmin basemap and the OSM map generated with OSM. Could it be a kind of priority between the maps? I am aware of --draw-priority, but this is for drawing only, isn't it? It is strange, it is as if the Edge were using both the mapsource and the basemap to calculate navigation, instead of relying on the most detailed map!! Besides, can you tell me what the version of your basemap on your Edge 705 is? Also, would it be possible to create a very simplified basemap from OSM for the Garmin? Maybe that would prevent this issue by having more consistency? But really the Edge should ignore the basemap entireley when a mapsource is available!
One possible explanation is that there is an unconnected junction (two fully or almost overlapping nodes in the junction, or missing connection in a T junction) or that there is a highway=pedestrian area that is not being translated as a routeable way, but only as a polygon.
Possible, but the problem occured on all GPX files I tried with our without cycleways, including very short junctions (bh_road3.gpx) for instance. I have another idea: is it possible to make all roads equivalent in the style file? Just to see how navigation works? I suppose this is stated in the "lines" file?
Have you tried different routing options? Instead of bicycling, try car (shortest route). Then it should ignore any cycleways or plazas that might be broken in the OSM data.
Well the problem looks similar, but it might be because I used --ignore-turn-restrictions --ignore-maxspeeds in my options. This might mess up the car setting? I'll try again without them.
I should have a little more time in a week or two.
Thank you very much. Do not hesitate to contact me in case you want me to do further testing. Kind regards, Eric
Hi, I have done further tests that show that indeed there is something happening at the level of routing depending on the basemap installed "under" the OSM map. I purchased my Edge 705 second hand, and the seller updated the basemap to the Garmin Worldwide Autoroute DEM Basemap NR 5.01 (41MB). The stock basemap (as found on the CD) was actually the "Atlantic Routable Highway Basemap v3 3.00" (12MB). When I replaced the DEM NR 5.01 gmapbmap.img with the RHB v3, then navigation from GPX files was close to perfect! To confirm this, I downloaded other basemaps available from Garmin website and got this result: 1. From iQue 3600 = World Routable Highway Basemap v3 3.00 (30MB) -> navigation is messed up 2. From XT Mobile = World Autoroute Basemap v4.01 (30MB) -> navigation is messed up 3. From XT Free Non routable = Worldwide Roads Basemap Basemap v2 -> navigation works! Lessons learnt: there seems to be an issue with more recent basemaps on the Edge 705, which interfere with navigation using an OSM generated with mkgmap. Note that when a basemap leads to issues, the navigation is correct with both OSM alone or basemap alone, but not together! Still, there are some glitches with short tracks or line breaks, but they may be entirely different issues. For Edge owners, I would appreciate if you could let me know which basemap version you have (it is displayed at start up, quite quickly). Thanks, Eric
On Wed, Mar 07, 2012 at 04:36:15PM +0000, Eric Fernandez wrote:
For Edge owners, I would appreciate if you could let me know which basemap version you have (it is displayed at start up, quite quickly).
The USB interface on my Edge 705 is broken, but I have a copy of the file system image (which I patched together after the device corrupted its internal FAT file system about a year ago for the first time). There I have the following world basemap: GMAPBMAP IMG 6418432 2009-11-24 23:49 mtype -i /tmp/1g.bin ::garmin/gmapbmap.img|md5sum f0ec7649096a9b388fded7d7604174b6 - Best regards, Marko
2012/3/7 Marko Mäkelä <marko.makela@iki.fi>:
The USB interface on my Edge 705 is broken, but I have a copy of the file system image (which I patched together after the device corrupted its internal FAT file system about a year ago for the first time). There I have the following world basemap:
GMAPBMAP IMG 6418432 2009-11-24 23:49
mtype -i /tmp/1g.bin ::garmin/gmapbmap.img|md5sum f0ec7649096a9b388fded7d7604174b6 -
Best regards,
Marko
Hi Marko, Many thanks. My file is different: $ ll /media/GARMIN/Garmin/gmapbmap.img.orig -rw-r--r-- 1 eric users 13123584 16 févr. 2011 /media/GARMIN/Garmin/gmapbmap.img.orig $ md5sum /media/GARMIN/Garmin/gmapbmap.img.orig 293d3c96fed262fc80298dd8114fb115 /media/GARMIN/Garmin/gmapbmap.img.orig Marko: I have seen in the archives that you also reported that the base map interfered with navigation on the Edge 705! Have you been able to better understand the issue and correct it? Or have you removed the base map entirely? The difficulty here is that we may see several types of errors: - errors in OSM itself - interference between maps - buggy navigation algorithm of the 705. I believe that relying on one map only may be the way forward anyway. Kind regards, Eric
Hi again, Unfortunately, I can confirm that there are navigation problems with OSM maps compared to Garmin map (City Navigator) with some GPX files in complex areas, even when the base map is deleted. Possibly the routing data structure, which is not entirely understood, is missing some things. Eric
On Wed, Mar 07, 2012 at 08:13:55PM +0000, Eric Fernandez wrote:
Many thanks. My file is different:
$ ll /media/GARMIN/Garmin/gmapbmap.img.orig -rw-r--r-- 1 eric users 13123584 16 févr. 2011 /media/GARMIN/Garmin/gmapbmap.img.orig
Do you want to have a copy of my file?
Marko: I have seen in the archives that you also reported that the base map interfered with navigation on the Edge 705! Have you been able to better understand the issue and correct it?
No, I was satisfied with my hypothesis (that the OSM data was to be blamed; there was a 'routing island').
Or have you removed the base map entirely?
I cannot access the internal file system of my Edge 705 any more. The gmapbmap.img is there. I do not dare to use the device for recording traces, because I fear that it could corrupt the internal FAT again, and without a working USB interface, I cannot fix it. The only way I can control my Edge is by uploading maps or GPX or TCX files to the SD card.
The difficulty here is that we may see several types of errors: - errors in OSM itself - interference between maps - buggy navigation algorithm of the 705.
Can you load the area around the route to JOSM and check that the ways that were replaced by the straight line are connected as they are supposed to be? That would rule out errors in OSM data.
I believe that relying on one map only may be the way forward anyway.
I believe that the future belongs to the likes of OsmAnd. Their routing data structures probably are much worse than Garmin's, because OsmAnd can only calculate very short routes. But within a couple of years, it will be there. (Or, nobody else expect me has an issue with asking a remote server how to get from point A to point B.) Marko
Hi Marko, 2012/3/7 Marko Mäkelä <marko.makela@iki.fi>:
On Wed, Mar 07, 2012 at 08:13:55PM +0000, Eric Fernandez wrote:
Many thanks. My file is different:
$ ll /media/GARMIN/Garmin/gmapbmap.img.orig -rw-r--r-- 1 eric users 13123584 16 févr. 2011 /media/GARMIN/Garmin/gmapbmap.img.orig
Do you want to have a copy of my file?
Thank you, I could try it, although I am pretty sure this will not affect the routing too much. I now use the 705 without any base map and find it more reliable. I do not know any instance where the base map "improves" navigation, I only found out it may make it worse. I might be wrong though. I can provide you with mine too, but I understand you would not be able to upload it.
Marko: I have seen in the archives that you also reported that the base map interfered with navigation on the Edge 705! Have you been able to better understand the issue and correct it?
No, I was satisfied with my hypothesis (that the OSM data was to be blamed; there was a 'routing island').
Could be worth it to try, but again you cannot do it anymore.
Can you load the area around the route to JOSM and check that the ways that were replaced by the straight line are connected as they are supposed to be? That would rule out errors in OSM data.
I had a look indeed and could not find any error using the OSM online editor potlatch 2.
I believe that the future belongs to the likes of OsmAnd. Their routing data structures probably are much worse than Garmin's, because OsmAnd can only calculate very short routes. But within a couple of years, it will be there. (Or, nobody else expect me has an issue with asking a remote server how to get from point A to point B.)
That is interesting. I tried OsmAnd on my Nexus S and indeed it is a very interesting piece of software. I even could do long routing (Oxford to London) and it seemed to work. The fact it uses OSM and is open source ticks all the boxes for me. The only issue I see with it: - a smartphone is not as rugged as a GPS device like the Edge. I am aware of mounts and casings, but they are certainly not ideal - battery life is really too short on a smartphone. A Nexus S using GPS has low autonomy compared to the Edge. Ideally, we would need proper GPS units that can accept not only OSM but also external routing applications. Do you know any of them? Kind regards, Eric
Hi, I also made an interesting discovery using Garmin City Navigator maps. I reported that GPX track files were working properly with Navigation. Although navigation works indeed better than with OSM/mkgmap maps, they are not exempt of issues. Take this route in London: http://www.bikemap.net/route/392706. Without using a basemap, there are still a lot of breaks in the navigation using OSM/mkgmap. Using Garmin City Navigator NT map, it is a bit better, but has still a couple of breaks too. This means that - assuming the navigation algorithm functions properly (and this is not guaranteed either) - even Garmin maps may have flaws that break routing too! Eric
On Thu, Mar 08, 2012 at 10:33:16AM +0000, Eric Fernandez wrote:
Marko: I have seen in the archives that you also reported that the base map interfered with navigation on the Edge 705! Have you been able to better understand the issue and correct it?
No, I was satisfied with my hypothesis (that the OSM data was to be blamed; there was a 'routing island').
Could be worth it to try, but again you cannot do it anymore.
Well, I can still update the map on the device.
The only issue I see with it: - a smartphone is not as rugged as a GPS device like the Edge. I am aware of mounts and casings, but they are certainly not ideal
The SonyEricsson Xperia Active is not that bad. It might be the only outdoors-proof smartphone that supports ANT+Sport sensors. The GPS might be a little less accurate than the Edge 705, but I have yet to do an apples-to-apples comparison. (The reception will probably be much worse in a jacket pocket than on the bicycle handlebars.) I will install the SportyPal handlebar mount soon.
- battery life is really too short on a smartphone. A Nexus S using GPS has low autonomy compared to the Edge.
That is easily fixed by using a charger that connects to a bicycle dynamo hub. I have used such a setup for 3 years now, and never ran out of juice, even on multi-day trips.
Ideally, we would need proper GPS units that can accept not only OSM but also external routing applications. Do you know any of them?
No. Marko
2012/3/8 Marko Mäkelä <marko.makela@iki.fi>: ... Yes the Edge has an amazing GPS chip. Very sensitive and accurate. Anyway, I have done further testing with the style file, and it has indeed an influence on the way the Edge is able to do navigation over GPX files. I created a theoretical style file with only a lines file (I created the other style files but left them empty). My lines file contains two sections: one for route names (as found in the style cyclemap) and only one line for roads: # Roads highway=* [0x01 resolution 8] This is of course an overkill and the Edge takes a while to draw all the lines at low scale. But navigation on the http://www.bikemap.net/route/392706 GPX track is almost perfectly accurate. On the other hand, if I increase the resolution value, then I start to see more and more breakages (pink lines of death). Thus lines style is paramount for the navigation algorithm. I am curious why this is happening? I always thought that navigation was relying on NOD information, which should be (?) independent from the way the map is displayed at various scales. Any idea? Kind regards, Eric
On Thu, Mar 08, 2012 at 02:00:50PM +0000, Eric Fernandez wrote:
I always thought that navigation was relying on NOD information, which should be (?) independent from the way the map is displayed at various scales. Any idea?
Inside Garmin, the navigation might be independent of the line drawing. But, inside mkgmap, the NOD generation ought to be dependent on the style file. Can you try another test, using the default style but without the polygons file? Marko
Can you try another test, using the default style but without the polygons file?
No problem, I'll try it. I just tried the cyclemap style (close to the default, available at http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Cycle_map) but replacing their lines with my simple lines I described previously: now the track where the Begin was overlaying the End is correct! However I lost the navigation street names (although navigation works properly). Eric
Hi Marko,
Can you try another test, using the default style but without the polygons file?
Unfortunately this fails, I get this error: at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:140) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readBaseStyle(StyleImpl.java:518) ... This was working before, but not with the other default style files. Do I need some minimal info in the polygons file? Or do I need to change something? Eric
Unfortunately this fails, I get this error: at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:140) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readBaseStyle(StyleImpl.java:518) ...
This was working before, but not with the other default style files. Do I need some minimal info in the polygons file? Or do I need to change something?
Eric
Please ignore, I found the issue (see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013517.html). Eric
Hi Marko, A blank polygons file does not improve navigation. The key component I could find (so far) is the lines resolution. But there may be other reasons. Kind regards, Eric
participants (6)
-
aighes -
Eric Fernandez -
Felix Hartmann -
Marko Mäkelä -
Steve Ratcliffe -
Thorsten Kukuk