Because sadly this misuse is quite wide and previous attempts to stop blatant misuses of name tags sadly failed.
3 Likes
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.
2 Likes
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.
3 Likes
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.
1 Like
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. 
1 Like
… 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
3 Likes
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.
+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: