On Thu, Aug 15, 2019 at 04:50:26PM +0200, Peter Elderson wrote: > Sarah: > > There is relatively few software that can handle hierarchic relations. > One could argue that putting alternatives in separate relations makes it > actually harder to access those. > > I think it's fair to say there is almost no software that does anything > with route relations except rendering and exporting as a gpx. Dislaying > elevation prophile is also one you can find, and it shows nicely what > inconsistency does: break up the prophile. Rendering looks OK because in > the end you display the ways and it doesn't matter if they are out of > order, double, running in loops or whatever. For A to B navigation you need > single ordered chains without all the variations and reduplications.
There is a difference between what current software does and what software could reasonably do. Yes, software needs a sorted relation and it needs the information what the linear main route is and what diversions, alternaitves and accesses are and how they relate to the main route. Relations should contain enough information that software can extract the information with resonable efford and without resorting to guessing. But there is another side: relations are only useful when they are reasonably easy to maintain by mappers because otherwise there are no relations. Now, sorting is a beast. I haven't found a way to support unsorted relations and guarantee a certain usefulness of the data even when relations get broken. I prefer hardning against data breakage. It's always a trade-off. Adding alternatives, links etc. is a different matter. When they are marked with the proper role, than that is a very simple matter of filtering the members of a relation by their role. That is a very, very simple excercise for software. Much easier in fact than handling nested relations. So no need to burden the mapper with complications like nested relations. Just add the ways with the proper role and software can cope. We just need to come to an agreement between software and mappers what the roles mean. What I'd like to see clarified is: what roles can be expected and when should be used, i.e. I think we should make it clear that only a signed alternative/excursion/access is eligible. And even there are some nuances: is a single sign-post sufficient or should there be the same trailblazing along the path as for the main route. > If that can be done at mapping level, datausing software could actually be > made to work with that. Now you can only export a track (losing the map > info), strip it in an editor to create your own route, and then move it to > the routing or planning software which then recombines it with a map. > That's why I say: > 1. Routes with only ways OR only part relations I agree but more for making life of mappers easier. > 2. No double ways That cannot be avoided. There are routes that go past the same way twice. These routes should be mapped as they are. > 3. Always have one single strand main route; alternatives as separate > single strand routes. That's not possible unless you want to resort to separate relations for backward and forward direction. (Think one-way streets along cycling routes.) And we know to what kinds of hells that has led for PT mapping. Sarah (aka lonvia, maintainer of waymarkedtrails) _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
