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

Sarah Hoffmann lonvia at denofr.de
Thu Aug 15 21:14:47 UTC 2019

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.

(aka lonvia, maintainer of waymarkedtrails)

More information about the Tagging mailing list