routing seems to depend on order of ways
Hi Steve, I think I found a very old bug in mkgmap, it seems to exist since at least r2210. I found it while testing a patch for r2914 and found it in all older versions that I tried. Attached are two test files and a gdb for MapSource. The command that I use: java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\good.osm or java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\bad.osm The only difference in the two files is the order of the ways w3 and w4 (the ids don't seem to matter) I use r2889 to test this because current trunk version uses a sort in the RoadMerger, but the error is not related to the merge. With bad.osm MapSource calculates a route that that passes the target point, goes up to the barrier and then reverses back to the target. This happens with vehicles like car and bike and seems not to be related to any routing preferences. I hope you can reproduce the problem and find out what goes wrong... Gerd
Hi, I have commited the new (undocumented) option --x-no-mergeroads to disable merging of roads. I think this is useful for chasing problems. WanMil
Hi Steve,
I think I found a very old bug in mkgmap, it seems to exist since at least r2210. I found it while testing a patch for r2914 and found it in all older versions that I tried.
Attached are two test files and a gdb for MapSource. The command that I use: java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\good.osm or java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\bad.osm
The only difference in the two files is the order of the ways w3 and w4 (the ids don't seem to matter)
I use r2889 to test this because current trunk version uses a sort in the RoadMerger, but the error is not related to the merge. With bad.osm MapSource calculates a route that that passes the target point, goes up to the barrier and then reverses back to the target. This happens with vehicles like car and bike and seems not to be related to any routing preferences.
I hope you can reproduce the problem and find out what goes wrong...
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, really confusing... The strange bug disappears in MapSource (6.16.3) when I (re-)activate option "Try to avoid.." "U-turns" In Basecamp (4.25) , the bug appears as well when I deactivate "Feature type avoidance" "U-Turns". Regarding the order of the ways in the OSM file: It seems that the only important way is w3. If that appears as first way, routing is crazy. I think the reason is the order of the calculated routing nodes that changes. Because of the gate the the way w4 is spit into 3 parts, and the calculated route seems to depend on the order of the routing nodes related to way w4. If w3 comes first, the node that connects it with w4 also comes first, else it comes later. I have no idea how to find the "right" order in a network. In NOD3, we sort the nodes "lexicographically by longitude, then latitude". Maybe we should do the same for NOD1? Gerd WanMil wrote
Hi,
I have commited the new (undocumented) option --x-no-mergeroads to disable merging of roads. I think this is useful for chasing problems.
WanMil
Hi Steve,
I think I found a very old bug in mkgmap, it seems to exist since at least r2210. I found it while testing a patch for r2914 and found it in all older versions that I tried.
Attached are two test files and a gdb for MapSource. The command that I use: java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\good.osm or java -jar d:\mkgmap\dist\mkgmap_r2889.jar --link-pois-to-ways --route --nsis --tdbfile --preserve-element-order f:\osm\bad.osm
The only difference in the two files is the order of the ways w3 and w4 (the ids don't seem to matter)
I use r2889 to test this because current trunk version uses a sort in the RoadMerger, but the error is not related to the merge. With bad.osm MapSource calculates a route that that passes the target point, goes up to the barrier and then reverses back to the target. This happens with vehicles like car and bike and seems not to be related to any routing preferences.
I hope you can reproduce the problem and find out what goes wrong...
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/routing-seems-to-depend-on-order-of-ways-tp57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi,
I have no idea how to find the "right" order in a network. In NOD3, we sort the nodes "lexicographically by longitude, then latitude". Maybe we should do the same for NOD1?
Tried that. It fixes the problems in my test case, but creates similar problems in other cases, so sorting seems not to be a solution. My conclusion: In MapSource and Basecamp, make sure that option "try to avoid u-turns" is activated. The doc for the display tool http://svn.parabola.me.uk/display/trunk/doc/nod.txt mentions "indirect links" which mkgmap never writes. Maybe these are needed to avoid bad routing as described by Franco: http://gis.19327.n5.nabble.com/mergeroads-sometimes-breaks-routing-tp5791132... but I have no idea how to test that. Gerd
Hi Gerd, Nice simple test case. I can reproduce on a similar version of mapsource that you used, but not on an older version.
I hope you can reproduce the problem and find out what goes wrong...
Interestingly if set to shortest time and avoid u-turns, then it goes straight down w1, w2 and through the barrier to the destination. It doesn't go along w3 at all. This happens on good (and bad I think but I would have to re-check). ..Steve
Hi Steve,
Nice simple test case. I can reproduce on a similar version of mapsource that you used, but not on an older version.
I hope you can reproduce the problem and find out what goes wrong...
Interestingly if set to shortest time and avoid u-turns, then it goes straight down w1, w2 and through the barrier to the destination. It doesn't go along w3 at all. This happens on good (and bad I think but I would have to re-check). yes, the original test was without w3. I wanted to prove that the link-pois-to-ways-v2.patch doesn't change something to the worse as feared by Chris66 : http://gis.19327.n5.nabble.com/patch-v1-link-pois-to-ways-and-restrictions-t...
The test proved that, so I wanted to find out what MapSource does if there is an alternative connection which is much longer. Result is the test case. Later, I've modified w3 to be much shorter, but that did not change anything to the better, means, all results with wrong routes were the same. Gerd
participants (4)
-
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
WanMil