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. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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 get. *_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. Regard Ticker 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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev