The Node Network relations make sense when you (as long as you) actually have truly separate networks. In Nederland, Node Networks started out as small separate networks, each with their own operator. Now, it’s one big network, though the formal operators are the provincial governing bodies. The Node Network relations are just big bags of Nodes and Node2Node routes, and they are of no use to any data user or end user. In Knooppuntnet Analysis you can use them to limit your search area, but you can just as easily use geograpic areas for that.
This is a completely different situation than a collection relation for all variants belonging to long distance route X.
By the way, I think the kind of variant that we’re referring to here is normally mapped as a wholly independent route relation in the U.S. Attaching them to the main route is generally frowned upon, despite the robust documentation about this approach. But variant routes here tend to be distinguished by a banner or suffixed route number, which we can simply tag, so we feel less inclination to associate it with the main route via a relation membership.
It wasn’t necessary, as this is consistent with how the operators themselves document and track special routes, as routes unto themselves. (This terminology comes from highway route planning, but the same planners are responsible for long-distance cycling routes.) As a user, you can still associate the special route with the main route based on an identical ref and a network or cycle_network that shares the same prefix. This requires the network to follow the hierarchical format.
Yes. We also have less formal spurs and such along some older cycling and hiking routes. To my knowledge, some have been included in the main route for expediency.
Here, I just found this example: https://www.gr2013.fr/wp-content/uploads/2016/06/DP-GR2013.pdf (just look at the picture, and please abstract from the facts that this is for hiking rather than cycling and that this operator refuses that its routes are in OSM).
The main operator for hiking in Nederland has a variety of layouts. Some routes are simply one continuous signed route, no variants. Some are a signed route with signed approaches. Some have dog variants, high water variants, excursions, shortcuts. Some are in fact small networks, containing several loops and branches. The latest trend is to add separate day trips (roundtrips) to the routes, offered under the same name and ref as the main route and the “regular variants”.
Personally, I dislike that. A lot. But hey, they are the operator and we have to accommodate what they do out there. They waymark extra roundtrips as “Humptydumpty trail” with the same signs as the main “Humptydumpty trail”, that’s ground truth. I usually have a main route (superroute containing the daily sections as route relations of the ways); then all the variants as separate routes (mostly short approaches and highwater variants); then the separate extras as separate routes. Then I include the main route and the variants in one superdupercollection relation, tagged with the name and ref, I add
“(all variants)” to the name to indicate that it’s the collection, not one trail.
The OSM model of relations in a hierarchy is that it can handle all these variants, as long as we don’t cut off options by making things mandatory or disallowed. So while it’s allright to state how we do things for a particular area, transport mode or case, we need to take care not to apply that as a general norm.
Now to come back to the topic. I think when handling this, in all variants, for the data user and the end user and the maintainers, it helps to know if the relation is a route containing only ways, or a superroute containing sections which together form a single route, or a collection of pieces which together are positioned as “route X”.
This constraint doesn’t require a distinct type=superroute tag. In OSM XML, a <relation> element contains a full list of its members. Merely by loading the relation itself, the data consumer can distinguish a route from a route of routes by the presence or absence of <member type="relation"> elements within. The constraint you’ve expressed is that the relation shouldn’t have a mix of <member type="relation"> and <member type="way">. The only things the data consumer can’t verify from this element alone are that each member relation is a route relation, and that it’s a superrelation rather than a super-duper relation.
Also, to be clear, various disconnected segments aren’t necessarily a route just because they share a number and network. There’s a U.S. Bicycle Route 230 in both Wisconsin and Ohio, but they are two separate routes, both spurs of USBR 30, with no plans to connect them to each other.
To me this confirms that it would be beneficial to tag it rather than to force the data user to detect it.
That’s another argument to use relations for compound routes, rather than discovery. You can be explicit in what is to be regarded as part of the route and what isn’t.
The caveats I mentioned apply equally to type=superroute.
My point is that, to a data consumer, there’s no real difference between checking if the <relation> element has a child <tag k="type" v="superrelation"> element versus checking if it has a child <member type="relation"> element. It’s an artificial distinction that doubles down on the backwards terminology we’ve been using (“route” for a route leg, “superroute” for a route).
If an editor or QA tool needs to verify that a way hasn’t been added directly to a route superrelation, it simply checks whether the <relation> element has both a <member type="relation"> element and a <member type="way"> element. It’s no different than checking that a multipolygon relation has no nodes in it. In Overpass, it requires one extra, quick step or a more readable conditional to find route superrelations. Finding non-relation children or mismatching relation types and networks among the children is easy regardless of the top-level relation’s type.
Yes, I very much agree. There should always be a single top-level relation that represents what a layperson regards as “a route”, no matter how deeply we need to structure the element hierarchy beneath it. On the other hand, we shouldn’t be creating massive relations to represent networks of routes and collections of those networks.
If it’s that easy, I would expect many applications to actually do something with route hierarchies. Maybe I am lacking knowledge, maybe you know many.
Yes, I’m pretty sure what I outlined is exactly how a QA tool would flag this relation as a horrible Frankenstein’s monster and an editor can offer to push a way down to one of the child relations.
What I’m trying to say is that type=superroute makes little difference compared to nested type=routes. The only data consumer I know of that actively consumes nested relations is Waymarked Trails, which equatestype=route superrelations with type=superroute relations. For example, it lists child relations under this type=route superrelation just as it would list one tagged type=superroute. Apart from that, you could consider Wikidata to be another data consumer, but its OpenStreetMap relation ID (P402) property couldn’t care less whether the relation is tagged type=superroute, type=superduperroute, or type=überloopdelooperroute.
You’re probably getting a bit bored of this, but cycle.travel does too (in fact it spits out a couple of warnings about circular relation references every time I run OSRM…).
But for my purposes moving to type=route would make things simpler. type=superroute doesn’t add any value.
(I like the idea upthread of grouping spurs and alternate routes in a route_master relation, as long as the component relations are appropriately tagged without having to refer upwards.)
Sorry, I keep forgetting that. I’m much more familiar with hiking. Now you’re probably gonna say ct supports hiking, too… I have to broaden my view, I’m afraid.
Re: superroute vs route
type=superroute in JOSM triggers the continuity line to show if the member relations connect, geograpically.
type=route in JOSM triggers the continuity line to show if the member ways form a continous line.
Knooppuntnet Monitor combines these two modes in a supercontinuityline for the hierarchy, treating superroute and route as the same. It can do that, I think, because of the preprocessing of the whole hierarchy, while JOSM only has what the user has downloaded.
That is one use case, which to me, as a regular maintainer of a sh!tload of hiking routes, saves a lot of time. Before I discovered this difference, I tagged all routes as type=route. This meant that to check the continuity, I had to open relation editor windows for all the parts, and manually check that the sections actually connected. After changing the superroutes to type=superroute I could see the continuity of the sections at a glance. That saves a lot of time and makes my yearly check of about 30 compound hiking routes with 15-25 sections in each of the main routes manageable.
Second use case:
Information panel of waymarkedtrails. This is the only application I know of that can browse the route hierarchy. It has an information display rule for the routes and sections. The display of a continous route divided into sections could be better than it is now (I am not saying it’s bad!), if the app can be sure that it actually is such a superroute. The information display of a route collection containing all variants could also be fitted to the purpose.
Probably the elevation profile display could also benefit from the distinction.
Now my understanding was that it’s much easier for the application to get the information needed for the distinction in a tag than in a manner that requires processing.
Note that this is all not about rendering or routing. It’s about maintainance including quality management/quality assurance, and about information display for maintainers and end users.
I happen to find those things very important.
And yet again, OSM finds that a tagging “dispute” (well, it’s a discussion right now) is largely answered with how downstream use cases parse one variant of tagging vs. another. I’m not saying this is bad, good or neutral, I’m simply pointing it out as true. This isn’t a particularly obvious aspect of “mapping” (it is a bit more obvious when we more precisely say what we’re talking about is map tagging) and might need pointing out every once in a while. Thanks for reading.
I don’t disagree with this view. Analysis is my favorite use case for OSM data! However, what doesn’t quite make sense to me is how a separate type=superroute tag would be essential for facilitating the QA and analysis use cases, other than the fact that, for instance, JOSM currently looks for this tag specifically instead of also looking for type=route. I’ve already shown that it’s straightforward to detect the same errors on a nested route relation structure, to the extent that mixing relations and ways in the same route is incorrect to begin with.
If I correctly understand the history surrounding this tag, it was essentially an editor-driven tag redefinition. We don’t have a “JOSM/Controversial Decisions” page on the wiki, so I can’t rush to complain there, but I think a lot of this discussion would’ve arisen during any attempt at formalizing the tag through the normal process, without the circular reasoning that JOSM should prefer this tag because JOSM preferred this tag.
