+1, for routes with multiple stages you can also add the reference number of the stage (if applying) to the “stage” tag of the route relation: https://taginfo.openstreetmap.org/keys/stage
(not yet completely established does it seem the obvious tag for such information)
it is very rare (actually almost never seen it, maybe depends on the route operator) to have a route or stage (part of a route) to start or end in the middle of nowhere. Hiking routes usually go from something well identifiable (a village centre, parking, tower, restaurant, castle, a crossing with another hiking route etc.) to something else well identifiable (as before, or alpine hut, summit, mountain pass, lake, spring, etc.). If there is nothing (not even a route crossing) for orientation, you can omit from and to (in the end, the route is already well defined through its geometry). Usually, if a “chopped” part starts or ends in the middle of nowhere, we should consider “chop” the route differently 
There is no reason that in the absence of a name or other tags the value of description couldn’t be used as a fallback label in an editor.
Generating descriptions on the fly would actually make quite a lot of sense for the software issue of editors. We would need to tackle the people problem of constructed names being put back for routes without a natural name and spamming search.
That’s mostly a matter of implementing the same functionality that editors have in openstreetmap-website. Once that’s done, most of the motivation for adding descriptive names to these routes would quickly disappear.
I agree in principle, but the choice of description isn’t without downsides. description has always been documented as text intended for display to the end user of a map or search result, whereas note is for display to other mappers. PTv2’s author assumed that name was free to overload with a formulaic name without considering that key’s broader meaning; I think it would be unfortunate if we repeat that mistake with a second key. On the other hand, maybe the idea of displaying description to end users is purely aspirational at this point.
2 Likes
I don’t think it’s so rare. Examples:
I will be attending State of the Map EU in Antwerp and I am willing to discuss this, including whether description is a good replacement, in person.
How is the proposal going to achieve its goal? Is the idea here just to slowly raise awareness in the community? Or are you planning concrete actions, such as changing the Wiki page for Public transport and similar pages so they encourage the use of description=* instead of `name=*? Mass retagging?
I am trying to unhide real route names, including making them searchable without search engines being spammed, by moving route relations to name is the name only like other elements in OSM. This is more important than the my original proposal of the description tag and I am willing to discuss alternatives. As my objective is to get constructed names out of the database I am trying to build community support.
I think updating the wiki documentation to remove the recommendations to construct a name would be a good start. There are probably a few cases there what appears to be a constructed name is the actual name used by the operators which would make an automated edit problematic.
To reiterate, I support this objective and appreciate you stepping forward to address a common pet peeve.
I agree that changing the standard needs to come well before planning any mass edit. That said, I don’t think mass-editing these names would be particularly fraught. The format is so contrived and would be unwieldy as a real-world name.
For several years after the PTv2 schema was approved, the documentation called for a literal => in name. Of all the assumptions that PTv2 made, its assumption that ASCII art doesn’t appear in a real route name is probably the most sound. Personally I’d have a good deal of confidence in a mass edit that breaks apart the name of these 73,677 route relations matching the rigid documented syntax, and even more confidence in a mass edit that removes name from these 37,086 route relations in which the structured tags already match the name exactly. (A more rigorous query would undoubtedly find more.)
Maybe the risk is that some public transport operator loves OSM so much that they decided to copy our conventions? If so, we could mitigate that risk by proceeding region by region.
Inserting shameless self-promotion here: I will be holding a talk on the state of hiking routes in Antwerp on Saturday 11pm with an intend to hold a BOF afterwards. The topic of descriptive names will definitely come up. The talk/BOF focuses on hiking while you were probably more thinking about PT routes. However, when it comes to the name tag, problem and solution should be pretty much the same.
3 Likes
In my experience names on hiking routes are actual names, rather than descriptions.
Some examples
Pennine Way
Wales Coast Path
This relation seems to be called " Pennine Way (Edale to Crowden)"
Some of that is regionally named, but this one is " Wales Coast Path (North Wales Coast)". There’s also the North Wales Path, which may or may not be related.
I think it’s more likely that they’d follow whatever the GTFS spec recommends, but it is possible.
That big an edit in one go makes me a bit nervous.
Agreed, I only provided those queries so we’d have an idea of the eventual impact of this proposal globally. I should’ve clarified that it would be multiple edits at least. But you can tweak the query to only operate on a particular region. Realistically I’d expect any bulk edits to be performed regionally or even network by network (for PTv2 public transportation routes).
… and GTFS has a field name called route_long_name in routes.txt
Full name of a route. This name is generally more descriptive than the
route_short_nameand often includes the route’s destination or stop. Eitherroute_short_nameorroute_long_namemust be specified, or potentially both if appropriate.
BTW: route_short_name can be mapped to OSM’s ref
Short name of a route. This will often be a short, abstract identifier like “32”, “100X”, or “Green” that riders use to identify a route, but which doesn’t give any indication of what places the route serves.
Yes, and as your quoted sections show, they are far less artificial and rigidly structured than the current recommendations for PTv2 routes.
2 Likes