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 here. 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. Conclusion: 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 ... Gerd