Hi Ticker, I think we have to live with this problem. I found the same error with original Garmin demo maps, e.g. "Topo Deutschland" from 2010 tile 16608746.img. MapSource calculates a big detour, Basecamp doesn't. Inverted route is short in both programs: 1. Rheinstraße 0 m 0:00:00 N53.01308 E8.77969 2. Get on Rheinstraße and drive north 0 m 0 m 0:00:00 0:00:00 180° grid N53.01308 E8.77969 3. Turn right onto Neckarstraße 13 m 13 m 0:00:01 0:00:01 17° grid N53.01317 E8.77973 4. Turn right onto Ahrstraße 32 m 19 m 0:00:08 0:00:09 99° grid N53.01315 E8.78001 5. Ahrstraße 44 m 12 m 0:00:13 0:00:22 180° grid N53.01306 E8.78005 I did not find a route restriction or oneway road which would explain this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Sonntag, 12. Juli 2020 20:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource Hi Ticker, okay, good to know. BTW: the problem is not the encoded length value, when I change the multiplier in NodHeader to different values it shows that the length is the threshold. Might be 10 feet. The simple patch is probably not the solution, NodCheck complains a lot and the error also doesn't always occur in my "normal" maps. So the length is not the only trigger and I am pretty sure that it would produce unwanted effects in other situations. 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 16:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Bad routing on eTrex and MapSource 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
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
