logo separator

[mkgmap-dev] some results regarding sharp angels

From Gerd Petermann gpetermann_muenchen at hotmail.com on Thu Aug 27 08:50:31 BST 2015

Hi all,

testing the effects of angles on routing is quite difficult.  
I've disabled all road type avoidances and feature type avoidances to 
make sure that possible detours are not discarded. 

I have created a few routes which (in the best case for cycling),
would just visit the node with the sharp angle, but instead showed
detours using car as vehicle.

I've then created the map again and again with different road_speed
values and different values for the headings at the junction and tested the
effects (this process is very error prone, one has to press Ctrl+G two times
to make sure that the new map is read from disk again, and one has to
make sure that all options are the same).

I tried Basecamp and MapSource, they are not always showing the same
results. Since MapSource is no longer maintained I think I should ignore it

My findings so far:
- the settings "Faster Time" and "Shorter Distance"
don't have the expected effect. Sometimes a detour disappears
when changing between the two options, but the calculated time/distance
values don't explain the result. Sometimes the shorter route is only selected 
when "Faster Time" is enabled. 

- The Garmin routing algo seems to ignore the angle completely when 
the route follows the same road. To be precise: The same MapRoad instance.
Without road merging this typically also means "one OSM way".
If I got it right, RoadMerger will not merge roads that build sharp angles,
and it prefers to merge those roads which build a straight line at the merge point.

- As expected, a left turn (in a drive-on=right area) gets a higher time penalty than a right turn,
I did not yet analyse if this also depends on other arcs at the node. 
- The time penalty depends on the angle and on the road speed:
 + road_speed=3 or 4 seems to require > 67.5°
 + road_speed=5 to 7 seems to require > 90° which not really a sharp angle ;-)
If the angle is smaller, the turn is avoided. 

- technical info: 
The threshold values for the angles are probably explained by the way how the initial heading
is stored in the img file: the so called "compacted format" uses only 4 bits, so the value 
is heavily rounded. It is used when the rounded initial headings of the arcs at a node are all different.

Modifying the initial heading values can be a solution in some cases, but not in all.

A road_speed>=5 should be avoided in cycling maps.
Even a road_speed >= 3 is problematic, angles with  < 67.5° appear very often, esp. in towns where cycle
ways are sometimes drawn besides the road and then joined with the road later without caring much
about angles. The effect: Two junctions are connected with 3 or more arcs, one for the road, two
for the cycle ways, sometimes even more when the style creates additional arcs for the same OSM way.

I think about an alternative optimisation that tries to detect this case and somehow combines the arcs,
but that seems to be even more complex.

Still working on sharp-angles-v2.patch ...


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20150827/c291facc/attachment-0001.html>

More information about the mkgmap-dev mailing list