Proposal: Use description instead of name for route relations

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

9 Likes

Can you give few examples of route relations that have wrong values on name and should be moved to description?

4 Likes

I agree, examples would be useful.

I think it would help if the examples covered these two situations:

  • The “name” as currently mapped has been constructed by mappers and does not refer to anything in the “real world”
  • The “name” as currently mapped refers to e.g. terminal points, but that is consistent with something in the real world, e.g. it is how a public transport operator or hiking route operator refers to the route.

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?

1 Like

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

4 Likes

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.

2 Likes

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. :laughing:

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. :stuck_out_tongue:

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.