Hi Gerd I wonder if a combination of the closeness and parallelness of the roads containing the start & end points persuade the Garmin software that it is a dual-carriageway (having failed to notice both are bi -directional) and incorrect data in mkgmap output is being taken as a restriction to stop the joining road being used for an extended u-turn. Later, probably won't be until tomorrow, I'll try assemble the data for my other case where the routing is simply forced off the main road, down an alley, u-turn, back into main road in original direction. I'll also look for a similar configuration of roads elsewhere and test the behaviour on BaseCamp/MapSource Ticker On Sun, 2020-07-12 at 07:59 +0000, Gerd Petermann wrote:
Hi all,
My findings so far:
Attached are small demo files that show the problem with Basecamp routing. With demo.osm Basecamp refuses to route the shortest way in one direction and doesn't in the other when start and tartget are on the same side of road A. It also prefers the detour with "faster time" for one direction, with demo-more-than-32.osm it always takes the shorter way because the distance between the two ways is a bit longer. The problem also disappears when there is a curve on the ~30 m arc (mkgmap writes different NOD data for this) .
I still have no idea if this is an error in the data written by mkgmap or if there is a special case in the Basecamp routing algo. While one can argue that a right turn can take long in a drive-on -left country one would expect that this should have no or only a small effect on the calculation of the "shorter distance". OTOH Garmin doesn't claim that it calculates the shortest route, it is only a "Route Preference".
Options to use: --route --preserve-element-order --drive-on=left If you use option --drive-on=right the results are reverted, means, you have to also revert the route to see the same results.
Maybe those who have an original routable Garmin map can try to find a similar case in their map and report if the routing works or not.
Gerd