[mkgmap-dev] Bad routing on eTrex and MapSource

Mon Jul 13 06:43:27 BST 2020

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 at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at 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 at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at 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 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
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: detour.PNG
Type: image/png
Size: 78092 bytes
Desc: detour.PNG
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200713/178d624a/attachment-0001.png>