I have started a new proposal: that the name tag should be restricted to the same meaning for route relations that it has on other elements and that the description tag should be used otherwise.
https://wiki.openstreetmap.org/wiki/Proposal:Use_description_instead_of_name_for_route_relations
Can you give few examples of route relations that have wrong values on name and should be moved to description?
I agree, examples would be useful.
I think it would help if the examples covered these two situations:
Iām fairly clear that your proposal aims to change the first situation. Iām not so sure about the second.
Route relations are used for all sorts of things: https://taginfo.openstreetmap.org/keys/route#values. Which of these does this proposal affect, and with which of these does it see the biggest problem?
Iām not sure why this is a proposal given that itās basically āuse the name tag correctlyā and āuse the description tag correctlyā.
But that aside, 100% yes to this.
Prior art:
https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html
https://lists.openstreetmap.org/pipermail/tagging/2020-March/051787.html
1 is clearly fictions data. But 2 is worse in that it prevents renderers, geocoders, and applications from using the name= directly Include route relations in Nominatim Ā· Issue #413 Ā· osm-search/Nominatim Ā· GitHub without parsing ability. Been discussed several times in Talk:Buses - OpenStreetMap Wiki etc.
Because sadly this misuse is quite wide and previous attempts to stop blatant misuses of name tags sadly failed.
I think this is mostly (mis)tagging for the rendered. Especially when it comes to making multi-relation routes easily selectable in e.g. JOSM. Iāve tried to avoid it and itās lead to some very confusing PTv2 editing.
I think most of the constructed info in the fake names is normally stored in operator from and to tags so itās largely redundant.
for such uses I would ask JOSM devs to autogenerate descriptions from existing tags (I requested it in past for some specific case and it got implemented from what I remember)
I guess we need a wiki page on (mis)tagging for the editor. 
For those who havenāt tried to avoid this tagging practice, the main problem is that many bus routes and other kinds of routes have names, in the sense that we normally define the name key, but the formulaic names have co-opted them.
For example, this bus route is actually called the āKings Island Expressā. The routeās name appears alongside the route number on maps, timetables, bus stop signs, and the electronic display at the front of the bus. An automated voice recording also announces the route name at each stop. Itās named after the amusement park at its last stop, but the stop has a more specific name.
Iāve tagged the name in name, but this technically violates the PTv2 schema. To conform to the schema, I would have to delete this useful information or move it to a silly-sounding key like real_name.
I agree that itās important for a relation list to be able to distinguish the two one-way relations that PTv2 requires. Software should be able to generate sensible labels based on other keys like from and to for the majority of routes. iD and Rapid already do this, but JOSM and openstreetmap-website would need to be patched to continue providing the same amount of information to mappers.
There may be some edge cases requiring an explicit tag. The problem with repurposing description is that it too has an existing definition. Mappers may be tempted to add verbose detail that is useless to an editor. @Kovoschizās suggestion of label makes a lot of sense to me. Itās clearer that weāre just providing a hint to mappers.
Hiking (cycling, MTB, horse ridingā¦) routes are in the same case.
I set JOSM to display āfromā when route donāt have name or ref, but it would useful to display āfrom - toā or i.e. āref ā from - toā.
Knooppuntnet display a label build from the tags from and to.
I didnāt saw that in iD do this because I donāt use this editor : it canāt reliably managed (big) relations.
I donāt know exactly what you mean by āeasily selectable in JOSMā. In JOSM you can customize the appearance and order of relations in the relations window by changing the key ārelation.nameOrderā. If a relation doesnāt use any of the tags mentioned there, it is only referenced by the ID in the window.
description as one of the default values that is used if there is no ref, name etc. given has been introduced last year.
Iām fully in support of using name for the actual name on relations of all sorts, just as with any other named object. label seems like a good idea for labelling relations in a raw data view (such as in an editor). Ideally Iād like a key name that clarifies the purposeāto disambiguate or distinguish between objects that share the same name for the convenience of data management. disambiguation_label, qualified_label, and distinct_label are a few ideas but Iām not sure if the qualification is truly worth the extra letters.
This doesnāt really help. You have something selected, you want to add it to an existing relation, that has a ref a from and a to tag, and three relations of the same ref appear in the search box/relations panel without showing the contents of the from or to tags so you have to guess which of the two type=route relations is correct. Relying on a formulaic description for routes would make other editing more difficult.
label appeals to me because it matches the very intentional distinction between labels and names in Wikidataās data model. However, its similarity to the label relation role could cause some confusion, because that relation role is about map labels rather than labels in an editor interface.
Thanks for bringing up the idea of disambiguation. I like the idea of tagging something freeform that an editor interface can append to the name instead of replacing the name. I think many mappers are already familiar with the concept of a disambiguator from seeing them in parentheses at the end of encyclopedia article titles. Wikipediaās disambiguators are as short as possible ā e.g., āThe White House (department store)ā ā while Britannicaās are more like short descriptions, sometimes as long as ā10 Downing Street (official office and residence of the prime minister, London, England, United Kingdom)ā.
In the U.S., mappers have long appended disambiguators to the names of road routes. For example, there are multiple highways designated as Interstate 275 in different states. The one in Michigan is tagged name=I 275 (MI). On the other side of the country, U.S. Route 101 is so long that weāve had to split it into multiple route relations. The tiny town of Hopland, California (population 661), will be gobsmacked to learn that two of the most important route relations in the country are arbitrarily named after them, one in either direction.
These days, none of these name tags are necessary anymore, thanks to network, ref, is_in:state, from, and to. But in some cases, thereās no good from/to combination to choose from, and an accurate is_in:* would be far too obscure for any software to recognize. A freeform tag means mappers donāt have to fudge other keys that already carry special semantics.
disambiguator has the benefit of making it clear that you donāt have to tag it on every relation, only the ones that would be ambiguous otherwise. Plus, the extra letters will dissuade mappers from overusing it. 
ā¦ just a short reply before work: this may really be easy to implement in JOSM - showing a somewhat customized label in the the relation window - if it is not already possible (I donāt understand all of the syntax of the entries in relation.nameOrderā¦)
Yes, out with these route name constructs of "transport mode nr: from location ā to location with an insert āAnelloā if roundtrip and in with the official names as published by the transco.
This has already been mentioned, but to reiterate: the solution is to add from and to tags (and via when appropriate) to the relation. I donāt believe that we need a new proposal that will just confuse things more.
This allows a reasonable label to be generated* for āunnamedā routes in editors and renderers can do the same. It would seem that the bit missing is a feature request (or better code) for iD to support this too.
* both JOSM and Vespucci support generating labels for editing purposes out of essentially any combination of tags, including making this conditional on if for example a name tag is present or not.
Example: https://github.com/simonpoole/beautified-JOSM-preset/blob/master/master_preset.xml#L13631
This we (me) does and when absent QA services will remind to add those tags.
This will definitely help. There are, however, some routes where this doesnāt work, because they are part of another route that has been chopped into multiple parts, or where the from and to starts somewhere in the middle of nowhere.
Some months ago, I was working on a proposal that is a lot more thorough on the what and how. I havenāt brought it up yet, because I dināt feel it was ready for discussion. Now that other tags like label=* (which Iām also suggesting in that proposal) are thrown around, Iād feel like I need to show people a bigger picture, and also give some description whatās wrong with the current use of name on a lot of routes.
I donāt want to hijack this thread, but I feel like the whole discussion is ripping apart a good suggestion by @Wynndale, because there are a lot of things wrong with route names and their proposal is only focussing on using description instead of name for routes that donāt have a name. People need so see the bigger picture, or, well, the proposal needs to address the whole set of problems, because, as @SimonPoole mentioned, sometimes using from and to is good enough and no description is needed.