Unusual Routing Behaviour in BaseCamp

Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Unusual Routing Behaviour in BaseCamp

Dave

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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Route with bounds.jpg (351K) Download Attachment
Route without bounds.jpg (375K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Gerd Petermann
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 <[hidden email]> im Auftrag von Dave <[hidden email]>
Gesendet: Mittwoch, 11. November 2020 09:22
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Dave
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 <[hidden email]> On Behalf Of Gerd
Petermann
Sent: 13 November 2020 12:05
To: Development list for mkgmap <[hidden email]>
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 <[hidden email]> im Auftrag von Dave
<[hidden email]>
Gesendet: Mittwoch, 11. November 2020 09:22
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Gerd Petermann
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 <[hidden email]> im Auftrag von Dave <[hidden email]>
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 <[hidden email]> On Behalf Of Gerd
Petermann
Sent: 13 November 2020 12:05
To: Development list for mkgmap <[hidden email]>
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 <[hidden email]> im Auftrag von Dave
<[hidden email]>
Gesendet: Mittwoch, 11. November 2020 09:22
An: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Ticker Berkin
In reply to this post by Dave
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Dave
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: [hidden email]
Sent: 14 November 2020 13:03
To: [hidden email]
Reply to: [hidden email]
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Ticker Berkin
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unusual Routing Behaviour in BaseCamp

Gerd Petermann
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 <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev