Here’s an overpass query that folks can use to search for potentially missing route relations.
[out:json][timeout:2500];
way[highway][name~"State Highway"]({{bbox}})->.highways;
.highways < ->.routed_highways;
rel(bw.highways) -> .parent_routes;
way(r.parent_routes) -> .routed_highways;
(
.highways;
- .routed_highways;
);
(._;>;);
out skel qt;
I spotted a tagging error there, too. The way is tagged name=State Highway AB, but it shouldn’t have that tag, it should have noname=yes.
Are you sure? It looks like it’s a Missouri supplemental route to me. Or are you saying that it should be added to a route relation but not have a constructed name in the way’s name tag?
Effectively, the latter, since ref=* is not name=*.
I’m making popcorn, everybody. This is a fun space to watch right now.
Ah Missouri, where MOAB is only a stone’s throw from OZ.
Another way to put it is that the British system assigns names to roads that are purely alphanumeric codes; words like “road” or “motorway” that come after are just descriptors, not part of the name. I’m glad this came up:
For the U.S. counties that don’t post shields, the only reason anyone is even considering “County Road 123” in the same conversation as “State Route 123” is that the number comes after the name. Otherwise, it’s functionally just a street name that contains a number, no different than “5th Street” or “Avenue B”. It might happen to be known by that number in an inventory log too, but we have no more reason to map that number as ref than we would for mapping PennDOT quadrant route numbers as ref. It would be inaccurate to tag the number in ref but not in name, especially if the name is of the format “North County Road 123 East”, as it often is in rural counties.
What distinguishes many other local systems as numbered route systems is that, in actual practice, people isolate the number and elevate it above the status of an arbitrary word in a street name, whether on a shield or just a plain old street name sign. So as a rule of thumb, if we’d feel comfortable tagging a route number in ref but not in name, I think it’s a pretty sure bet that it should have a route relation. But if it’s just an inventory number that happens to show up in a road name, for lack of something more memorable, then name will do and ref is questionable.
Forest roads are known by their numbers first and foremost, as the USGS topo maps above demonstrate. There’s also a horizontal/vertical distinction that’s inherent to the road’s identity, not merely incidental to the sign design or a cartographer’s whim. Way refs are incapable of storing anything more sophisticated than human-readable shorthand, so if we expect this distinction to persist through to data consumers, there probably should be route relations.
A similar pragmatic approach was taken in the case of Ohio’s northwestern counties. Like many northeastern Indiana counties, the county and township roads are numbered according to a grid, and functionally they’re just numbers in a street name. But unlike in northeastern Indiana, these northwestern Ohio counties post a variety of shield designs (which could be thought of as oversized, square, multiline street name signs).
Precisely because we think data consumers may care about shields, we’ve mapped route relations for these otherwise mundane numbered roads. There may be parallels to the British system if you think hard enough about it, but consistency with other Ohio counties was a higher priority than with the UK.
Ah, Ohio, where “nothing is true.” Or sorta, something like that. I’m allowed (to say things like this), I was born in Michigan.
USFS routes are numbered with the unique identifier, and sometimes a name.
This identifier doesn’t change with change in administrativr status like continuing on from one Forest to another. Forests are transitory and can change with executive order (merging, splitting, deleting) as an administrative designation. The land is public domain land in federal ownership, administered by the USDA Forest Service and can be taken away from that agency and added to another, or vice-versa.
The identifier doesn’t change with a change in public access status- closure with a gate or berm, the travel route continues on, same with objective maintenance status level- a road out to the boondocks may start ML-3 passenger vehicles, downgrade to ML-2 high clearance vehicles, then ML-1 generally closed to motor vehicles, retained for periodic use in the long-term (like opening the road up every 5-10 years for wildfire suppression access, timber sales, etc. - administrative purposes only.
So yeah, ref value on the route relation, though the route relation really might not be necessary unless its a very long and complex USFS route. Most USFS roads are short, simple spur roads for timber harvesting - getting a re-do every 10-15 years or so; pre-haul, during haul, post-haul maintenance. And where it makes sense and benefits the public those spur roads are kept open for forest visitors- recreational users- like when they provide through-routes or to special areas.
National Forests are not parks. They may have intensive-recreation use designated areas due to high recreation values- wilderness, trails, rivers, lakes, scenic views, ski areas, etc. Otherwise NFS lands are designated for timber production for a varied intensity- assigned silvicultural systems and rotation lengths- to support rural economies and ensure adequate supply of forest products. Its spelt out in every National Forest’s land and resource management plan.
I think that’s understating the technology gap, at least with respect to mapnik/carto stacks like openstreetmap-carto. If you follow the issue for adding shields, you’ll see two blocker issues mentioned, one of which is a significant technology stack change. So at least with respect to the standard tile layer, which uses a tech stack that’s in wide use in our open source cartography community, the problem isn’t desire but rather building the technology to do it. It’s worth pointing out that @pnorman has been doing serious heavy lifting to get there. It would be more accurate to say that it’s backwards compatibility for data consumers that aren’t yet capable enough to implement route-based shield rendering, including software that’s still very much current technology.
Should we plan to proceed with this tagging scheme? It seems like most commenters are/were on board. But I started editing some USFS routes in George Washington National Forest using the tagging scheme in this proposal before realizing the wiki docs still haven’t been updated, and I see it doesn’t have much usage in Taginfo yet, so not sure where it stands.
I think we’ve had enough discussion. @ezekielf, it looks like you had the most criticism of this scheme—do you still have any objections to adopting it?
My only objection is that the proposed scheme recommends route relations for all USFS roads. I think this should be recommended only for the Forest Highways and for lower classed roads route relations should be described as optional. I would rewrite the proposed scheme to be like this:
highway=* ways and route=road relationsroute=road relations:
network=US:USFS:primaryref=*
highway=* ways:
FH as a prefix in ref=*
highway=* waysnetwork=US:USFS:secondaryref=*
route=road relations can optionally be added with the same tagginghighway=* waysnetwork=US:USFS:minorref=*
route=road relations can optionally be added with the same taggingnetwork=US:NFSR:*
operator=<forest name> if necessary to disambiguate roads with the same ref=* and network=*
This is not a hill I’m going to die on though. If everyone else is in favor of route relations for every mile of USFS road, I won’t stop you all.
I’m in agreement with Zeke, except I think we should keep the prefix on ways, ref=FR/FH . There’s a lot of ref=FS xx out there now too.
I don’t think it makes sense to suggest route relations on minor roads, it will never happen.
Network should be US:USFS:forestname but other than that it seems fine. National Forests operate as their own independent networks; it’s common but not guaranteed numbers stay the same crossing between two adjacent networks in a way that’s not dissimilar to state highway grids connecting.
Is there any more action on this topic?
I don’t think we’ve reached consensus on this, and at this point I don’t know the best path forward.
This might be useless chatter on my part, but this both has been and is a good discussion. Please, keep up the good work, everybody. Tagging network=* for USFS roads certainly IS something we can solve, we simply haven’t done so yet. It seems to me like we’re most of the way there, though. What are the specific, relatively minor disagreements?
I’m opposed to the idea of tagging all networks network=US:USFS and operator=the name of the forest… each forest is it’s own network and the USDA Forest Service is the operator of all of them.
Are you mostly just opposed to setting operator=the name of the forest? Or do you feel strongly that network should be different for each forest? If network were different for each forest, what might a data consumer do with that? So far, network has been used for displaying shields and these appear to be the same across all forests.
I don’t believe each network is in its own network. I believe these forest roads are in one “national network,” where USDA Forest Service is the operator=* of each of them / all of them. I lean towards operator=USDA Forest Service tagged on each road, and perhaps on each route. (Remembering that the owner of these roads are the People of the USA).
This discussion is similar to early days of the USBRS, where state DOTs apply to AASHTO for their proposed (limited to their jurisdiction of statewide) bicycle route to be approved into the national grid / network, yet there was a lot of initial misunderstandings about how this might be best tagged in OSM. Some suggestions (circa 2012) were that AASHTO itself be named the “operator.” This was quickly dismissed, as AASHTO acts simply as the agency which approves a route(s) into the numbered national grid according to certain protocols, like even numbers east-west and odd numbers north-south, though there is more to it than that. What evolved is our current methods of tagging USBRs network=ncn, while other routes in a limited fashion can also be tagged this (we call these quasi-national, not national) — there are barely a half-dozen of these. Confusion is avoided by saying “numbered shields = USBRS/national” versus “shields with names or acronyms = quasi-national.” There is also sane (well-documented) cycle_network=* tagging to further denote a specific network at any given level (international, national, regional, local) in a network=* tag.
What we have with the USFS Roads (network) is a national network of roads, widely geographically disparate / disconnected, and so to many do not fit a usual concept of a “network,” yet that is exactly what they are. A (newly-coined?) tag, similar to / analogous with cycle_network=* could be used to describe the specific hierarchy and/or locale, such as forest_road_network=US:USFS:El_Dorado to denote each forest’s “sub-network(s).”
Realizing that there are different use cases (all of which are valid) and that we can design the tags to fulfill most or all of these downstream uses, learning from the lessons of decades-old methods of how we already do similar things just makes sense. If we need to coin a new tag or bend an existing namespace to include something specific, we can do that: we’re all working towards the same goal of accurately-denoted roads that fit into a network which are tagged so everybody can both understand and use (parse with software) these (to-be well-structured data). Such design work isn’t always “socially pleasant” but we can resolve to keep it so (as we do here) going forward…and in the not-too-distant future, we’ll have a nice system, excellent data and pretty renderings that everybody understands. (Because we discussed, designed and documented it).