Didn’t know that, thanks!
At the same time, the sytem as it has developed, manages to describe almost all recreational routes around the world, in a way that is understandable by mappers, data users and end users. Even the infamous Node Networks have been fit into the system, after first hijacking the regional scope to mean “this is a node network”.
The four scope levels are assigned by country communities as they see fit, which means that the lengths may differ, and that is no problem. A national route in Nederland is shorter than a national route in Australia, that’s reality and everybody understands that. Regional may mean strictly within a province for one country, or within one nature reserve even if it spans several administrative regions or crosses borders. No problem!
If a route crosses controlled borders, mappers will be more likely to assign i*n, where uncontrolles (free) borders may not count for much. No problem, everything can be fit in nicely according to reality.
The cycle_network= tag accommodates for recreational routes what network= does not: specify to which specific named (mostly national) networks the routes belong. Operators and administrations like to call any collection of routes having a specified purpose a “network”, usually with a nice sounding name, construction specifics, signposting specifics, special reference codes, et cetera, in particular for cycling infrastructure. Important to record, and helpful for end users, because it usually determines what type of signpost they have to look for.
Even though some aspects can be criticized, e.g. the use of name= for descriptions instead of true names, I think the system is a success, and it is one of the areas in which OpenStreetMap excels.
1 Like
So, the cyclists plagued the world with rwn, lcn and other ihn values for the network tag, then saw the mess that they had created and invented their own cycle_network, leaving others to deal with the mess ? 
4 Likes
For sure, it is simple to consume. It becomes a problem in bigger countries that use more admin_levels, where the words “local” and “regional” can mean different things to different people because there aren’t enough slots to fit these levels into.
Here in France/Spain/Belgium/… we also have the issue of local international trails…
Nederland also has some national trails, regional trails and local trails that cross a border. And node network routes crossing a border, of course. Usually we easily agree whether it’s truly an international route or a Dutch national/regional/local route with a cross-border section.
One route has a Dutch section and a more or less parallel German section, with a number of cross-border connections. There are arguments to call that international, and arguments for national , and arguments for regional. Let me see… it’s mapped as rwn now. It’s in a cross-border natural region, and the route is named after the region, so that makes sense.
2 Likes
It sounds like one school of thought is that network should indicate the geographic scope of the individual route, whereas other mappers would use network=* to indicate the geographic scope of the network of routes to which the route belongs.
I’m more familiar with the latter approach. For example, the Ellis Spur Bikeway is part of a state bike route network, so we tag it as network=rcn cycle_network=US:OH. But it measures only 0.3 miles (0.5 km), shorter than many small towns’ bike routes. Those routes are tagged network=lcn because the geographic scope of the network as a whole is local.
Briefly, very early on, network=* was documented to be essentially a measure of importance of the individual route by length. However, this definition got split off into an importance proposal that ultimately went nowhere, at least for route relations.
1 Like
Hmm… both make sense and are often the same, actually. Our national routes often cross the whole country, or part of it but in that case they belong to one of the national networks of such routes. The national ‘networks’ are more like collections of longish routes.
Regional routes however, can be just as long but stay in a region or province. The individual routes are labelled r*n. You could also say that e.g. the collection of all the cycling routes in a region is the regional cycling network.
Then there are the local loops, in Nederland usually also operated by a province or a regional recreation organization. They often form a regional network or regional collection of local routes. Here, the scope of the network really differs from the scope of the routes. (I’m picturing local foot routes now; most cycling routes are not local). But most of these regional collections started as a local ‘network’ of the loops starting from one village or town.
Something similar has happened with node networks, which started as a way to navigate along the local routes, switching routes at points where they cross each other. First, each town had its own growing node network; then they connected to surrounding node networks, then they started merging into regional node networks; and now Nederland is in fact one big node network. The operators are the provinces, and in OSM we have one to three node networks per province (and some non-administrative regions). Which explains why we tag the node2node connection routes as (belonging to) regional networks, while the individual routes are clearly local.
In short, it’s not either or, but and and. And, despite the seeming mess, it’s amazing what this route mapping system can do!
1 Like
This is a different meaning of network than what network=* represents. For example, every street and highway within a city’s boundary belongs to “the city street network”, but this usually doesn’t mean that every street and highway belongs to the same network of designated routes.
It may be a difference without a distinction in some places by coincidence, such as in a region with few routes to speak of, but no one should be making this assumption globally. Otherwise, the network=* key would be pointless, tantamount to is_in=*.
This reminds me of how Ohio’s state bike routes developed: from a Word document posted online by a daydreaming cyclist-cartographer,[1] to some unofficial signs put up by volunteers, to official adoption by various park managers and eventually the state highway department. The campaign to adopt these numbers not only resulted in official route signs but also promoted the development of critical links between the local trails. All the while, the counties, cities, and villages have continued to operate their respective physical trail sections.
More recently, the system has strengthened to the point that some of these state bike route designations are being replaced by U.S. Bicycle Routes. The USBRS is coordinated by the states at a national level, but in terms of sheer geographic scale, it’s more comparable to international route systems like EuroVelo than to other national systems like the UK’s NCN.
Unfortunately, some people see the documentation for network=* and get the impression that it’s a basic form of geocoding or a kind of organizational chart. But in the U.S., we have no choice but to use it instead for the level of cross-border coordination that has resulted in a coherent numbering system. The logical next step is to name the system itself as a cycle_network=*.
I don’t disagree; we’ve managed to make it work so far. That said, what cycle_network=* shows is that we can unlock additional benefits by specifically identifying the network, as we do for other kinds of routes (route=road, route=bus, etc.). The focus on the three-letter network=* classifications limits maps to a simplistic system of color-coded routes, even when that isn’t how map users are supposed to use the routes.
One longstanding goal of the U.S. community is to start rendering route shields for hiking and cycling routes, just as we do for highway routes, for consistency with what’s on the ground. OSM Americana or a similar style would be using cycle_network=* to choose a shield and mostly ignoring the three-letter network=* classifications, just as it already uses network=* to choose shields for road route and mostly ignores the highway=* classifications. The more simplistic classification system might not go away ever, but it’ll hopefully decrease in importance.
Historically, the global community has relied on osmc:symbol=* and wiki:symbol=* to encode the appearance of the route markers along each individual route, but the OSMC symbol syntax is far too simplistic for our route shields. It also forces data consumers to guess whether any two routes are supposed to be related. Some otherwise coherent route networks don’t even have a consistent shield design as expressed in OSMC symbol syntax.
It’s unfortunate that data consumers have to treat recreational route networks differently than other kind of route networks. For now, we can work around this problem with iterative refinement: there’s some analogous usage of hiking_network=* and walking_network=* as well. In the long term, maybe we should have a goal of unifying network tagging across the various route types, so that the difference between, say, New York State Route 199 and New York State Bicycle Route 199 can be merely route=road versus route=bicycle.
The original document is sadly lost to time, but another cycling enthusiast reproduced part of it as part of a campaign to adopt it officially. ↩︎
1 Like
I should have been more clear - I meant, The collection of all waymarked recreational cycling routes can be seen as the regional recreational cycling network. To be even more clear (to make matters even worse?), the recreational cycling routes often use roads and paths that are not part of what the road authorities would call the cycling infrastructure (of course, they also call that the cycling network!). And, many fine cycleways and cyclable roads are not part of any recreational cycling route. Especially the cycleways accompanying a major motorroad, which tend to get the same ref number as the motorroad, are unattractive for recreational cycling, because they are meant for commuters, using speed pedelecs, mopeds and racing bikes to get there as fast as possible.
I see (and, in hindsight, regret) that the network key is used differently for the road grid than for the recreational route network. At the same time, I don’t see how the two could be united. I really don’t see a practical path to changing the grown patterns. Trying to do that would create a mixed mess, where now you have two separate worlds with small overlap. For cycling, the overlap is bigger than for walking, because cycling comes with (ever growing) official infrastructure, while hiking tends to avoid that.
1 Like
On an obscure wiki talk page, @Kovoschiz suggested a possible way forward by pairing the badly skunked network=* key with somewhat redundant network:name=*, network:area=*, and network:wikidata=* tags during a long transition period away from network=*:
network:wikidata=*is already widely used, and many recreational route networks are already modeled in great detail on Wikidata, so this would be a natural choice.network:name=*would be a freeform, local-language name, similar to the rail-relatednetwork=*values or theflag:name=*key. For any network that lacks a formal name, we might have to coin our own name for it, or we could just leavenetwork:name=*unset and expect everyone to rely onnetwork:wikidata=*.network:area=*would allow for more classification levels than the current three-letter acronyms. Instead oflocal, mappers could choose a more intuitive value likecityordistrictto head off the question that started this thread.
While this approach is elegant, I don’t know how difficult it’ll be to convince existing data consumers to adopt network:area=* as an alternative to what they’re currently doing with network=*. After all, even network=uk_ncn was too fussy for OpenCycleMap back in the day.
In the same talk page discussion, another suggestion was to move cycle_network=* back into network=* while simultaneously correcting an unrelated mistake. When the U.S. community first coined cycle_network=*, we chose identifiers like US:US and US:OH:HAM based on OSM’s namespace syntax, without realizing that ISO 3166 codes should use hyphens instead. Other communities like Belgium have adopted hyphens, as in BE-VLG:cycle_highway. The advantage of hyphens is that data consumers can easily distinguish between the geographic and specific parts of a network identifier without the need for an additional tag.
Since very few data consumers are currently using cycle_network=*, I suspect the U.S. community would be open to mass-migrating to the hyphen syntax if it would enable shield support. That change alone would make network=*cn redundant. However, the next step of moving these tags over to network=* would be more disruptive, so we’d need to prepare any affected data consumers ahead of time.
1 Like
I happen to have recently exchanged messages with a couple of authors of major consumers of outdoor data in Europe, about a related topic (nested relations). Their general position was “we’ll implement the consensus, but we don’t have time to participate in the debates”.
Edit: Oh, and lets not forget network:ref (the pain of dealing with contributors who would put anything in ref just to avoid leaving it empty was mentioned)
Or less intuitive in places where local trails are literally labelled as “Sendero Local”!
More seriously, I can see how the network:area approach would allow for more levels in the hierarchy, but I’m not sure it would be any less ambiguous. Does city mean entirely contained in a city, or crossing no more than one city boundary, or operated by a city administration?
Here in Spain, as it happens, the skunked network tag maps fairly neatly to the standard classification hierarchy as E, GR, PR, SL (talking about hiking here, not cycling). That means that a trail that loops around a single province and takes 30+ days to hike is tagged as nwn, the same as a 30+ day route across multiple provinces, rather than rwn. That feels right, as it matches the way routes are signed and publicised - it doesn’t really matter to me how many provinces a route crosses. It seems that to preserve that hierarchy in a network:area, mappers would need to agree on some kind of arbitrary rules like “use network:area=state for routes that require more than 2 overnight stops regardless of how many provincial boundaries they cross”, making it even less intuitive than network=.
Perhaps at the root of this is my feeling that I’m not sure what the whole concept of a network really means for hiking routes. While the name of the network tag is unfortunate, an arbitrary string of letters feels appropriate where the meaning is really “somebody external to OSM decided this route should be classed as level 2 in the hierarchy”. It avoids linking the tag too closely to unrelated concepts like city or district that carry their own preconceptions.
Not that I’m saying the current system is perfect by any means, and I recognise that for some places it doesn’t work well. But for any proposed changes to be adopted internationally they’ll need to take into account countries where the current approach is simple and gives broadly satisfactory outcomes. (Even those like Spain where the neat match to *wn levels may be more a happy accident than anything).
2 Likes
For now, I think the general picture is that tagging could have been more logical, but it is reasonably good: understandable and manageable for mappers, data users and end users. Moreover, it would be very difficult, if not impossible, to replace it with a different system.
Just like the road class assignments, each country maps its own geographic/administrative/importance classification system(s) onto the four level scope system. I have not seen anyone reporting that that doesn’t work in their country, just that it’s not the same in all countries. I believe that can’t be helped, and it works fine as long as everyone knows that the scopes are assigned per country. For end users, that is quite intuitive, I believe.
Where the need is felt to inform the data user of a particular classification system/naming system/numbering system for routes (“more granular networks”), other tags than network=? are added to the route relations.
Issues such as the redundancy of transport method in the route key and the network values are not actually much of a problem.
I hope the OP has their answer? Or maybe ends up more confused? (That’s what happens to me almost every time i pose a simple question…)
1 Like
network:area=local is also in use. It’s just whatever terms are necessary to make all the regionally important distinctions. In a small country with only a simple system, maybe only national matters; in a larger, more complex country, several values may be needed. If network=*wn works for you now, then you’d map those values one-for-one to network:area=* values.
A network of routes is coordinated in some fashion, whether through predictable numbering or naming, consistent signage, or other uniform standards or operation. If you find this unclear for hiking routes, it may be because the hiking routes in your region aren’t coordinated as networks.
Even in the U.S., where we tend to mark trails like highways, a great many bike routes aren’t really part of any system at all. For these standalone routes, network=*cn is essentially a functional classification rather than a network per se. When this happens, we either come up with a unique cycle_network=* value or leave that key unset in favor of wikidata=* or some other unique identifier. For now, we also set network=*cn to some arbitrary value. Often, this is just a value that differs from other nearby routes so it shows up in a different color on some maps. Tagging for the renderer!
The whole notion that we need to functionally classify recreational routes is based on a specific presentation style popularized by OpenCycleMap and Waymarked Trails, no doubt influenced by traditional paper maps from some regions. I have no particular urge to make life hard for these data consumers, but I am interested in enabling more innovative uses of the same data.
(Ironically, public transportation routes are usually classified similarly, except in OSM. How have we survived the lack of network=rbn for regional bus networks? Would we even have a clear, uniform definition of a regional bus network?)
It doesn’t really work in the U.S. We just make do with some workarounds because we’re only one country, and for a long time the focus was more on gas pedals than bike pedals.
We’ve arrived at the following usage organically:
lcnfor a bike route in a network associated with a park, neighborhood, city, town, village, township, park district, county, or parish, and some privately designated routesrcnfor a bike route in a network associated with a township, park district, county, parish, or state, and some privately designated routesncnfor a bike route in an interstate network (there are multiple)icnfor the International Selkirk Loop
Note the large overlap between lcn and rcn. This is the result of uncertainty about what “local” and “regional” refer to. While OSM has many examples of classification schemes that force countries to fit their reality into a limited number of slots, no scheme is as constraining as the three-letter acronyms.
1 Like
I don’t know. waymarkedtrails is using the network scheme and I find it pretty much a showcase how it is unsuitable for creating a global map. It is almost impossible to make a route selection based on the network tag for lower zoom levels so that the result is readable everywhere. And even on low zooms the display is often meaningless because what you’d really want to see are the different local networks.
I’d very much prefer more fine-grained network: tags, so that as a data user I can make my own decisions about the importance of routes.
Germany is an obvious example where it does not work at all on a country level. Here cycle routes are planned by states and communes and everybody comes up with a slightly different idea of how to set it up. Hiking is even worse. In many areas of Germany even mappers in the same area will come to different conclusions which network tag to use.
1 Like
Or it might reflect the reality that an operator’s “network” may be both local and regional, a mixture of more local and more regional routes; and that various operators and issuing bodies create networks and collections with much overlap.
Privately designed routes is not really a category, I think, can be anything.
I can understand why you want to add cycle_network for more exact information about the specific network to which a particular route belongs. I’m just not sure it solves the overlap issues between local and regional, and overlapping networks of different operators. This happens in Nederland as well, in particular with walking routes, but we can’t solve a real world mess with OSM tags.
No, not here at least. The difference between a countywide route network and a statewide route network is clear as day and usually verifiable on the ground (even if, for now, the statewide route network might be designated by a private entity rather than the state highway department or parks department). What isn’t so clear is how to tag these networks using network=**n.
For example, the tiny Route 3E mentioned earlier is clearly a hyperlocal route, just a link across the street to a neighborhood park, but it belongs to the Ohio State Bike Route System, which is clearly a statewide route network. This is a clear contender for network=rcn, but some other route networks are haphazardly tagged as either network=lcn or network=rcn because the network’s scope falls somewhere between neighborhood-wide and statewide.
To me, a network’s scope is determined by the overall geographic range, as though merging all the routes together, calculating the bounding box, and associating that bbox with a geography.[1] Maybe you have a different perspective based on, essentially, averaging the length of each route and deciding whether that average length is short-, medium-, or long-distance? It would be weird to call Route 3E a “medium-distance” route just because it’s a state route, but that’s an argument for not using network=* for this purpose.
By now, I’m used to hearing “Fix your country!” as an excuse to keep the status quo in OSM. But “Your country is broken beyond all hope” is spicy. 
Not that anyone literally does this; just to illustrate the point. ↩︎
This I don’t really understand. My focus is on recreational routes: what route can I hike or ride in one day, two days, a week. i don’t need to see on the map to which local network it belongs; that’s a detail for later. Once I have picked a route I look at the details and export a gpx, and move on to trip planning and route customization in appropiate applications.
If I see something like this…
… I think that’s not a route, not a recreational network, it’s a route relation used inappropriately to map cycling infrastructure.
If I see this…
I think this allows me to pick a local, regional, national or international route to zoom in to.
This…
Shows me that the German community does not assign ncn very much. Probaby due to cycling being organized on the lower levels. They do have a lot of rcn routes, but these are shown from zoom 9 upwards. Is that part of what you mean?
Or does it have more to do with this:
This looks ok to me for local routes, and there are regional and international routes passing through the area.
Maybe you have an example that shows what the problem is, why it is meaningless? I probably have a blind spot, because I just don’t see what you mean.
No, the result of a discussion long ago, quoting DE:Key:network - OpenStreetMap Wiki
This doesn’t always work for routes that are crossing the borders to the neighbouring countries. While Vallée de la Sarre / Saarradweg is tagged with network=rcn the VeloRoute SaarLorLux is tagged with network=icn, leading through Germany (Saarland), France (Lorraine) and Luxembourg. So three different approaches to network=*cn may apply.
The Vennbahn-Radweg leading from Aachen through Belgium to Troisvierges in Luxembourg started its life in OSM with network=lcn, got changed to ncn and is now network=icn 
Where I live at the French-German border there are several routes that begin in France, crossing the former French regions of Lorraine and Alsace (now Grand Est) and leading then in Germany through the States of Saarland and Rhineland-Palatinate. Vélo vis-à-vis was from the beginning a cross-country project.