Hi Gerd Haven't had a chance yet to build this and investigate, but forget my other problem; just found this: https://www.openstreetmap.org/relation/7403805 Ticker On Sun, 2020-07-12 at 09:13 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, handling of dual-carriageways might be a reason for this. I might have found a way to circumvent this problem: If I make sure that arc lengths with an encoded value below 7 are increased to 7 the problem disappears. Interesting thing is that Basecamp and Mapsource still show the real values, so obviously the reported values depend on the data in RGN, not that in NOD. I think I already learned that in the past but I forgot about it.
Maybe values below 7 have a special meaning, maybe they should be encoded in a different way. Patch needs more testing for unwanted side effects...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Sonntag, 12. Juli 2020 10:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource
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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev