Starting a new topic for the necessary international discussion sparked in the US subforum: Appalachian Trail disappeared from Waymarked Trails.
A few relevant posts that will remain in the original topic:
Related discussion but for cycling routes here: Bike route networks classification (ICN, NCN, RCN and LCN)
May I point out that using network:type as it is being used here to indicate the scope, conflicts with the, very well established use, to indicate, well, the network type network:type | Keys | OpenStreetMap Taginfo
And I would note that I have always found it exceedingly daft to encode the scope of the route in network (not to mention that the values are daft^2), but what is being proposed here as a solution is DOA.
As a programmer, I tend to avoid calling things “types” because that word is so overloaded. network:area=* is being used in a couple places, seemingly for the purpose for distinguishing local routes from national routes and so on. Maybe that would be a solution here.
Having just skimmed over the US route relations thread, I notice that this tagging is in conflict with what is currently done in the US with cycle networks. There the US community seems to have settled on cycle_network for the network description and leaving network=[inrl]cn untouched.
If we overhaul the network tag (and to repeat myself, I’m very much in favour of that) can we go for one solution that works for all route relations the same? Apart from using the same tag for all route types, this would also mean that we get rid of scope values that encode the route type.
In that sense, I’d prefer Quincy’s approach over what happens with the cycle networks. It’s in line what is currently happening with road networks. Only, [inlr]wn needs to be swapped for something along the lines of local/regional/national/global.
Personally I also don’t see a conflict with the values node_network and base_network used in network:type. These kind of networks are just a special form of local to me. I hear that in the Netherlands (or was it Belgium?), there are plans to extend the (local) node network with “national nodes” to indicate long-distance connections. But these would need to be modeled as superroutes anyway, which would make them clearly distinguishable.
Following up on the thread about US bicycle routes: there is a simple solution for facilitating complex routes (e.g. those with branches or with multiple loops) and that would also allow to stop making node networks a special case: add all legitimate branching points to the parent relation just like it is done in node networks.
But maybe regional too?
But in the end it is just mixing two things with very different semantics in to the same tag and -if- we are doing something new, can’t we just not immediately create foreseeable new problems. It isn’t as if introducing 2-3 new tags comes with a large cost.
Leave network:type as is, introduce network:extent/scope/area (as has been noted network:area has some existing use) for the geographical scope, introduce a new tag for whatever @quincylvania wanted to express, and let network die a slow death. So that is really just one new tag.
Unlikely. A route in a node network goes from one node to a neighbouring one. Two adjacent nodes are usually quite close, no more than a couple of kilometers away, more frequently less. That makes a route in a node network a local connection. Just because you happen to create enough nodes to cover an entire country still doesn’t make the vertices in the network national.
Or to put it in a different perspective: from a rendering point of view a network:scope is not very interesting. What counts is the route:scope. waymarkedtrails has always interpreted [lrni][chw]n in that way. It’s also why 2km routes that are tagged iwn just because they happen to cross a national boundary are quite problematic.
The vertices in node and base networks are not exactly the same as local routes, so having a different type for them is fine. (I’d also reserve a special category for pilgrim’s routes because they form a very peculiar form of network that again is different from everything else but that is another discussion.)
Don’t underestimate the creativity of route designers 
We have one case in the Alps of a regional node network “on top” of local node networks, with selected local nodes that have an additional signage for the regional network.
Yes, it is inconsistent. If there weren’t so much attachment to the three-letter acronyms, I don’t have any doubt that we would be able to reform that tagging as well, but we were only trying to bite off a few problems at a time. American usage of cycle_network=* goes well beyond the USBRS and essentially predates that network, which was the focus of the thread. The discussions about superroute, direction=*, and so forth don’t necessarily preclude a replacement for cycle_network=*.
While I realize that the loca/regional/national etc designators are based on things like who manages the routes – but from a cartography perspective, isn’t route length the real descriminator that matters here? The Appalachian Trail is 3500km long as a “national” network, but a 1km path that crosses the US/Canada border might get classed as an international one. I’d want to see long routes on low-zoom maps and short routes on high-zoom maps. Apologies if I am completely dumbing this down.
Yes, that is a cartographic need, but it shouldn’t be confused with the notion of a network. In fact, what some maps may need is more of a functional classification (borrowed from highway classification) that departs from both networks and distance classifications.
As it is, some mappers would scoff at tagging this tiny spur as a regional route, but that’s how it’s tagged by virtue of being part of a state bike route network. The USBRS and Appalachian Trail both have shorter spur routes; the infrastructure is local but the network is not. Many of the short transnational routes don’t really belong to a network per se, certainly not a global system; they’re one of a kind.
Sometimes I wonder if a data consumer that needs to prioritize the distance should calculate the distance and come to its own conclusions for assigning zoom levels, but that opens up a whole new discussion.
Yes route length could be a good approximation. However, given that OSM is a constant work in progress, you cannot make the assumption that route length equals mapped length.
Also, this thing has an impressive length of 345km despite clearly being a local … erm… route.
I thought about actually counting the administrative areas a route touches.
It seems to me that the network values iwn, nwn, rwn, and lwn are a classification system indicating scope or importance from highest to lowest. They serve a similar purpose for hiking/walking routes as the highway values trunk[1], primary, secondary, tertiary, unclassified, etc do for roads. A tag starting with route* would make sense to me (route:scope, route:class, route:importance).
Semantic values like these seem reasonable, though perhaps challenging if there ends up being a need for more than four classes. I could see 1, 2, 3, 4, 5 working just as well, as with admin_level.
motorway intentionally omitted as it is a bit of a special case that isn’t just about importance ↩︎
Actually I don’t see any compelling reason to keep node networks as a special case (except during a grace period, of course). Node networks are structurally equivalent to routes with many many many branches. Importing the concept of network nodes to any type=route would provide the expressive power that we need to deal with:
I would agree that network:type=xxx also isn’t a great tag, the only reason I moved the nwn there is that I wanted to preserve that value for the time being, and there are a few thousand uses of that pattern already.
Some thoughts on improvements:
national and international may be useful values for administration but not geographic extent. A “nation” can be the size of a city or a continent and this will always cause confusion with mappers.This might account for the differences that are currently obtained in Waymarkedtrails through dedicated code for, e.g., italian routes
Moreover, a short segment of a route may connect two major routes. Encoding functional classification on a bike route relation is like encoding functional classification on a highway route relation. There have been a few proposals to instead put this information on individual highway=* ways, including:
On the other hand, Proposal:Hierarchies route=bicycle - OpenStreetMap Wiki proposes to create a nested relation structure to represent changes in function along the route.
Moreover, a short segment of a route may connect two major routes. Encoding functional classification on a bike route relation is like encoding functional classification on a highway route relation.
This is true, but I think the difference is that road classification is much more about the level of infrastructure. Even the most forgotten or motorways is physically a motorway. Whereas much of the Appalachian Trail is just an indistinguishable path in the woods, a sidewalk, or a road shoulder. Typically in OSM these ways aren’t even distinguishable as trails without the presence of the parent route relation.
I’ve actually stared experimenting with trail=yes/no on ways to indicate if they are part of the trail network without looking at relations. This may be a little too generic, perhaps a better pattern would be hiking=yes, cycling=yes, etc. Mirroring mtb=yes, these wouldn’t be access tags, just categorical.
In this context I do kind of like the idea of tagging more of these classification attributes on ways instead of relations. A given way might be part of several routes of different levels of importance, but a renderer would just care about the highest. I could see some sort of tagging on ways like hiking:class=primary or hiking:rank=2 or hiking:longdistance=yes.
I’ve actually stared experimenting with
trail=yes/noon ways to indicate if they are part of the trail network without looking at relations. This may be a little too generic, perhaps a better pattern would behiking=yes,cycling=yes, etc. Mirroringmtb=yes, these wouldn’t be access tags, just categorical.
one could add lwn=yes or nwn=yes on the ways, indicating they are part of a local walking network, or national walking network.
Agree on that. The current classification is not universal and dependent on the area. Like a national route in the US will be equally to an international route in Europe.
As well local and regional not really have that issue. To use an abstract rating would be better. Like stays within 50km circle, 100km circle 500km circle or above would be more universal globally.
Those numbers might differ for cycling, hiking,…
As well we should think about whether type=route/superroute is a good approach. If a looong route relation needs to be split in multiple relations due to complexity, the main relation actually should be type=route and all the supporting relations should be marked in a different way.