I have finally found how to fork a thread. I’ll use this brand new skill to elaborate on Minh’s point about superroute.
I’ve worked on dozens of very long relations, consolidating the sub-relation - super-relation structure when I could. All this time, I have never understood why some parent relations had to be different from others and have the superroute tag value. That is… until I found that the JOSM relation editor does not check continuity across member relations unless the parent relation is type=superroute. Since then, I have switched to superroute like everybody else
Can we hope to use our work on Eurovelo to convince the JOSM developers to support sub-relation sorting for all type=route relations?
I have been struggling with this for hiking routes and recently asked what the difference is between a “route of routes”, itself tagged as a route, versus a relation tagged as superroute. I didn’t get a lot of feedback - hopefully something can be clarified here.
Interesting, I had no idea that the JOSM relation editor makes this distinction. It sure would be nice if editors would note any special handling in their taginfo project files, not just the inclusion of a tag in presets.
A special case for superroute was introduced in response to a proposal in JOSM’s issue tracker to replace the route_master part of the PTv2 schema. It seems to have been a conscious choice to promote new tagging rather than a technical need that nested routes couldn’t fulfill. This change appears to correspond to a sudden uptick in usage. Until then, there had only ever been one substantial discussion on the tagging mailing list. I’m unsure if it was for or against superroute per se, because most of the participants seem to have conflated superroute relations with route superrelations.
All I can say is that, from where I sit in the U.S., type=superroute is exceedingly rare compared to nested route relations, which were discussed, documented, and tagged more than a decade earlier. If a separate type=superroute tag is actually solving a problem, I’m unsure why that problem hasn’t surfaced in a country that seems to be surfaced in routes of every shape and color. After all, route relations are the raison d’être of our community’s reference renderer implementation.
A clean distinction between “routes” and “superroutes” would be impractical here anyways, since we have many reasons for nesting routes inside other routes. Many highway routes and long-distance cycling routes are too long to fit in a single relation. Many are actually series of independent routes coordinated among states to meet at common points and share numbering, probably akin to the EuroVelo stages. Even a route that traverses only a single state may need multiple child relations to represent the signposted cardinal directions, which might change up to four times along a ring road.
Sometimes stages of a highway route intentionally overlap or stages of a train route intentionally do not connect. Sometimes the disjointed nature of our routes breaks other tagging schemes’ assumptions and we have to improvise:
These oddities came up during that last tagging list thread about superroute, but only in defense of nesting route relations into superrelations in general, not specifically about crafting a new relation type.
a superroute contains route and/or superroute relations as members
Some mappers put nodes in the route and superroute relations, with roles such as start, end, guidepost. In Node Networks the Node2Node route relations can have the start and end Nodes as members, without a role. I’m ignoring that option for now, as do most applications.
In the JOSM relation editor, the continuity line shows the connections between the member ways in route relations (route mode), but the connections between member routes in superroute relations (superroute mode).
Knooppuntnet Monitor combines these two continuity modes in its unique hierarchy table. I am not sure if the type=* tag makes any difference in Knooppuntnet Monitor, but I guess it doesn’t.
To me, the issues that limit usability in end user applications are
a) gaps in the route signage on the roads (where the operator offers a route section that does not exist on the road)
b) the non-continuous ‘supersuperroutes’ which are in fact collections of discrete routes (swept together by an operator under one flag).
In short, I would very much like to keep the superroute relation, defined more clearly as a relation not containing ways. While a route is a relation containing the ways.
Plus, I would like to have a way to clearly define a collection relation.
This would allow data users to e.g. handle single trails that are just broken up into stages for convenience, different than a collection of separate trails under one name/ref.
I don’t dispute that it should be possible to nest route relations in other relations. However, I’m not sure why this requires a special relation type. You’re expecting the “superroute” to be homogeneous, consisting of only route relations as members that collectively form a single linear geometry. Certainly, a roadway should always be a member of the most specific relation available. However, I don’t think the requirement to be homogeneous or connected would be valid for all or even most nested route relation situations in the U.S.
In my experience, the most common reason to map two route relations and group them together is that a route traverses both sides of a dual carriageway. Whether the child route relations touch depends on whether the dual carriageway becomes a single carriageway at any point. The JOSM validation rule could still be useful, but not in every case.
For example, this super-duper relation represents a route looping around Washington, D.C., entirely on dual and quad carriageways. This is technically a collection of three discrete routes, but no one thinks of it that way in practice, especially since one of them is only 580 feet (177 meters) long in the middle of a bridge, as wide as it is long. Some of the bottom-level route relations touch, but not all of them, because the clockwise and counterclockwise carriageways never meet. (The superrelations in this structure are divided by state, whereas a different route on the same road has superrelations for the clockwise and counterclockwise directions instead, all based on the signs.)
Should these super-duper relations be tagged type=superduperroute? Maybe, but I don’t see the point of making up extra words for things that aren’t that super-duper special. A separate relation type for streets would seem to me like the higher priority. I’m fairly confident most data consumers would care more about distinguishing those from routes based on tags, since route superrelations are already identifiable by their members.
That two-way situation is pretty much specific for bicycle routes. It is handled within one route relation by the backward/forward role system, even when the complete route clockwise uses other ways than counterclockwise. This system also works for the other transport modes. For data use it is a PITA, I think that’s why few applications handle it properly, but here we are.
I know that superroutes can’t be expected to represent only one continous trail (and its counterdirection), even though I can see how tools and applications might profit from the distinction.
For now, let’s use route for the relations containing ways, and superroute for relations containing relations, and preferably not mix way members and relation members. I have pretty much implemented this for hiking/foot routes in Nederland.
I was hoping that someone would mention route_master. There are many things that we can do on a purely linear basis (one single sequence of ways or subrelations), as demonstrated by the handling of forward/backward roles in cycling routes. But at some point we need to realize that the longer the route, the higher the probability that it has some ramifications:
difference between forward and backward routes
approaches, alternatives, etc
routes that are intrinsically branched (e.g. EV17)
temporary branches added because of disruptions
To manage that, we can elaborate on serialization techniques, taking inspiration from the forward/backward scheme. Or we can define something like route_master.
Note that we already have something like route_master in the hiking and cycling context: the parent relation used for node networks, when there are so many ‘branches’ that serialization makes no sense at all.
Personally, I’d suggest that getting the ways that should be in some part of EV17 et al into a relation that is part of EV17, and getting them tagged properly with any other tags helpful to users (surface etc.).
Whether a higher level relationship is expressed as “type=route” or “type=superroute” is secondary. Data consumers (if they are interested) will need to consume both anyway as there are many other type=route and type=superroute.
Now there’s a thing - that relation is almost useless! Do you know of any application using it? Besides Knooppuntnet Analysis, that is. Even Knooppuntnet Planner does not use it.
What the wiki explains is that we need to split large routes. What it does not say is that we need a parent route to gather the resulting bits. Is there a reason why we need a parent for the bits that form a linear or weakly branched structure when we don’t need one for the bits that form a heavily branched structure?
If not, then what’s the point of a separate type=superroute tag, versus the older and much more common practice of nesting routes in other routes (a decade older and almost twice as common by member count)? Nesting routes is equally effective as a solution for long routes outgrowing a single relation.
Another consideration is that the top-level relation is what someone would normally call a “route” in plain language. It’s the lower-level relations that most people would describe as something else – stage, leg, branch, variant, direction, etc. – but we’ve kept them as routes for backwards compatibility.
I’ve wondered about this too. I suppose a route_master relation can incorporate some nuances that make less sense for route. For example, a route master relation can include two variations of the same bus route going in the same direction from and to the same destinations, running at the same time, just because one bus started the route later than another. There are some analogies to the highway routes I’ve given as examples, though they’re rarer on highway routes and much more common on public transportation routes.
I think it comes back to what a layperson would consider to be “the route” on the ground, regardless of the topology in a routing graph. The precise determination varies by context, but at one extreme, I think most people would refuse to call the entirety of a large interconnected network a “route”.
That is understood, but the whole point is that there is a continuum. At one extreme, most EVs are simple lines. Then E2 and E5 have large branches. E9 has many small branches (tidal ways, etc) Then we have some regional hiking routes in France that look like hairy spiders. Then we have “node networks on top of node networks”: a regional network that uses selected nodes from a local network. And finally we have the local node networks.
I fully agree that the nature of these beasts changes along the continuum: linear, branched, network. The question is whether the object ceases to exist at the end of the continuum, in addition to changing nature. I am not at ease with that question. And the “node network on top of a node network” thing makes it even more difficult.
Still, I get Peter’s point about no data user except QA (and maybe indexing) currently taking advantage of the node network relations. I’m trying to understand why, and whether this is going to change in the future. I daresay yes, because I know that operators in France are looking for ways to market their networks more efficiently.
Edit: this also brings us back to how routes were managed originally, and skitour routes are still managed: a series of ways that share tags, without any parent relation. At some point it was decided to add a parent relation. Could there be a similar situation here?
I have seen something similar with hiking relations as well, where a hiking relation contained another one completely, but the longer one had a more difficult scale (i.e. if you don’t want it too difficult, you only go until point x).
The parent and children usually have different tags for from, to, via, distance. Also description, network, operator and note may vary. I use section_ref for the stage count, that obviously varies. This is all information for the end user; it’s up to the application if and how it is used/presented.
If a user wants the whole route, e.g. for a gpx or an elevation profile, you want a superroute at that level, because recombining the route using the tags in the section relations is a tricky business.
Especially if there are variants, or if sections or sectioned routes are reused as parts of other routes.
It’s much better to configure the complexities of the routes using associations based on their OSM id numbers, which is what you do when creating the relation hierarchy.
