Problem statement: descriptive names in the name field of road route relations make it difficult for data consumers to consume the name tag for routes that are named but un-numbered because they cannot differentiate true named routes from constructed descriptive name. This tagging also goes against our guidance that names are not for descriptions.
Background: A “descriptive name” in this context is one where a route identified only by route number (ref) also has a name tag populated with a description. For example, this route relation for Interstate 77 in Ohio is tagged name= I 77 (OH) (North).
Planned edit: I intend to systematically re-tag descriptive names on route=road relations in the United States, starting with US interstates. In these cases, the name tag provides no additional information not otherwise present in the tagging other than giving a human-readable description. Therefore, I will move the contents of name into description.
I changed this back in 2021 and so far this hasn’t broken anything
Below is an example of a correctly-tagged road route relation that uses a name tag. It’s important that data consumers can consume the name tag in cases like this while not consuming descriptive names.
Scope: This applies ONLY to road route relations in the US and not to road ways. I intend to make no changes to way name tagging with this series of edits. This is NOT a discussion about whether cases like highway=primary + name=State Route 123 on a way is correct tagging – this is purely about road route relations.
Other reading: There is a similar but unrelated thread from back in October regarding this topic on public transit relations.
Please let me know if anyone has concerns about these planned edits.
If I remember correctly, one of the reasons people added these constructed “names” to route relations was to distinguish them in the JOSM relation-editor window. This may or may not still be an issue, but I think this is the issue discussion: #4596 (Relations are not always easily distinguishable) – JOSM
Edit to add: I don’t think this JOSM issue should block these edits – I just wanted to log some history as to why tagging might have been done that way in the past.
I’d say the correct name without descriptive additions would be name=Interstate 77, which also happens to match the sign.
This mitigates practical issues with relation editing and also allows the route relation to show up in a text search for Interstate 77 (e.g. Nominatim if it ever decides to add support for searching road routes).
I support this, and will take care of SD if this is approved. I’ve been deleting descriptive names for SD and county-specific routes (as they provide no more information than the ref tag does), but I’ve left the multi-state relations alone for the time being.
The two discussions are somewhat related. The proposal here is to remove disambiguating suffixes from the name tags of hierarchical route relations, which might be one possible outcome of that discussion too. I agree with this proposal as a first step.
As far as I know, there was never really any deliberate decision to include disambiguators in the relation names. At the time, literally nothing was using OSM for routing and nothing was rendering highway route relations. Only three pieces of software factored into this practice of using disambiguators: openstreetmap-website, JOSM, and Potlatch 1. iD hadn’t been invented yet. In other words, name became a dumping ground for Nowadays, iD distinguishes route relations by cardinal directions in its relation list. It doesn’t distinguish is_in:state, but this is easy to add, and in the meantime, we can tag from and to, which iD also recognizes.
I think we should strive to get more robust label fallbacks into osm-website and JOSM, but backwards compatibility with these tools is not as critical, as you’ve demonstrated with the earlier retagging. We should stay vigilant for ways being added to superrelations erroneously due to confusion about similarly named relations, but explicitly tagged disambiguators didn’t fully mitigate this issue to begin with.
By this logic, we should sign this name=South Interstate West Virginia 77.
I’m pretty confident that there’s no consensus in the United States to mis-tag for the geocoder because it might someday help one specific geocoder that doesn’t support it well. Our responsibility as mappers is to enter correct information into the database. This is a numbered route, not a named one.
Further, you can configure JOSM to display descriptions instead of ref in the relation editor, which I recommend to anyone that works with road route relations. Here is the dialog to edit it:
At first, I was under the impression that this proposal was specifically about the disambiguating suffixes in parentheses, but I think I still agree with it even if it’s about moving the full constructed name out of name, as long as it’s done carefully.
To elaborate, one reason for naming relations differently than the member ways is that only the member ways represent the physical infrastructure and contribute to an address. The roadway can have a cardinal direction in its name that represents the quadrant in a street grid, whereas the route has a different direction indicating the direction of travel. We can still name a freewayname=North Interstate Highway 35 even as it carries southbound Interstate Highway 35:
Many of the relation names date back to when a shield-capable renderer or route-aware router was still aspirational, so nothing was actually using network. But since then, routers such as OSRM and Valhalla and renderers such as OsmAnd and OSM Americana have added sufficient support for network that the constructed names are really only for the benefit of editors. Yet it actually gets in the way of editors potentially synthesizing a fuller label for the relation, because the name could be significant for all it knows.
Nominatim’s developer has cited constructed and descriptive relation names as the reason why it doesn’t index route relations:
How are you detecting name tags to retag? Is it based solely on the pattern “Interstate ref (some optional parenthetical)”? Cardinal directions, state abbreviations, and “(super)” are pretty obvious candidates for removal, but I’m not as sure about stuff like “Interstate 495 West Thru”. “Thru” comes from the signs for the non-local lanes in a local–express configuration; it isn’t a type of special route that would appear on a banner sign or in network. This relation happens to have a modifier tag just in case, but that key is effectively deprecated these days. A more straightforward case is “635 TEXpress”, which is a real brand name that contains a route number. I suggest leaving these cases alone and handling them case by case in the future.
My plan is to use targeted overpass queries and sparse editing in JOSM to pull down potential candidates, and then manual inspection of the routes to be re-tagged. I suppose I could do something with regexes to find patterns, but I think the data set is small enough that a manual review is fine for national routes. Perhaps if I get down to looking at state routes I might need to do more pattern matching but I think that’s down the road.
Sure, I’ll leave off cases like this. I would certainly regard “635 TEXpress” as a name but “Interstate 495 West Thru” screams “constructed name that needs structured tagging to express”. But in the interest in handling the cases that we all agree on, I’ll skip cases that look like that.
I introduced descriptive names to Virginia’s secondary state route relations a few years ago but will work to change the wiki and move the county identifier to the description field to help cleanup existing routes and ensure new relations get tagged properly. These routes do not have an official county designation as they are part of the state network, but numbering is severely re-used across the state (though not* within counties), so I created the constructed name as I couldn’t use the network tag to specify which county(s) a route geographically belongs to.
Does is_in:county support multiple values? Some routes cross county lines (some serpentine their way back and forth) so I want to make sure I capture that information.
When that happens, does VDOT consider it to be two different routes in two different counties? This is the case in some states like California, Nevada, and Ohio. You can tell based on how the mile markers reset at the county line, both on mileposts and in route logs. If so, then you could split the route relation at the county line and tag each relation individually with is_in:county. A winding route might result in multiple splits and two discontiguous relations.
Another option for disambiguation would be from and to, which is well supported by iD. These keys would only make sense if you create a separate relation going in either direction. The values can come from the control cities on distance signs.
Finally, if all else fails, there’s always description or perhaps disambiguator.
Seems like I can follow the VDOT route master in most cases where they have split it by county, and routes that snake along county borders seem to stay contiguous until the road dips significantly into the other. Looking at official VDOT paper maps, distances also seem to reset at county boundaries, so I think this is an alright approach. Since secondary routes are overwhelmingly local roads, there’s no other on-the-ground hints like mileage signs/control cities to go by, and from a driver’s perspective the route is contiguous across boundaries, unless it crosses into an independent city, in which case the road becomes owned by the city and loses its route designation. (This is actually written into Virginia law, and no secondary state route can exceed two miles within an independent city’s limits!)
I’ll let the other mappers who have recently touched these relations know about the change too- there’s a couple of us slowly working through the 48,000 miles of SRs. (If anyone wants to help develop a way to automate the process, my inbox is open!)
I really wish JOSM also included the network because, at least in my city, we have 4 distinctly bannered historic routes, a state highway and a national bike route all numbered 66, frequently concurrent with each other.
