[mkgmap-dev] Unusual Routing Behaviour in BaseCamp

Sat Nov 14 10:28:54 GMT 2020

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 at lists.mkgmap.org.uk> im Auftrag von Dave <dfjkman at 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 at lists.mkgmap.org.uk> On Behalf Of Gerd
Petermann
Sent: 13 November 2020 12:05
To: Development list for mkgmap <mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag von Dave
<dfjkman at gmail.com>
Gesendet: Mittwoch, 11. November 2020 09:22
An: mkgmap-dev at 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 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