[mkgmap-dev] Bad routing on eTrex and MapSource

Sun Jul 12 10:13:25 BST 2020

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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: len7.patch
Type: application/octet-stream
Size: 1053 bytes
Desc: len7.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200712/b3e85afd/attachment.obj>