Relation types not shown for type=superroute

[SomeoneElseOSM]

URL

https://community.openstreetmap.org/t/beginners-guide-to-route-relations/105018/8

How to reproduce the issue?

Browse to https://www.openstreetmap.org/#map=20/54.27619/-0.39679

Edit with iD

Select way https://www.openstreetmap.org/way/1053144093

Scroll down to "choose a parent relation"

The relation type of the superroute is not shown, leading to lots of people accidentally adding ways to superrelations. In the UK I regularly fish these out and add to the actual relation, like at https://www.openstreetmap.org/changeset/142663029 .

Screenshot(s) or anything else?

https://community-cdn.openstreetmap.org/uploads/default/optimized/2X/8/882ea1f84ee04954765a6dbf48dc44a96984b82d_2_651x500.jpeg

Which deployed environments do you see the issue in?

Released version at openstreetmap.org/edit

What version numbers does this issue effect?

2.27.1

Which browsers are you seeing this problem on?

Firefox

[1ec5]

“Relation” is the generic label for any unrecognized relation type. This label also appears in other places, such as the change summary in the save screen, and is localizable.

Most commonly, when a non–public transportation route relation needs more structure or exceeds the limits of a relation, it is nested inside another route relation – a route “superrelation”. To disambiguate the two similarly tagged relations, mappers commonly add a name containing a suffix such as “(super)”. This proposal would formalize this practice but in the description key instead.

The superroute relation type seems to have been the result of someone mishearing “route superrelation” and transposing it as “superroute relation”. The wiki talk page has some strongly worded criticism. The one data consumer I know of that supports superroute relations, Waymarked Trails, prefers nested routes. If there needs to be a separate relation type for this kind of nesting, I wonder why route_master was never considered.

When someone adds a way to a route superrelation, it isn’t as much of a problem as when they add it to a superroute relation. The few data consumers that recognize non–public transportation route relations get all the tags they need from the immediate route relation, which would have the same basic tags anyways.

Even if there isn’t enough consensus yet to surface superroute relations as a first-class concept in iD, a hidden preset for this relation type would at least make the relation label more descriptive and harder to confuse with the nested route relations. The id-tagging-schema repository is the place to request a preset for a new relation type, searchable or not.

[SomeoneElseOSM]

@1ec5 You've linked to quite a lot of wikinonsense there :)

The statement on https://wiki.openstreetmap.org/wiki/Super-relation that "Nested relations are virtually undocumented and rarely used" is ... just not true. Even in my small corner of the world, a quick glance at https://github.com/SomeoneElseOSM/database_qa_scripts/blob/main/osm_ldp1 (and ldp2 and ldp3) finds quite a lot of relations split into parts because they are too big to manage.

It's probably best to draw a veil over the talk page argument between two of our more opinionated contributors that you link to too.

Let me ask the question another way. Imagine that I wanted to add https://www.openstreetmap.org/way/1053144093 to "The Cleveland Way". How would I know to add it to https://www.openstreetmap.org/relation/31112 not https://www.openstreetmap.org/relation/4087652 ?

When I recently split the adjacent Wolds Way into https://www.openstreetmap.org/relation/78028 and https://www.openstreetmap.org/relation/16327210 , with https://www.openstreetmap.org/relation/16327216 as the "superroute" (or whatever you want to call it), how would I have done that in iD? FWIW I did that in Potlatch (see https://www.openstreetmap.org/changeset/141232629 ) because I'm not an utter masochist, but it would have been possible to do it in JOSM.

[1ec5]

The statement on https://wiki.openstreetmap.org/wiki/Super-relation that "Nested relations are virtually undocumented and rarely used" is ... just not true. Even in my small corner of the world, a quick glance at https://github.com/SomeoneElseOSM/database_qa_scripts/blob/main/osm_ldp1 (and ldp2 and ldp3) finds quite a lot of relations split into parts because they are too big to manage.

I agree. Superrelations may have been relatively rare globally in 2011 when that statement was added, but even then they were the preferred solution for modeling Interstate and U.S. Routes in the United States, which need a hierarchical structure due to state-level management and extreme overall lengths. I think superroute was just a case of the left hand not talking to the right hand, and when the hands finally talked, there was a miscommunication.

Let me ask the question another way. Imagine that I wanted to add https://www.openstreetmap.org/way/1053144093 to "The Cleveland Way". How would I know to add it to https://www.openstreetmap.org/relation/31112 not https://www.openstreetmap.org/relation/4087652 ?

I already acknowledged that the UI isn’t as intuitive as it can be. The solution at a minimum is to add an unsearchable preset for superroute relations to id-tagging-schema, so that the list will read “Superroute Cleveland Way” versus “Hiking Route Cleveland Way”. But I wouldn’t rule out the continuing potential for confusion among less experienced mappers, since you would still need to know the difference between a “route” and a “superroute”, the latter being OSM jargon that sometimes conflicts with actual route names.

When I recently split the adjacent Wolds Way into https://www.openstreetmap.org/relation/78028 and https://www.openstreetmap.org/relation/16327210 , with https://www.openstreetmap.org/relation/16327216 as the "superroute" (or whatever you want to call it), how would I have done that in iD? FWIW I did that in Potlatch (see https://www.openstreetmap.org/changeset/141232629 ) because I'm not an utter masochist, but it would have been possible to do it in JOSM.

It is possible to create a relation of an unrecognized type in iD: at the bottom of the “Select feature type” menu is a generic “Relation” preset. This is the one you were seeing labeled. Select that preset and set the Type field to the desired type=* value. Alternatively, you could create a Hiking Route with nested Hiking Routes.

[DujaOSM]

As a workaround, why don't we add a changeset validation whereby a super-relation route may only contain other relations, not individual ways?

I have a feeling that changeset validation has been under-utilized, or rather, mis-utilized: it complains about quite mundane features such as ditch-path crossings or untagged objects, but lets through quite glaring errors that would be relatively easily to detect at commit time (#9154, #8167, just the ones I reported).

[DujaOSM]

Ah, we can't do that really:
Relation:superroute

The older and simpler approach, however, is to tag the superrelation as a type=route containing the shorter type=route relations recursively with appropriate role=*.

Thus, there's no way to distinguish simple routes and super-routes only by tagging (since both can be type=route). I guess I would support automated re-tagging of all super-routes to use type=superroute, but there's a long way there...

[SomeoneElseOSM]

@DujaOSM As an aside, I wouldn't rely on the OSM wiki for documentation in this area at all. I'd look instead about how these features are actually mapped and tagged. A number of people have updated wiki pages based on their limited experience in their local area and the assumption that "everyone else everywhere else in the world also does it that way".

For routes and roles https://taginfo.openstreetmap.org/relations is a better place to get a global picture (e.g. search for relation types and search for "route" - 4 versions have > 1000 usage).

However, "Thus, there's no way to distinguish simple routes and super-routes only by tagging (since both can be type=route)." is correct, but that's not the original request here - that was to for the UI to show those that have been mapped that way.

[1ec5]

To disambiguate the two similarly tagged relations, mappers commonly add a name containing a suffix such as “(super)”.

To avoid confusion, iD could add a special case to check if a route relation contains another route relation and append this bit the parent relation’s label (not the name tag) in the relation list.

iD/modules/util/util.js

Line 182 in bb17d5c

export function utilDisplayName(entity) {