On Mon, Aug 19, 2019 at 6:34 AM Peter Elderson <pelder...@gmail.com> wrote: > Keeping linear main route and alteratives separate is actually quite > straightforward and much less work than creating and maintaining routes with > roles. Especially when the forward/backward roles do not indicate the > direction of travel, as is the case with bicycle routes.
The 'forward' and 'backward' roles are well defined. At least two editors that I've used understand them. JOSM appears to sort them correctly. (It does stumble a bit in the special case where a route=road ends at junction among dual carriageways, because it cannot find a single endpoint.) We seem to have this problem mostly solved. I disagree with the 'much less work' when you're maintaining a route that's hundreds of km long, follows dedicated trails or rural roads most of the way, but once in a while enters a city and splits because of one-way streets. Maintaining separate 'forward' and 'backward' relations for the whole thing would be quite annoying. > The point of route relations is that they are already routed, i.e. they > prescribe exacty what ways to travel. They are not suggestions for routing. > Of course, if there are problems, you can try to make up for that using > routng techniques, but you should not turn that around and say hey, I am > routing anyway, so forget the data issues. The idea is to record exactly how > to travel, so people can travel along the path without rerouting. Just take a > way, then the next, etc until the end. These are not suggestions, it's a > prescribed route to follow, as seen on the road because it's > signposted/waymarked. Right. Structuring the route in that form also allows software to produce the skeleton of the route book. I started with the output of a PostgreSQL query when I wrote the initial draft of http://www.nptrail.org/trip-planning/section-descriptions-and-mileages/ (I found several gross errors in the 'official' route book that way: there was one segment that was shown as 1700 m shorter than its actual length, for instance). -- 73 de ke9tv/2, Kevin _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
