logo separator

[mkgmap-dev] Unusual Routing Behaviour in BaseCamp

From Gerd Petermann gpetermann_muenchen at hotmail.com on Mon Nov 16 11:16:35 GMT 2020

Hi Ticker,

my assumption reg. "shorter distance" was that Garmin might simply ignore the "indirect arcs" which help to find the next major road. Never tried to find out the details, for me the implementation of "shorter distance" is simply broken and should be avoided.


Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 16. November 2020 12:10
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp

Hi Dave

The factors you mention can have a mix of effects.

The default for drive-on is 'detect,right', so, without a method of
knowing the country, mkgmap will use 'right'. The bounds file gives the
information that 'detect' will use, so, for the tile in question it
will be correct as 'left'. With drive-on resolving to 'right', the
right turn on the obvious route causes no penalty and that is what you

*_link vs. normal might change the road-speed and this could have an
effect on the chosen route.

primary vs. secondary might change the road-speed with effects as
above. It will change the road-class which can have a drastic effect on
routing, but not, I think, in this case. It can also cause changes to
the adjustments of the junction angle information per road that mkgmap
generates and the routing algorithm uses.

These last two effects are slight in this case and I presume the
decision is on the border-line, so much so that MapSource chooses the
obvious route.

Because the correct route is chosen when using 'faster time' and the
longer route is chosen when using 'shorter distance' I think it can be
explained in terms of road-speed and the perverse way in which Garmin
implements 'shortest distance'. My theory is that that it overrides all
the road speeds and then uses the 'faster time' logic, which would be
fine except for all the junction time penalties which are still there!

Default style and service roundabouts is another topic. For all but
trunk/primary/secondary/tertiary roundabouts it uses the Garmin
standard roundabout type (0x0c) rather than extended types
(0x10801..4). I've no idea what any of these (and 0x10805...) might
look like on your device without a TYP file.


On Sat, 2020-11-14 at 15:53 +0200, Dave wrote:
> Hi Ticker,
> This is in the centre of Zambia so should not be affected by drive on
> right countries. Where Zambia borders drive on right countries such
> as Angola and DRC there are not likely to be any link roads
> particularly Angola as it is pretty remote and not many roads here
> anyway.
> I understand the idea of a time penalty for a right turn across
> traffic, it is something that is always considered when driving in
> Lusaka normally as it is very congested, making a journey with all
> left turns will nearly always be quicker than one with a right turn
> across the traffic, the new flyover is part of a program to ease
> this. My interest was in the fact that bounds plus link tagging
> caused the problem,  bounds without link no problem, bounds plus any
> other tagging no problem. So the routing algo is obviously affected
> by the link even if it is following a direction away from the
> intended destination and then making a very tight right turn, tighter
> than 45 degrees that I am sure is illegal although not tagged with a
> no right tun in OSM. Following traffic regulations in Zambia is moot
> though and could endanger your life. I can live with the oddity.
> In connection with the default style, for appearance sake it may be
> worth using a narrower type with service way roundabouts as the
> current style shows them in a size out of proportion to the
> connecting service ways. As space is not at a premium in Zambia many
> of the mall parkings have roundabouts within them  that are bigger
> than a mini roundabout, probably as big as a small roundabout in the
> UK.
> Regards,
> Dave

mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk

More information about the mkgmap-dev mailing list