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. ↩︎