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. ↩︎