Hi Dave, yes, data quality in Africa is still poor compared to most European countries. The driving side is important because the garmin algo adds time penalties for a left turn in a drive-on-right country and vice versa for a right turn in a drive-on-left country. Even with the "shortest route" option this penalty is considered. Another question is if mkgmap should use the given country name (country-name="Zambia") or iso code (country-abbr="ZMB") to look up the driving side when no bounds are given. Probably better than just using the default "drive-on-right". Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Dave <dfjkman@gmail.com> Gesendet: Samstag, 14. November 2020 11:11 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp Hi Gerd, Yes the map is in Lusaka, Zambia. There is a new road layout with a flyover bridge, newly constructed, so out of curiosity did a test routing here to see what BaseCamp would do, that's when the strange route came up. I then decided to try work out why BaseCamp would give such a obviously wrong route. BaseCamp and Garmin devices do not always give good routing options in Zambia as the OSM way tagging in Zambia does not always indicate unpaved roads and many tracks are tagged as unclassified or even higher order highways. This is mainly due to the many remote mappers mapping in Africa. Many of the link roads (primary_link etc.) were tagged by a team of Apple Mappers. After finding that the -- bounds option affected the routing I wondered if an added factor was the tagging of the way, this particular way is tagged as primary_link. I found if I removed the link tagging and tagged as a primary, secondary or tertiary way the route was as expected. Using the fastest preference routes as expected regardless of bounds or tagging, in fact there should be no difference in routing it is a direct right turn. Many of the links tagged as such are not true links as may be found in more developed countries where the idea is perhaps more applicable to on ramps and off ramps. Removing the link tagging just meant another eager beaver Apple mapper just came through and retagged it as a link. I just found it strange that the combination of bounds and the link tagging would cause the error. Just now thought it may have something to do with one way directions which would be dependent on the drive on side of the country. But Just changing the link tagging as I did in my test map would not affect the one way direction. I have not come across another example of this in the current map but do recall that I saw a similar thing many months ago at a roundabout coming into Lusaka where the route was off the connecting road to the roundabout and back on to the roundabout rather than just around the roundabout. It does not occur now but I suspect the roundabout flare was tagged incorrectly as a link and that has now been corrected. Regards, Dave -----Original Message----- From: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> On Behalf Of Gerd Petermann Sent: 13 November 2020 12:05 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp Hi Dave, if I got that right this part of the map is in Zambia, so without bounds you have to tell mkgmap that it is a drive-on-left country, else you'll get completely wrong results. Besides that Basecamp often doesn't find the shortest route in car mode. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Dave <dfjkman@gmail.com> Gesendet: Mittwoch, 11. November 2020 09:22 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp Hi All, I have come across an unusual routing behaviour in BaseCamp on a stretch of road in Lusaka. When using the driving profile with no avoidances selected and the shorter distance route preference selected the route shown diverts down a link road and is obviously not the shortest route. Changing the route preference to faster time shows a more obvious route. Both route preferences should, in my opinion, be the same. See attached screen shots. After some investigations it would appear that this occurs when the -bounds option is used with bounds-latest.zip, if I do not use this option it routes as expected. The following are the commands used with mkgmap r4587: Routing problem: java.exe -jar C:\Users\Dave\Documents\Maps\Utils\mkgmap-r4587\mkgmap.jar ` --output-dir='C:\Users\Dave\Documents\Maps\Temp\Output' ` -c C:\Users\Dave\Documents\Maps\Options\Default.cfg ` -c C:\Users\Dave\Documents\Maps\Zambia\Split_Files\template.args ` The Default.cfg file has the following options: country-name="Zambia" area-name="Zambia" country-abbr="ZMB" overview-mapname=Zambia product-id=1 family-id=2526 draw-priority=20 max-jobs keep-going tdbfile order-by-decreasing-area gmapsupp bounds=C:\Users\Dave\Documents\Maps\Data\bounds-latest.zip latin1 index route remove-ovm-work-files nsis By commenting out the bounds option I change the routing behaviour. I have not used any typ or style files in case they were the cause of this. Also not tried on my Garmin device yet to see if the same behaviour occurs there as well. The routing error I have found occurs at this intersection but may occur elsewhere https://www.openstreetmap.org/#map=19/-15.45547/28.26647. After some experimentation this only happens when the adjoining way is tagged as a link road, in this case primary_link. Using JOSM I have changed the tag to secondary and later primary, saved the file to my laptop then processed the saved file and the unusual routing does not occur. Regards, Dave _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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   Original Message   From: rwb-mkgmap@jagit.co.uk Sent: 14 November 2020 13:03 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp Hi Dave There are a few things going on here that might have effects on the routing behaviours you are seeing. Driving side - as Gerd has elaborated. I have an example where the Garmin routing algorithm will do 2 left turns, a u-turn and then a right turn anyway across the traffic to avoid the correct, single, right turn! I notice that Zambia has adjacent countries with drive-on-right, so you need to beware of tiles around the edge of your map where the automatic choice could be wrong for Zambia. The default style uses type 0x08 and 0x09 for link roads and these are thought to have special properties regarding pop-up hints, but not known to effect routing decisions. Link roads have the same road_class as their non-link equivalents so this shouldn't have drastic effect on routing, but they do have a lower speed, which should have favored the direct turn even more (being shorter as well). Changing between primary and secondary might have a small effect on which roads get their angle into/out-of the junction adjusted where they are at a tight angle (<= 45 degrees) from another road and the turn appear permissible for navigation - tight angles impose a routing penalty. Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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