@Minh_Nguyen started a discussion on one of my changesets regarding superrelations and I believe it’s better to drag the discussion to a wider audience.
On super relation the term is explained as a relation only containing other relations. Two samples are given on that site:
A superroute is defined as a collection of route-relation containing smaller chunks of the overall route and should contain only other relations, no ways or nodes. As well the defined members of route-relations are ways and nodes only (except members with the role information). That differentiation is not described as a hierarchy of relations, just separates routes containing actual geometry from relations containing just other route-relations.
I followed that principle on USBRS bicycle routes, though it seems on road-routes a normal type=route relation is used and the name is used to contain that information. Like Relation: US 1 (super) (112245) | OpenStreetMap, where a artificial (super) was added. To be honest, I’m not a big fan of using name to store that kind of information.
In my opinion, those names should be moved to description. A bicycle route’s identity is completely decribed by the route, network, and ref tags. The use of name in that way is just a hack to make it look nice in JOSM.
Agree, though the main question is whether US cycle routes should using type=superroute (as described in the route-relation wiki page) or type=route (as it’s common for road-routes in the US) for their overall relation.
In Europe we use superroute more and more, but I’m not sure that we do it for good reasons. Personally the only reason I switch from route to superroute is to accomodate the JOSM relation editor who otherwise does not display its continuity hints.
Conceptually, the superroute type does not solve much and the difference with route is not clear cut. It does not help to manage non-linear (e.g. Y-shaped) routes for instance.
Edit: just read the changeset comments, agree with Minh
As I understand type=superroute the aim is only to differentiate between a route, containing ways and nodes only, as defined for a type=route and a collection of route-segments in a explicit way. Is the concept perfect, I don’t know. At least the concept is better than using tags like description,note or name in my opinion.
It’s not aiming solving anything else. Like the typical north/south or east/west problem, in the US we have with the route-road. So the overall question is, what’s more important: Having all route=* in the Us following the same concept or use a explicit tag for the routes, where it’s possible based on current tagging definitions.
Somehow there seems to be a need to differentiate “superrelations” from it’s children. Otherwise most of the none-superrelations have “(super)” or some other term in its name or description.
As well it’s solves the “theoretical problem”, that type=route is only allowed to have ways and nodes (see: Relation:route - OpenStreetMap Wiki).
If there is a need to differentiate two things, it makes totally sense to me, using a definite tag for it in OSM compared to just describe it in words and at least jOSM is making use of that. As well searching those relations is possible, which is rather random if there is no tag for it.
But, please keep this discussion to the question related to how US community prefers it. Please start a new discussion in the general category if you want to discuss about it in general.
type=superroute is ill-suited to the U.S. Bicycle Route System. About a year ago, there was a broader discussion about route superrelations versus superroute relations in the context of EuroVelo. I summarized the history at that time, worth a read:
type=superroute is ostensibly a solution for when we must split a long route relation at a border or some arbitrary point, so JOSM helpfully ensures that the sum geometry of all the members remains linear. However, most route superrelations exist in the U.S. for a deeper reason. To understand why the USBRS in particular doesn’t need type=superroute, one needs to understand how highway routes are structured in the U.S. The two national route networks – Interstates and U.S. Routes – are technically loose confederations of routes designated by states and coordinated by a nonprofit organization, AASHTO. The federal government only sets standards and provides funding.
Officially, a route like Interstate 70 is actually a collection of 10 separate routes that share the same number and meet at each state line. If you look closely, some states even deface the shield with the state name to let you know it’s actually a state route. In OSM, the 10 route relations may differ in a variety of keys, such as official_name=*, operator=*, and wikipedia=*. Technically, this means we shouldn’t even map I-70 as a single relation, as relations aren’t categories. However, the general public normally doesn’t care about these distinctions, so we attempt to model I-70 as if it’s a single route at the same time that we also model each of the individual routes below it.
The USBRS is based on same principles as the U.S. Route network, including this loose organization. Earlier this year, when the Indiana Department of Transportation wanted to extend USBR 37 into the state from neighboring Illinois, they had to formally petition AASHTO to establish a new USBR 37, not modify the existing one.[1] Until a year ago, most USBRs had completely different shields depending on the state. Unlike its neighbors, Virginia still uses the pre-2009 “acorn”.
Not every USBR crosses state lines. If a route only exists in a single state, there’s only a single route relation without a superrelation of any kind. Someone querying OSM data would find it surprising that some USBRs are modeled as routes while others are modeled as a “superroute”, whatever that is.
Another similarity between road routes and bike routes is that each route has two official cardinal directions. This is important information about the route that users often need to know during turn-by-turn navigation. You can’t necessarily derive these directions from the overall route geometry. OSRM and Valhalla don’t care whether the route is linear or contiguous, but they do care that the cardinal direction is tagged somehow.
So far, we have poor coverage of cardinal directions. We mostly only tag them in one-way couplets through downtown areas, setting the cardinal direction as a roadway’s role in the route relation. Sometimes this conflicts with the need to specify whether the route traverses the roadway in the forward or backward direction. For example, in Augusta, Maine, this street carries only the northbound direction of USBR 1. The role needs to be forward or north but can’t be both simultaneously.
Cardinal directions are also found in public transportation routes. Consistent with the PTv2 schema, some mappers have gone through the trouble of refactoring a USBR route relation into a pair of linear route relations, one per direction. This allows the direction to be tagged as direction=* on the route relation.
Unfortunately, the combination of per-state routes and per-direction routes means that two levels of relations aren’t enough: we need a relation to join both directions within a state and another relation to join all the states’ sections of the route. Otherwise, there’s no way to refer to Maine’s USBR 1 as a whole – which is closer to the real-world concept of a route than any of the other relations. Currently, there are six USBRs for which OSM lacks a coherent route relation due to cardinal directions: 15 in Georgia, 21 in Georgia, 23 in Tennessee, 66 in Oklahoma, 95 in California, and 201 in Maryland.
If we insert an intermediate relation for the route within a state, then what should the topmost relation be? A route superrelation can contain another route superrelation, but can a “superroute” contain another “superroute”, or do we need to coin a different tag for the topmost relation? Moreover, I don’t think member order really matters in one of these superrelations anyways. No one will think we’re telling them to bike southbound across Alaska on USBR 95, then go back to the starting point, then take a flight to Seattle, bike south to Oregon, turn around and go back to Seattle, take a flight to California…
I support removing “(super)” and other disambiguators from the name=* tags of these relations. It’s an old convention that only persists through force of habit. We’re already discussing removing these names, and not just from route superrelations.
I can easily add a few lines of code to iD to automatically append “(super)” to the label if the relation only contains relations, making type=superroute completely redundant. JOSM could do the same. However, we have ample evidence that this label alone does nothing to prevent inattentive mappers from adding ways directly to the superrelation anyways. Better yet, editors could warn when a route relation contains a mix of element types. (That would be easier for iD once id-tagging-schema starts tracking the expected element types and roles in a machine-readable format.)
That’s because superrelations have always been seen as a special case. Long before JOSM’s developers gave us type=superroute, this wiki page and the dedicated page on superrelations needed to sell skeptical mappers on the idea of nesting relations in the first place. The implicit expectation was that the parent relation would still be type=route, not type=superroute.
This is a common misconception. In fact, if you have the relation’s tags, you almost certainly have enough information about the relation’s members to distinguish between a route relation and a route superrelation. The only way to lack this information is with out tags; in OverpassQL, but you can’t open just those tags in JOSM for editing. type=superroute does explicitly indicate the intention of being a superrelation, though I don’t think this is much of a benefit in practice. A validator shouldn’t suppress warnings about ways in a superrelation just because it has type=superroute.
Search this database for the route number 37 and the year 2024. ↩︎
Do I understand it correct, that there is no such one USBR 50, but a USBR 50 in CA and another USBR 50 in NV and another USBR 50 in OH and so on?
If that’s the case, based on the mantra “relations are no collections” there should be no such superrelation for USBR routes routes. Since there is no such one object exist in reality.
How can you know whether the relation was intended as a route-relation, but someone added by mistake a relation to it or whether it was intended a superrelation and someone added by mistake a way or node?
Again, how do you know the intention, if you receive a relation containing both ways and relations?
You can’t derive this information from the relation itself. That it’s a superrelation should be a property of the relation. Of course that not necessarily needs to be a different type.
Correct – technically. However, an ordinary layperson would roll their eyes around and around if we insist that an Interstate highway or a U.S. Bicycle Route cannot cross state lines, because that is the entire point!
The longstanding convention is that any mix of relation members and way members in the same type=route relation is a mistake. This is implied in the documentation you cited, by the requirement that (in the general case) the members are all ways, followed by a long discourse about superrelations.
Introducing type=superroute is like saying we need a new relation type for boundaries that have capitals, because how else would we know whether it’s intended to have an admin_centre member way? I suspect JOSM’s developers promoted what had been a rare tag in order to avoid having to write a for loop. But no data consumer insists on this type; they only support it as an alias of type=route.
I realize you thought you were just following a practice that has taken hold in some parts of OSM. In my opinion, we should view that practice more critically, and we should strive to structure all three types of AASHTO-coordinated routes consistently.
I added direction=* and is_in:state=* based on the name=* tag. I removed the name=* tag, but for the benefit of editors, I left the old name in description=* and also set from=* and to=* to the routes’ commonly stated terminus locations.
The next step, in my opinion, would be to introduce superrelations for these six routes that correspond to individual states (excluding USBR 621, which is only in Georgia). Of these routes, only USBR 95 in California is split at arbitrary points. However, I would support consolidating its relations, since together they’d be well under the 32,000-member limit per direction. (I’m also unsure that the unapproved portions of the route should really be part of the superrelation as they are now.)
Before that step we should think about how a super-relation for routes in the US should look like and document that somewhere in the wiki.
As mentioned previously, I’m not insisting on type=superroute though I prefer to have those relations somehow identifiable.
Like if I want to find USBR 50 in CA, I can search for is_in:state=CA, cycle_network=US:US and ref=95direction=northand I would get somehow the north-bound route-relation(s). That’s ok.
But do we want one layer containing all north-bound state-relations and then one layer combining north and south or do we want to have just one layer and using roles to differentiate north and south? How would someone can address such kind of relation(s)?
Edit: If we want to clean-up all superroutes and somehow replace them with something else, we need also take a look in route=road-relations, as it also seems to be used in there.
I don’t blame you for missing this documentation. The USBRS page has a lot of text on it that buried the passage about type=route. In looking for something like “use X tag on superrelations”, you might’ve missed the point on the “Route directions” page about the superrelation having “the same tags as” its members. The documentation needs to be clearer, now that type=superroute is documented elsewhere on a dedicated page.
Cardinal directions can do funny things. An L-shaped route or a loop route can switch directions multiple times while maintaining continuity. To keep things simple, one relation can combine all the route relations for USBR 95 within California. JOSM can try to sort this superrelation into a ring if it wants, though there are plenty of routes that it definitely can’t sort into a proper ring no matter how we structure it. For the handful of data consumers that support superrelations, the sort order doesn’t matter anyways.
The cardinal direction roles have been discouraged for a few years, partly because of the conflict I mentioned earlier, but we tolerate them as a form of “technical debt”. After all, when you’re remodeling a short stretch of road to have a dual carriageway, you probably don’t want to have to refactor the entire statewide route relation in the same changeset. We probably should make a concerted effort to clean up relations that have cardinal direction roles.
If a route relation has any relation members, it’s a route superrelation by definition, even if it also has way members by mistake. In OverpassQL, you can easily filter relations by the types of their members. For example, this finds every USBRS superrelation, regardless of type=* or name=*:
You would need to decide. Either USBR 50 CA is the highest level existing in the US and there is nothing on top or there is a USBR 50. If second, then it’s similar principle like EuroVelo in Europe and USBR 50 is following then USBR 50 CA in that area. Or there is no such thing as USBR 50, then OSM should not have such object in it’s database and everyone could create such kind of collection of all USBR 50… in a smiliar way as we would do for finding all hospitals,…
My aim was to find the one relation representing the USBR 50 (if that is existing) and I do not see how your search reliable get me there. Though with tagging that relation somehow differently, that would be possible without issues.
There is also, in Europe at least, the question of beasts that are half routes and half networks. For instance a “hiking route” (marketed as such) that consists of four intertwined loops. Or European hiking route E2 that has a West branch and an East branch.
That is indeed both what happened (on my part) and excellent detective work by Minh. I “went along with” a newer-style of tagging, perhaps without realizing that it could have unintended consequences. To be clear, “everything (regarding US route relations) was working fine” before I did this.
To make my (strong) feelings about it clear: the introduction of type=superroute seems superfluous to me, despite my inclusion of it in the USBRS wiki. From my perspective (North America, others…) it isn’t needed. I’d be happy to delete that from the wiki if others find that more correct or more precise,
If our USBRS wiki text needs cleaning up / tightening up, more brevity, I’m the first to suggest “edit at will, please.” I’m not a perfect wiki author and I’m blowing bubbles as best I can (given the chewing gum around here, which is plenty). I welcome the shared fabrics of our map (data) and our wiki (data).
Whether USBR 50 is a single nationwide route or a collection of statewide routes is a matter of perspective. There are two perfectly correct answers, not a coincidence in a country composed of sovereign states. Why not accommodate both perspectives, like this:
USBR 50
USBR 50 in California
eastbound
westbound
USBR 50 in Indiana
eastbound
westbound
…
We already have this structure for some Interstate and U.S. Routes. For example, the members of Interstate 495 are statewide relations, including, hilariously, a 0.11-mile-long (0.18 km) route in the middle of a bridge within the District of Columbia, maintained by the Maryland Department of Transportation. This three-tiered structure used to be more common, though @revent went through a few years ago to flatten the structure for some Interstates.
An alternative would be what happened to Interstate 10 in Arizona, where the eastbound and westbound relations somehow wound up as members of independent nationwide and statewide superrelations by mistake. But I’m not sure that multiple inheritance brings any benefits other than to confuse mappers further.
There are a number of ways to see this indeed. USBR 50 is an incomplete single thing: a national bicycle route. It ALSO happens to be made up (as it completes) of state-by-state segments. (Just like Interstate highways in the USA). In OSM, as data structures. Additionally, the way that Minh characterizes eastbound and westbound in both California, Indiana (and other states…) is optional. Here, these are denoted as “these two states are two unidirectional routes.” However, it’s perfectly acceptable in OSM to have one of these components be a (single relation) bidirectional route (with roles forward or backward on members with “only in this direction travel.”)
And a relation of relations (a super-relation, by definition) can contain mixes of these. And OSM knows what we mean by that. And these distinctions and even what might be subtle aspects are (largely) documented in our (USBRS, for example, for that particular network) wiki.
As the wet clay of “under construction” continues to be molded, sometimes new unidirectional routes are added, sometimes bidirectional routes are added, sometimes new members are added to super-relations. It’s all documented. It works. We know what we mean by these things (and how we do this).