Proposal talk:Use description instead of name for route relations

Use something else, and more specific

description=* is a longer unformatted senetence or paragraph for extra info. It should not be occupied by other data. This prevents description=* from being used for its original purpose. Due to limited length, eg mandating a newline /n after the existing name=* line will conceivably not work either.
In the past, I have mentioned eg label=* somewhere. It would be a tag equivalent to positional label and type=label for the label text.
But it should be emphasized this is a transition solution for existing name=* , and mostly a stop-gap for future new features and attributes. Eg JOSM list will already show description=* (not preferred then note=* if others are not available according to relation.nameOrder preference. https://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation#TextFontproperties ( mappaint.nameOrder for labels on the edit map) iD already supports from=* , to=* , etc tags.
—— Kovposch (talk) 21:09, 7 October 2023 (UTC)

What exactly is being proposed?

The current proposal summary states, "Restrict name=* and associated tags to have the same meaning on route relations as on other OSM elements."

How does the current naming of route relations differ from what you propose? I deal with a number of corner cases:

Highway routes

Near me, the relation for "New York State Route 146" is appropriately nameless. There is a named way, 'Balltown Road' that is a member. This is the usual urban/suburban case. Out in the countryside, the way may be unnamed according to your reasoning. Still, in the case where there are blade signs identifying the way as 'Route 146' and houses with street addresses like '12345 Route 146', to my thinking that has the effect of _also_ naming the way. This is important locally for a several reasons:

1. Different local jurisdictions decide to spell the constructed name differently: "Route 146", "New York 146", "State Highway 146", etc. It's important to have the way name consistent with the signage and the street addresses.
2. Route concurrences are common. Consider a section where NY 28 and NY 30 run concurrently. The buildings in the section retain addresses like '12345 State Route 28', ignoring the concurrence. The blade signs say 'State Route 28'; the route markers and trailblazers bear the numbering of both routes. Once again, it's important for the way to show the 'constructed' name as signed.

For these reasons, it's common locally to have a way name that _appears_ to be constructed from the route network and reference, but is actually carrying information about how the way is signed.

Trails and trail concurrences on highways

Hiking and cycling trails local to me often have short sections that walk the side of a road. Often, this is done because there was no other routing available across private land, or because the trail needs to join the road network in order to use a bridge to cross a waterway or motorway.

1. Nameless ways Locally to me, nameless ways for trails are uncommon. Most ways for stand-alone trails are named with the name of the trail, even if the name is also present in a route relation.
2. Ways named differently from the route because of concurrency. A trail may follow a highway, as at way 20092765 (where the way is named 'Old Piseco Road', and participates in two route relations: Northville-Placid Trail and County Road 24).
3. Ways naturally named differently from the route. It's not necessary to have a route concurrence for a member way to have a name different from the route: way 5595536 is correctly named 'Island View Road' and not inherit the name any of the other relations (and superrelations) that refer to it.
4. 'Senior' or 'dominant' routes. While a concurrence of a trail and a highway almost always acquires the name of the highway, it's not always true that the name of an other nameless segment can be derived from comparing relative importance of the routes. Long Path is a major regional trail, hundreds of km long. The part where it shares tread with Devil's Path (as it does, for instance on way 111804369 is, however, signed 'Devil's Path' and blazed with the red markers of Devil's path, with the aqua ones of Long Path present only at the two junctions where Long Path enters and leaves. Why? Devil's Path was there first, and the signage follows the senior trail.
5. Ways named alike to the route. This is a common case around me, and serves specifically to identify that none of the many reasons for the way name to differ from the route name do _not_ apply!

Routes named for their endpoints

Around me, it's not actually uncommon to have both road and trail names that simply derive from their endpoints. Troy-Schenectady Road is that highway's proper name. Similarly, Pine Hill-West Branch Trail is the proper name of a trail. People who name things can be unimaginative at times.

Routes with "constructed names"

I do consider it a poor practice to name a route if the name is simply constructed from, say, the network and reference. This was done, incorrectly, in some imports. Adding name=New York State Highway 146 to a road route conveys no useful additional information. (Adding the same to a member _way_, as discussed above, does!) For hiking, cycling, and horse routes, sometimes a name like Trail 2 is actually the name that the route goes by, and needs to be carried _somewhere_ in order to be available for navigation and rendering. (In particular, applications such as Waymarked Trails depend on the names of these routes.)

Summary

(I don't consider public transport routes here, because I don't quite understand the conventions that they follow.) There are specific cases, mostly relating to route names being constructed from highway numbers, where constructing a relation name from something like a route number is inappropriate. For a renderer a route name to label a member way might be a sensible default, provided that it is unambiguous. (It would be wise, though, to consider what type of routes are being considered. Naming a driveway according to a bus route that uses it is _not_ a good idea!) When a way is named and signed identically to the name of a parent relation, repeating the name on the way often does convey useful information and is otherwise mostly harmless. It's important that this proposal should claify exactly what is being proposed.

--Kevin Kenny (talk) 22:15, 7 October 2023 (UTC)

@Ke9tv: I interpreted this proposal as a response to the PTv2 schema's insistence that every type=route relation must have a name that adheres to a rigid structure duplicating various other keys, delimited by ASCII art. There have been occasional complaints about this guideline for years, and I'm glad to see Wynndale take the lead in finally resolving this issue. I don't think the proposal necessarily constrains our options in the cases you've helpfully laid out. If anything, it simplifies our decisionmaking because we no longer have to come up with two inconsistent conventions, one for the route relation and another for the constituent ways. – Minh Nguyễn ^💬 01:18, 8 October 2023 (UTC)

Lede example

898331 898331 is at least missing ref=A 205 . Then you need to decide what to use for 3929254 3929254 the entire orbit . type=superroute is dubious as North and South Circular roads are separate A205 and A406, not splitting of one route=road .
And should the Woolwich Ferry be included conceptually to form a complete loop? Although it is via sections of A1020, A117, and A2204. This obviously can't use type=superroute .
If "London Circular Roads" means the two A205 and A406, not the circulating road routing formed, it may even be eg type=cluster .
—— Kovposch (talk) 11:18, 8 October 2023 (UTC)

Why description tag?

For say "Tokyo Metro Tōzai Line Local: Nakano => Nishi-Funabashi" tagging name=* from=* to=* seems entirely sufficient (editors can build label from this tags) Mateusz Konieczny (talk) 10:27, 10 October 2023 (UTC)

In this case, the train class "Local" (not to be confused with the track infrastructure name "Local Line" similar to UK fast or slow line on JR) is not covered by any tags yet. While the service name might be obtained from route=route_master , the train class can't be isolated yet.
As a side note, the data structure of through service / interlining / interconnecting / running between different lines is unclear.
—— Kovposch (talk) 14:24, 10 October 2023 (UTC)

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 (not that particular example) and spamming search. Andrew (talk) 20:25, 10 October 2023 (UTC)

Requesting support in iD and JOSM

Has anyone requested support for labelling based on ref=* from=* and to=* in iD and JOSM? Or searched issues and confirmed that none exist? If we get that support then need for fake names will evaporate Mateusz Konieczny (talk) 06:06, 12 October 2023 (UTC)

@Mateusz Konieczny: iD already supports these automatic labels, although there is a request to discourage mappers from entering from=*, to=*, and via=* on some route relations. – Minh Nguyễn ^💬 19:19, 28 October 2023 (UTC)

@Mateusz Konieczny: I've made a request to JOSM team and they done it. Now I use it in one of my PT-related presets. --Korney San (talk) 19:51, 11 December 2023 (UTC)

Rename proposal?

Would “Name is the name only for route relations” be a better title for this proposal, concentrating on the most important tag in this proposal? Andrew (talk) 19:31, 28 October 2023 (UTC)

I think that it only applies to 'Public transport version 2', other route relation may not have the same suggestion for the name tag. See the proposal https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport&oldid=625726 . Each bus/train etc transportation page has the same 'name' issue e.g https://wiki.openstreetmap.org/wiki/Buses Warin61 (talk) 05:04, 10 November 2023 (UTC)

While only PTv2 had it, this needs to be enforced in other route=* too.
—— Kovposch (talk) 10:10, 10 November 2023 (UTC)

The name=* should remain consistent within OSM for all features. Most other keys, if not all, have consistent meaning and don't require 'enforcement' other than the occasional correction. I have come across a number of leisure=pitch using the name=* to specify the sport played there. Of course I have corrected those. Warin61 (talk) 10:52, 10 November 2023 (UTC)

There are examples for other route types. For road relations: https://lists.openstreetmap.org/pipermail/tagging/2023-October/067662.html, for paths: https://community.openstreetmap.org/t/proposal-use-description-instead-of-name-for-route-relations/104656/34. Sarah Hoffmannʼs talk at SotM EU had more examples. Andrew (talk) 11:30, 11 November 2023 (UTC)

54B Lawrence East

Hello @Wynndale:

You added the example of 304072 304072 with comment "name=54B Lawrence East to Orton Park (after 3pm) ref=54B — ✗ The name here is a description, nothing in this “name” deserves to be part of a name=* tag." The text "54B Lawrence East to Orton Park" is displayed on the headsign of the bus (photo) and is also spoken over an external speaker at every stop. "(after 3pm)" is the only part of this name which isn't seen or heard on the ground. If we don't put this text in the name=*, would tooling attempt to to recreate a... erm... name to display to bus users, and how could it know the correct name format to match what they see on the ground? --Jarek Piórkowski (talk) 01:04, 10 March 2025 (UTC)

This is a "label" or title, not a proper name. Having a sign showing everything doesn't mean it's the whole naming. iD is able to format ref=* , from=* , to=* , via=* , and network=* for labeling sensibly.
OSM is not a bus simulator. It shouldn't replicate the signage of every bus. If you need that, it should have another tag, not appropriating name=* for this other use.
—— Kovposch (talk) 08:57, 10 March 2025 (UTC)

Do you think there are any cases when a PTv2 type=route relation should have a name=*? If yes, which? --Jarek Piórkowski (talk) 03:01, 11 March 2025 (UTC)

If you are asking with buses in mind, it's possible for them to have proper names sometimes. Usually "BRT", especially color-naming lines in US. Of course, it can get complicated with numbered branches. List_of_bus_rapid_transit_systems#United_States
—— Kovposch (talk) 08:52, 11 March 2025 (UTC)

Random non-BRT-advertised examples. It's less common outside USA.

• Locations List_of_Metrobus_routes_in_Virginia#Routes
• Colors List_of_MTA_Maryland_bus_routes#CityLink

—— Kovposch (talk) 10:06, 11 March 2025 (UTC)

Interesting position, thank you for responding. So for this idea, taking for example the Virginia Metrobus line 1A and 1B, there would be four PTv2 type=route relations each with name=Wilson Boulevard–Vienna Line? --Jarek Piórkowski (talk) 00:07, 16 March 2025 (UTC)

I don't know this particular example. This would associate them correctly and usefully.
—— Kovposch (talk) 08:01, 16 March 2025 (UTC)

Cases where destination of a bus route isn't its `to`

I was wondering if you have any thoughts on how you would tag the type=route for TfL route 24 outbound (currently 3523630 3523630). This bus uses "Hampstead Heath" as its headsign (photo on Commons), and if I remember correctly for the destination announced by voice, but per comments above, the headsign shouldn't determine the name=* tag. The last stop of the bus is named "Royal Free Hospital" so presumably this would go in the to=* tag (as tagged currently). Do you believe "Hampstead Heath" should be tagged in the relation at all? --Jarek Piórkowski (talk) 00:15, 16 March 2025 (UTC)

"Towards" is often used for the direction, or an intermediate stop. It's listed as "To: Royal Free Hospital". Could add via=Hampstead Heath first. Interpreting Tag:route=bus strictly, to=* is "destination station" , which would be "<terminal stop> " to be consistent with the controversial name=* format.
On the other hand, it could equally be argued there's no highway=bus_stop + name=Hampstead Heath served or even existing, although via=* may have a more relaxed requirement. There may be a need to distinguish via=* for less important waypoints or roads advertising how the bus is routed, or a special service where certain stops are only served by this route=bus variant, and these significant locations or landmarks to travel to. Perhaps destination=* could be proposed here. It would be consistent with other uses, and emulate the signage at the same time.
Ideally in the real world, alternating display of "Hampstead Heath 24" and "Royal Free Hospital 24" can be shown, as done in other systems elsewhere. I don't know whether this has been considered by TfL before, or fits their standards.
—— Kovposch (talk) 08:18, 16 March 2025 (UTC)

Just to clarify, Hampstead Heath (both the park 664755005 664755005 and the railway station 6991113888 6991113888) is beyond the final stop Royal Free Hospital 469779509 469779509, so it is not via=Hampstead Heath. --Jarek Piórkowski (talk) 15:32, 16 March 2025 (UTC)