[Tagging] Route names, and section order in superroutes

[Peter Elderson]

We have talked in the past about the name tag in route names. It
often contains non-name elements. This appears to be driven by how
people want to see the routes displayed in lists.
From, To, Via, Ref, Purpose, Region, and Part numbers are popular elements.
These elements are layed out to produce alphabetically ordered and 'pretty
print' route list in applications and maintenance tools.
Understandable, but not conform the 'name=just the name' principle, which
is important for clean data and for a.o. Nominatim.

To clean this up, From, To, Via, Ref can go in the well-known from=*,
via=*, to=*, and ref=* tags. Region, Purpose (e.g. "German part of the
GR5"), can be moved to description=*.

Part numbers / section numbers have no approved tag. I have been using
section_ref=* which would in principle allow data users to order route
sections (relation members within the superroute), but this is not an
accepted nor a complete solution.
E.g. in international superroutes, the country-parts are usually named by
the country's community, without a section ref.

On the data level, this "how do you now the order of the sections" is sort
of the same the same problem as "how do you know the start/end points and
the direction of a unidirectional roundtrip route", which mappers tried to
solve using node members with roles, and tags like direction=clockwise. The
solution is: this is given by the order of the members in the relation.
Instead of adding extra data elements, just get the order right!

For this to work, data users should not use name-only display and name-only
alphabet ordering. For top-level display, a format should be used showing a
combi of elements; the exact format is of course up to the renderer.
Alphabetic order using this format is fine at the top level. For sections
of a (super)route, the display format may be the same or different, but the
order should follow the order within the relation.

As it happens, one data user / renderer / application has adapted the
frontend accordingly.
https://hiking.waymarkedtrails.org/#route?id=4580796&type=relation&map=7.0/48.2983/5.3405

I think OSM Carto uses displays the name tag and object Id for all
relations. Unlike (mainly) recreational route renderers, they have to
consider non-route relations. A separate format for display of route
relations might help, or a composite format which serves all relations.
Example: https://www.openstreetmap.org/relation/2552826 (expand the members
section). If the section numbers are removed from the name tag, all the
sections have the same name. Maybe they still would be in the right order,
but it would help to actually see that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220218/030723db/attachment.htm>