That structure sounds useful to me (and to be honest, I don’t see much of a difference to EuroVelo).
As I mentioned, I can see, how I would find USBR 50 in CA and if there is a eastbound and westbound sub-route I would also be able to find that relation. Though I can’t see how to find the “master relation” representing the whole USBR 50.
JOSM’s relation editor (window) has “Parent Relations” and “Child Relations” tab-buttons in addition to its basic-yet-effective presentation of elements and ability to edit them.
Also, many editors and OSM’s website itself will tell you what parent relations are when a relation is “selected” (URL contains …/relation/12345678) as well as displaying to you the child relations (via the website, in a handy pop-out “disclosure triangle”).
Furthermore, in the case of the USBRS itself, we go the extra mile to document the super-relation in a table in our wiki: you can simply “look it up and click on it.”
Sure, just add a filter for the route number:
relation["cycle_network"="US:US"]["ref"="50"](if:
per_member(mtype() == "relation") > 1
);
If that isn’t memorable enough, you can also recurse up to the superrelation:
relation["cycle_network"="US:US"]["ref"="50"];
relation(br)["cycle_network"="US:US"]["ref"="50"];
In a three-tiered structure, both these queries will return multiple route relations, but you can keep recursing up:
relation["network"="US:I"]["ref"="495"];
relation(br)["network"="US:I"]["ref"="495"];
relation(br)["network"="US:I"]["ref"="495"];
I don’t forsee us nesting relations any deeper than this, other than the extra level of a chronology relation in OpenHistoricalMap, but Overpass has a complete syntax for this purpose.
If you’re looking for a specific route’s nationwide relation and only want to consider tags, there are a couple options that depend on us cleaning up tags a bit. Ideally, you’d be able to filter on whether is_in:state=* is present, because that key is only necessary for disambiguation. Unfortunately, mappers have put semicolon-delimited lists of states in there to fill in what they thought was a required field, another unintended consequence of our documentation.
You could also search for a particular Wikipedia article title or Wikidata QID. I spent the weekend creating Wikidata items to represent the statewide USBRs, so now you can reliably search for U.S. Bicycle Route 50 (Q17183491) versus U.S. Bicycle Route 50 in Kansas (Q131170016) based on wikidata=* alone; you only have to recurse up once at most. Those six routes I mentioned earlier are the exception, returning multiple relations at a time, because we don’t have a single relation to represent the statewide route.
I would agree that when nesting relations into super-relations, going beyond three-deep (or three-high) gets mind-boggling.
What does seem helpful (in my experience) is where the syntactic break (of relations becoming agglomerated into a hierarchy) and the semantic break (of say, something like a state vs. federal level, maybe of government, maybe not) are either the same or roughly the same. (In MANY people’s minds…like the widely understood hierarchical distinction between state and national).
“The way we do things around here” (both in state and national routing of automobile, bicycle… routes, though not necessarily of hiking, equestrian and snowmobile routes, for example) largely hews to our political structures. (It is states that build state highways, it is the entire USA, funded through our national-level Congress, which builds federal Interstate highways…).
OSM, in the USA, has either been deliberate or lucky, or both (for the most part, when it comes to routes). Most routes. Well, many routes. There are still fuzzy edges, but some networks of routes (USBRS, I am biased as I am a large contributor) are pretty tightly-defined and are effectively widely-understood to have sound tagging that is clearly documented. Your mileage may vary.
I believe that would depend on the complexity a relation per state gets. Some folks start splitting relations with ~300 members as described in Relation - OpenStreetMap Wiki
So you might end up with multiple relations building up the westbound USBR-50-CA which is building up the USBR-50-CA together with the eastbound part which is in the end building up the USBR-50. So it might be for USBR up to 4 level (worst case).
Using
relation["cycle_network"="US:US"]["ref"="50"]["is_in:state"!~".*"];
seems to be a useful work around, at least after a clean up. Still that feels like more than a workaround and would think a explicit tag stating “this is the master of USBR 50” would be a better solution.
Yes, I was alluding to this earlier: there are a whopping eight relations purporting to represent USBR 95 in California. Two represent a proposed section, so that’s understandable. The rest could be condensed into two relations, one per direction, but it would blow right past the 300-member threshold. It’s OK to have all eight directly inside a statewide route relation. I don’t think we need a relation to represent “northbound USBR 95” as a single entity in a case where it needs to be multiple relations due to length.
All eight relations DO represent USBR 95 in California (there is no “purporting” going on). That isn’t disputed. Zero (not two) represent “proposed” segments, is what is understandable.
These relations were broken up (I speak from first-hand experience editing them) because of their enormous size (thousands and thousands of elements, now only “many hundreds” each, or maybe “low thousands” in the case of “southern”). Their (previously) enormous size made editing unwieldy, even with relatively “big iron” (relatively powerful) computing platforms. This is why OSM doesn’t like gigantic relations: they are hard for most people to edit. “Still large” relations? Well, they may still go >300 members, but they remain editable (with some sluggishness) even with relatively powerful computing platforms.
My bad, I thought I saw a state=proposed in two of them, but I must’ve been mistaken. Serves me right for trying to edit manually in Level0.
Maybe I’m too technical on that point, but I would not base the existence of a dedicated eastbound relation on the qty of member ways. Either it useful to have them or not. I would tend to say no, though if you need to split a relation within a state, splitting them to an eastbound and westbound relation would be valid)
So you would end up with:
Relations 1…n could have a direction=north,south,east,west or could contain both directions. In the latter case, they would have no direction. The level USBR 50 - CA and USBR would never have a direction, the level USBR 50 will never have a is_in:state.
We DO end up with USBRs which are all “at a statewide level” (and the “bottom” of the relational hierarchy, simply a route tagged network=ncn). THEN, we aggregate / agglomerate these into statewide relations, but ONLY in the case of unidirectional routes (one each direction, two per state if unidirectional). But we don’t do this for (single relation) unidirectional relations. THEN, we aggregate / agglomerate these into a single super-relation (of a single route, such as USBR 50).
I hope that is clear. The hierarchy doesn’t extend or go beyond that (at least for USBRS).
Henning, maybe what is apparent to me (though not you? I’d be surprised!) is that it is “a large effort” to enter a statewide (large state especially) route (of hundreds and hundreds of members) as a bidirectional route. Concomitantly, it is “a LARGER effort” to enter two unidirectional routes. Some routes were entered one way, some another (though bidirectional predominates and predates unidirectional routes, USBRS has both). They are not entered “one way versus another” depending on “how useful it would be” (to have one vs another). They are simply entered “as we have the data” and BOTH are “useful.”
“Splitting” a bidirectional route into what is effectively the entry into OSM of two unidirectional routes is actually a fair bit of effort. The latter contains a fair bit more routing information (usually) and so its data are more effort to enter. Both are valid routes, both are useful routes.
Yes, I glossed over the possibility of multiple relations heading in the same direction within the same statewide relation, but that’s what I intended to suggest.
Steve, no I get your point that it might be easier to have one-directional sub-relations. Especially if both directions differs a lot. Though I think on cycling routes that’s only seldom the case.
My aim is only to keep it both practical for us mappers as well as consistent for any data consumers.
So maybe lets wait for a couple of days to maybe get some further input. But it sounds like a x-mas task to get our cycle-relations straight 
And somehow jOSM needs to learn to differentiate the relations in the list 
I admire your aim, but the reality is:
• routes which are relatively straightforward “thru routes” that don’t have a lot of complications or segmented routing are largely bidirectional
• routes which are NOT relatively straightforward and DO have complications (many roundabouts, many separated routing segments…) are largely unidirectional.
I don’t think you will find much consistency there, because both unidirectional routes and bidirectional routes are VALID routes (in the OSM sense of a route expressed as a relation, with the tagging we specify). Mappers: learn to parse both, as both exist. Routers, renderers, other downstream use-case parsers, learn to parse both, as both exist. And both are valid.
Indeed, I left description=* in there so that JOSM users can customize their preferences to label relations based on that key. (disambiguator=* would be even better, since description=* tends to be filled with verbose descriptions.)
iD isn’t off the hook, either: it only shows from=* and to=* if direction=* is missing, and it doesn’t know about is_in:state=*. If the community is satisfied with this approach, then iD can adjust the labeling accordingly.
At least talking for myself, all those roundabouts are not a big issue. The main issue for me here is to understand the forward/backward roles, but using west/east or north/south should make that a lot easier. Though that concept was not obvious for me back when I worked on the USBR 95 CA.
But in the end, both is fine and valid, I agree. The only thing what’s important, that the number of “relation levels” is the same. Like there will be always a USBR <number> relation and there will be always a USBR <number> <state> relation and that relation either contains ways or further sub-relations. If those sub-relations are directional, they should have a direction-tag and should have a matching role in the USBR <number> <state> relation. If they are not, they don’t have that.
I’m not sure where you are getting west/east or north/south and direction-tag. The USBRS neither does this nor documents this. “We” do (OSM does) what we say we do in USBRS wiki.
This includes using only forward and backward role tags in bidirectional routes.
At least my current understanding of routes in the US is, that instead of forward/backward roles west/east or north/south is used.
Mmm, no. Not in a single case. I’m talking about the USBRS specifically. You may be referring to other networks, but you haven’t specified which, if you are.