[mkgmap-dev] Bad routing on eTrex and MapSource

Sun Jul 12 15:02:40 BST 2020

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