Hi, I am trying to find a better algo for the handling of short arcs. (Garmins routing algo refuses to route over short arcs) The typical case of a short arc is a crossing like here: http://www.openstreetmap.org/browse/node/1449682318 We don't lose much information if we merge the node with node 1303933872, so merging is a good idea here. On the other hand I stumbled across a few cases were I am not sure what to do. I many cases I'd prefer to move one of the two nodes so that the arc gets longer. See e.g. http://www.openstreetmap.org/browse/way/47138169 The first two points of the way build a short arc (2.8 m), while the next arc to point 267185122 is > 33m. The merging of these two nodes will produce a map which implies that you can turn right directly at the end of the bridge http://www.openstreetmap.org/browse/way/47138168 I think it would be better to move the node 627157116 a little bit closer to the next point 267185122. A similar case: The bridge at http://www.openstreetmap.org/browse/way/131860005 has a length of ~ 4.99 m. With the default value 5m, this is considered to be a short arc and short-arc-removal will remove the bridge by merging the two end points. On the other hand, a (service) road with just two points, one point connected to a road, the other not connected to a road should be removed if it is a short arc instead of eventually moving the point connected to the road (as this produces the zig zag lines as posted by popej (road.png): http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761.html (this one is easy to detect and I can create a simple patch) I don't know yet how to implement all this, so I'd like to make sure that I am not investing much time into a wrong solution. Comments? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708.html Sent from the Mkgmap Development mailing list archive at Nabble.com.