<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<div dir="ltr">
<div dir="ltr">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Hi all,<br><br>testing the effects of angles on routing is quite difficult. <br>I've disabled all road type avoidances and feature type avoidances to <br>make sure that possible detours are not discarded. <br><br>I have created a few routes which (in the best case for cycling),<br>would just visit the node with the sharp angle, but instead showed<br>detours using car as vehicle.<br><br>I've then created the map again and again with different road_speed<br>values and different values for the headings at the junction and tested the<br>effects (this process is very error prone, one has to press Ctrl+G two times<br>to make sure that the new map is read from disk again, and one has to<br>make sure that all options are the same).<br><br>I tried Basecamp and MapSource, they are not always showing the same<br>results. Since MapSource is no longer maintained I think I should ignore it<br>here.<br><br>My findings so far:<br>- the settings "Faster Time" and "Shorter Distance"<br>don't have the expected effect. Sometimes a detour disappears<br>when changing between the two options, but the calculated time/distance<br>values don't explain the result. Sometimes the shorter route is only selected <br>when "Faster Time" is enabled. <br><br>- The Garmin routing algo seems to ignore the angle completely when <br>the route follows the same road. To be precise: The same MapRoad instance.<br>Without road merging this typically also means "one OSM way".<br>If I got it right, RoadMerger will not merge roads that build sharp angles,<br>and it prefers to merge those roads which build a straight line at the merge point.<br><br>- As expected, a left turn (in a drive-on=right area) gets a higher time penalty than a right turn,<br>I did not yet analyse if this also depends on other arcs at the node. <br>- The time penalty depends on the angle and on the road speed:<br> + road_speed=3 or 4 seems to require > 67.5°<br> + road_speed=5 to 7 seems to require > 90° which not really a sharp angle ;-)<br>If the angle is smaller, the turn is avoided. <br><br>- technical info: <br>The threshold values for the angles are probably explained by the way how the initial heading<br>is stored in the img file: the so called "compacted format" uses only 4 bits, so the value <br>is heavily rounded. It is used when the rounded initial headings of the arcs at a node are all different.<br><br>Modifying the initial heading values can be a solution in some cases, but not in all.<br><br>Conclusion: <br>A road_speed>=5 should be avoided in cycling maps.<br>Even a road_speed >= 3 is problematic, angles with < 67.5° appear very often, esp. in towns where cycle<br>ways are sometimes drawn besides the road and then joined with the road later without caring much<br>about angles. The effect: Two junctions are connected with 3 or more arcs, one for the road, two<br>for the cycle ways, sometimes even more when the style creates additional arcs for the same OSM way.<br><br>I think about an alternative optimisation that tries to detect this case and somehow combines the arcs,<br>but that seems to be even more complex.<br><br>Still working on sharp-angles-v2.patch ...<br><br>Gerd<br><br><br><br></div>
</div>
</div>
</div></body>
</html>