[Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

Software needs a sorted or easily sortable relation. Currently, no software can handle sorting when the routes get broken. Routes with forward and backward roles don’t sort properly either. Routes get broken very easily all the time. 

Now the combine and sort routine waymarkedtrails uses when exporting routes actually does a fine job when e.g. a simple ordering problem is present. It fixes direction differences nicely. But if it encounters a more serious problem, it gives up and then all the simple things are not fixed either. So one wrong edit in Ireland can mess up the complete E2 over the entire length.

That’s why the only way to get reasonable outcome is to structure and sort the routes on the mapping level, then check and maintain all routes, all the time. 

Actually, nested relation are much easier for mappers to handle and maintain than long single ones. 

Roles in relations seem like a nice solution, but I don’t think it helps the sorting problem. Which in turn means no software can rely on Osm-route relations for other things than display.

I talk to many people about foot routes. I recommend waymarkedtrails, but when people want to use the gpx export I tell them to wait until I have checked and repaired the routes, or they will end up with a useless track that cannot be handled by a garmin or by OsmAnd.

Hardening against breaks? I would welcome that, but how? In Nederland, practically all ways are part of routes for walking, walking node connections, cycling, cycling node connections, PT. Not seldom I have to check and repair 10-15 route relations after one edit (most often a split of a way to allow a route to attach there) on the map. If we simply prevent an edit if it breaks a route, we will lose a lot of mappers who simply want to maintain the road network.

Mvg Peter Elderson

> Op 15 aug. 2019 om 23:14 heeft Sarah Hoffmann <lonvia at denofr.de> het volgende geschreven:
> 
>> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging