Hi all, I've found some rules and started to code. The results of the first working version using the default style looked promising. My approach: 1) For each routing node collect all direct arcs to other nodes 2) sort these arcs by initial heading (IH) 3) check the angle between two consecutive arcs, when it is too small: 3a) ignore the sharp angle when road speed of both is 0 3b) ignore the sharp angle when no vehicle is allowed to travel both arcs. - check oneways, - check access (car, bicycle, foot etc) - check route restrictions (from restriction relations or barriers) 4) For both arcs that build the sharp angle: calculate the angle to the next arc (before / after) If these angles are big enough, change the corresponding initial heading value of the arc so that the sharp angle is enlarged and the large angle is made a bit more sharp. This seems to work quite well with the default style as long as --make-opposite-cycleways is not used. With --make-opposite-cycleways we sometimes see two arcs with the same IH but different different results for the 3a) and 3b) check. The angle between these two arcs is - of course - 0 (zero). The cycle map styles like those from Minko or Felix will be even more complex (or not ?). To solve this problem I can combine the arcs again so that all arcs which are based on the same OSM way appear only once when calculating angles. If the heading of such a combined arc is changed, I just have to make sure that all corresponding arcs are changed. My problem: In most cases the combined arcs will have different routing attributes, so the code for the checks in 3b) will be very complex or they have to be ignored. Any ideas? Maybe I don't see the wood for the trees? Gerd GerdP wrote
Hi Felix,
My current approach is to evaluate the results of the style, so it is up to the author to decide what a pedestrian-only way is. Another point is that we don't need the check for ways which can't be accessed by bike. I am aware that these checks must be ignored when a special cycling map is created (or any other special map, we just have to find out meaningful option names)
I am trying to produce test data to find out in what case Garmin prefers a small detour, this should help to find concrete rules.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/sharp-angles-and-routing-tp5852065p5852884.ht... Sent from the Mkgmap Development mailing list archive at Nabble.com.