Bike route networks classification (ICN, NCN, RCN and LCN)

General talk
62

I happen to be involved in research initiatives carried out by experts in collaborative design and in the scaling up of design methods to use them in complex ecosystems. It tells me two things: 1) that OSM would definitely be a wonderful research field for them, 2) that there are a lot of collaborative design tools/methods that we do not use, either because of the context or because nobody is in a position to step forward and propose to operate them.

As a consequence, we must rely on everyone’s skill to try and maintain debates on track and moving forward. It is very easy to stall design initiatives, too easy

2 Likes
63

Doomed and stuck? Never! We can always try to improve, but I think redefining these classes with exacter specs that will cover all cpuntries and cases, would not solve problems, and create new ones instead.

If this classification causes well defined problems, or does not provide required information for some specific use cases, then I’m sure we can come up with adaptations and additions.

1 Like
64

A spitball, paper napkin version of talking-point extensions to network values:

1cn approximately or does equal icn
2cn, 3cn approximately or do equal ncn
4cn, 5cn, 6cn, 7cn, 8cn approximately or do equal rcn
9cn approximately or does equal lcn.

For example, in the USA, I can see a case for what we call “quasi-nationals” to be 3cn in this scheme. There is a measure of flexibility of others, which would seem to work as local adjustments reach a harmony. Or at least provide syntactic relief.

In case you hadn’t noticed this approximately leverages admin_level values (something not new, it has appeared in other proposals like for park boundaries). Those are based on political realities (roughly, governments and their structure), while this scheme is more imagined, simply a spitball on a paper napkin. To provide at least a talking-point, a nudge forward.

I know, what is he smoking, right? What are we trying to solve here? More comfort for regional routes that OSM’s tagging scheme is closer to reality? The answer is “lots of things.”

65

This is partly because some communities have attempted to indicate the network as a highway classification, pretty much the converse of the problem here. Mappers from some countries inevitably have difficulty understanding the distinction between networks and functional classifications, because they live in an environment where these two concepts are consistent with each other on the ground and in actual usage. For the rest of us, we have a real-world distinction that we can’t express. That kind of problem should always prompt us to question our tagging system. The good news, perhaps, is that the developer of one of the two main network=**n renderers has already stated their interest in evolving the tagging scheme.

Why not redefine it with more loose categories and let the chips fall where they may? That’s how network=* has developed outside the context of recreational routes. If a more freeform key is too much tagging freedom and we really need categories, why not more than these three or four? It doesn’t seem like a huge problem if not all of them are used everywhere.

The history lesson earlier shows that the three-letter acronyms aren’t sacrosanct. We started with an approach that would’ve been flexible enough for our needs today, but then we took a shortcut, literally tagging for the renderer (predating that term by a couple years). We should be open to revisiting that choice, even if the solution can no longer be as simple as reverting an edit to a wiki page.

66

Cycle route networks are pretty much sui generis and need individual parsing.

I think you could say that the ncn networks in the UK, France, Germany, Denmark, Switzerland and the Netherlands are pretty much of a piece. Then you have countries like Spain and Ireland where there are a handful of individual routes of varying quality, but parsing them as a “network” isn’t going to work. Italy’s kind of between the two.

The US Bicycle Route System is something different entirely, largely as a result of America’s love affair with the automobile and its system of government. (I have a comment saved somewhere from a former Adventure Cycling Association intern explaining why Missoula has half a dozen cycle routes passing through it and Denver has none.) Applying European ncn assumptions to the US really doesn’t work. Australia applies ncn to motorway hard shoulders, which is the sort of nonsense that cycle.travel enjoys snuffing out with extreme prejudice. And so on.

icn routes are even more uneven. EuroVelo is EuroVelo and that’s great. But then there are medium/long-distance touring routes which are akin to European ncn routes but just happen to cross a border: the Avenue Verte, Munich-Venice, Via Claudia Augusta, Alps-Adriatic, etc. I find it difficult to justify giving these any degree of importance above ncn routes.

rcn and lcn… let’s not go there?

One thing I would like to see is more use of type=network, network=bicycle relations. Fairly often you’ll see a city’s favoured bicycle streets mapped in one unholy multilinestring of a route relation just because it renders on OpenCycleMap. That’s really not doing anyone any favours. It’s not a route - let’s not map it as a route.

Ultimately, just as with anything in OSM, specialised renderers/routers will benefit from more granular information about a route. But the broad-brush classifications are probably still necessary for data consumers who take this sort of stuff less seriously.

2 Likes
67

For example, the signed bike routes of Royal Oak, Michigan, are modeled as a sprawling “route” relation. After all, there are Bike Route signs posted at intervals along these streets. lcn=yes on the individual ways would’ve sufficed for OpenCycleMap, but I guess someone wanted osm.org to provide a premade webpage that resembles the official map instead of having to craft an Overpass query.

If network relations can mitigate some of this usage, fine, but I hope mappers don’t think they have to maintain a delicate category hierarchy of the National Expressways of South Korea or the Roads of South Korea, even if named like a network, as in the International European route network. Aside from upsetting Those Who Invented Relations, most of these relations end up woefully incomplete, like the erstwhile New York City Transit Authority, because they’re so abstract and invisible. They’re invisible because few data consumers would realistically traverse a deeply nested hierarchy of categories to obtain the essential attributes, and fewer still would do anything interesting with network relations that can’t be done with route relations alone.

And I really hope no one adds the USBRS and NCN network relations to the same type=supernetwork supernetwork=ncn relation. :grimacing:

These also happen to be one-off routes for the most part rather than part of any broader system. If we were to tag the Via Claudia Augusta with cycle_network=* or osmc:symbol=*, it would probably be a unique value; if we were to add it to a network relation, the relation would have only a single member.

If I had my druthers as a mapper, I would advocate for these one-off routes to have nothing on them that might hint at a broader context. Instead, it would be up to data consumers to hard-code lists of relation IDs to special-case. Or better yet, data consumers would look up the QID in wikidata=* to see if Wikidata says it’s an important route. But since I sometimes sit on the other side of the negotiating table, I can see the benefit of explicit broad-strokes classifications too. They just shouldn’t be so prominent that we end up cramming lots of implied assumptions into them, including the network to which a route belongs.

1 Like
68

OSM-wise, it would require the data user to specify what information they need for a specific use case, then the mappers should come up with a mapping and tagging solution to provide this information. I think this sequence of steps is wise, even if the data user is also involved in mapping and the mapper are also data users.

That way, if we ponder a solution, we mappers can check if it indeed provides the information, and the data user can check if the information is actually and practically available to solve the use case.

If an existing classification is applied differently in different countries, that can be a problem for world-wide applications. I imagine the data user wants as little country specific processing as possible. OTOH if the data user has a system in place to offer country specific rendering and processing, the classification may be too general, and more detailed country specific information could help, if it can be recorded and maintained at an acceptable quality level.

69

I disagree, a route going from Paris to London is clearly international in scope, as is Munich - Venice which is in 3 countries and traverses the Alpes. How could that be seen as “national”? Asking for “importance”, alp traversals surely are very important routes, likely is a route connecting the third and forth city (by metropolitan area population) in Europe, although they may not be longer as some national routes

70

… which brings us to the question that has been burning my fingers for a couple of hours: why are we doing this exactly? what is the practical purpose of this classification (or the practical purposes, plural)?

Maybe that would help us finding what to do?

71

| StC
November 22 |

  • | - |

… which brings us to the question that has been burning my fingers for a couple of hours: why are we doing this exactly? what is the practical purpose of this classification (or the practical purposes, plural)?

I think the idea is to get an impression about the importance, which can help to decide when and how to display these routes on a map, for instance.

72

There is also quality assurance and the associated processes: where to look for authority on what is the current version of the route?

73

Yes, at least for one-off routes, it seems to be about importance, as in the zoom level at which a route appears. This is why importance=* was later proposed (and used quite frequently for other kinds of features). But the renderers that consume network=**n use it also for color-coding routes, as if to distinguish one network from another. Until these renderers adopt an alternative, mappers are torn between the two meanings and will alternate between the two based on what looks good on the map.

It depends, right? If a route primarily serves one country but occasionally crosses over into another, or it’s just an extension into another country for convenience, it could still remain as part of a national network. That can be influenced by real-world conventions. It also happens with road routes straddling borders and some cross-border public transportation routes.

On the other hand, some routes are a significant collaboration among multiple countries and therefore of international interest, regardless of length. These routes may be subdivided into legs that are operated by more local jurisdictions as part of the larger whole. (This is how the entire USBRS works among the states. On paper, a given U.S. Bicycle Route only exists separately within each state. It’s the states’ responsibility to ensure that they connect at border crossings, so ideally these distinctions are transparent to cyclists.)

74

One-off routes, and collections of one-off routes, usually called “network” by their respective operators or issuing bodies.

75

This isn’t the case with Relation: ‪Munich-Venice‬ (‪9624081‬) | OpenStreetMap :slight_smile:
Since Italy and Germany do not share a border, you’ve got to go through Austria for the easiest traverse of the Alps. There’s no extension for convenience.

An example for an extension just for convenience of a ncn-route would be Relation: ‪Radroute Saar-Mosel-Main‬ (‪1245730‬) | OpenStreetMap, with about 10 km (1% of the total length) just over the border in Sarreguemines, France and then leading through Germany to the Czech border.

And so maybe there’s the need for two values

instead of one for icn
If I look at two examples I mentioned before (Vennbahn, VeloRoute SaarLorLux) maybe even more :smiley:

2 Likes
76

To give you proper example: The Rhineland-Palatinate cycling trail is mostly centred around, well, Rhineland-Palatinate or more specifically, its border as closely as you can. It still partially dips outside like NRW (in two separate places) and even France but it makes it barely interstate, let alone international.

77

Again, I think both of us (many of us) are agreeing here. In the continuing thought experiment, expand icn to 0cn + 1cn. You could “let go of” the adherence to approximating admin_level values around there (it was loose to begin with). What I mean is to “wrap our heads around” expanding the number of and kinds of *cns (cycle networks) that we have here on Earth. The way it was born in London and has evolved to the (weirdly effective yet still confusing and kind of broken) smear that we have is maybe 15 years due for a discussion that “expands things.” We should say what we mean using our syntax (tagging). We can do this.

To me, it seems straightforward to “expand into the syntax space” (of *cn). Somehow. My simplistic crutch of a napkin sketch was simply a stepping stone ahead. Expand our syntax to include these multi-flavored routes. There really are a lot of flavors.

2 Likes
78

That wasn’t a question for me - your wording was very clear for me. And yes, there are a great lot of flavours here like the examle of @ManuelB701 , Relation: ‪Rheinland-Pfalz Radroute‬ (‪9455869‬) | OpenStreetMap, with its impressive (for me, I don’t know about the US) covered distance of more than 1000 km, even a bit longer than the German national route D5. With the current use the tagging of both is right: ncn for the D5, rcn for the Rheinland-Pfalz Radroute.
It shows that distance alone doesn’t matter - and it shows that the crossing of national and even international borders is sometimes not of relevance for the classification.

1 Like
79

I earlier this year entered USBR 95 in California (so big it is EIGHT unidirectional routes!) at 1069 miles / ~1720 km. We do have those here (USA / North America). 95 is part of our national (official, numbered) route network, and it is also in Washington state and Alaska, the ferry (where cyclists camp on deck) between them is crucial. There are “several” (currently) other national bike routes in the USA, the quasi-nationals.

It can be, it has been, it seems it still is, sometimes (or often!) difficult to talk about these, as they do differ around the world, even as they are similar around the world. OSM has been talking about this/these for quite a while.

There really are quite a number of quite different (cultural, geographic…) perspectives at work here; there really are a great number of things going on here simultaneously. Harmony seems possible, though with effort.

80

Returning to the question of why. Who needs this level/class information for what.

Routing does not use it, I think? The whole point of these route relations is that the route is already there, no extra routing needed. (Some routers can reroute the route by giving route relation members a much higher priority, but that’s a bit like using a text file to make a robot “automatically” type all the words into a text document.)

Searching then? I don’t know if applications include the network tag in their search engines. Usually not, I think?

Presenting by level, to choose from for trip planning, yes, that I get. If I go somewhere for a weekend, I’ll be looking for local and regional routes n(but I want to see them separately); if I go hiking for a week I will be looking for regional, maybe national routes (but I want to see them separatey, because I will probably walk a part of it). For international hikes I tend to look at the national sections of the international routes, which means I want national and international routes listed.

Does length matter? Sure. But I don’t want to see routes listed in length categories. I want them as described above, with length as a detail, and it’s a bonus if I could sort by length.

The main purpose, I think, is the map: rendering; panning/zooming in and out on routes and sections, with pop-up information. From there my greatest wish is trip planning functionality, but that’s a different subject, and it does not require the network level information.

So I think we are talking about rendering: zooming, styling. and a very practical criterium would be: zooming in from world level, at which zoom level do you want a particular route to appear, when do you want to see details such as names, symbols and maybe operator or “fine grained” specific network information, and practical modifiers such as indication of surface, inclination or sac-scale.

2 Likes
81

Leaving QA and other mapper-centric issues aside, I know that when I’m hiking a route (and also when I’m planning it) I have different expectations of how the route is designed and how it is waysigned depending on its network. But it definitely goes with a situation where there is only one national network with its standardized criteria for accepting new routes.

Maybe this could have consequences on routing? Something like “prefer higher level networks?”