Network=* tagging proposal for USFS Roads

Communities United States
, ,
#1

As most of us here may be aware, the US has probably the most complicated and fragmented route signage system of any country in the world. We’ve made good progress as a community on devising tagging schemes for most nationwide, statewide and local route=road networks, though there are still a few odds and ends that haven’t been worked out. Notably, the US Forest Service (USFS) is one of several federal land administrators that signpost their own routes. The National Forest Road System has a distinction between Forest Highways (or Primary Routes), signed with trapezoid shields, and Forest Routes (or Secondary Routes), whose signage is a horizontal or vertical rectangle depending on the maintenance classification of the road (which tells you whether the road is passable for a typical passenger car).

Forest_Route_90.svg

US_Forest_Service_Horizontal_Marker
US_Forest_Service_Horizontal_Marker912×672 29.5 KB
US_Forest_Service_Vertical_Marker

The current situation

The network=* tagging scheme for route=road relations belonging to the National Forest Road System, according to the United States road tagging wiki page, is US:NFSR:<forest name>:NF for Forest Highways and US:NFSR:<forest name>:FR for Forest Routes:

Required. An example is US:NFSR:Chequamegon-Nicolet:NF for a National Forest Highway, or US:NFSR:San Bernardino:FR for a National Forest Road.

Distinguishing the network in this way will keep individual National Forest Road systems distinct, and also allow for future shield generation corresponding at least to ‘Distinctive Route Markers’ and “other NFSR routes”.

While this seems to be the predominant tagging scheme, it disregards the distinction between Forest Routes with vertical and horizontal signage. Moreover, in the case of OpenStreetMap-Americana, the inclusion of each National Forest’s name has actually hindered shield rendering support, as the name of each forest must be enumerated in the underlying code. Signage is identical from forest to forest, which makes me doubt whether this is necessary information to include in network=*. Perhaps operator=* is a better home for it, if it isn’t easily deductible from a spatial query.

Proposed tagging guidelines

In order to distinguish between routes with different shield appearances and better match shields to network=* values, the following is proposed for route=road relations:

  • deprecate network=US:NFSR:*
  • define three values of network=* for the National Forest Road System:
    • US:USFS:primary: Forest Highways (aka National Forest Primary Routes)
    • US:USFS:secondary: Forest Routes (aka National Forest Secondary Routes) with horizontal signage, indicating a maintenance class of 3 or above
    • US:USFS:secondary:low_maintenance US:USFS:minor: Forest Routes with vertical signage, indicating a maintenance class of 1 or 2
  • add operator=<forest name> if necessary to disambiguate roads with the same ref=* and network=*
  • do not use a prefix in ref=* (same as before)

The following is proposed for highway=* ways:

  • use FH as a prefix in ref=* for Forest Highways
  • use FR as a prefix in ref=* for Forest Routes (regardless of maintenance class)

The prefix US:USFS: was chosen to be consistent with other federal agencies that signpost routes, namely the Bureau of Indian Affairs (network=US:BIA) and the National Park Service (network=US:NPS:*). As for ref=* tags on ways, there isn’t an obvious way to distinguish high-maintenance and low-maintenance Forest Routes, but it’s probably not necessary anyway. Data consumers that process this tag on ways are agnostic about which one of a variety of possible networks the route may belong to.

I considered going through the formal proposal process on the Wiki like last time, but this issue has a much smaller scope in comparison. I hope we can come to a consensus about these routes one way or another—I know a lot of us are dying to document these routes and have them show up in OSM.

Prior discussion

9 Likes
#2

One thing about actually implementing stuff that uses data is that you find out how usable that data is.

You analysis and your suggestions appear to be top notch to me.

And I think this is a better forum for tagging and wiki change discussions that the old mail lists so thank you for bringing this topic here.

3 Likes
#3

I do like this proposal. This would be much simpler for tagging. The NF and FR classifications are more confusing than this proposal. I much prefer the USFS:primary and secondary classifications, as well as distinguishing vertical from horizontal signs.

3 Likes
#4

Well written proposal.

The primary and secondary taggings in the relation seems redundant when you use the highway types, track grade, smoothness, surface to describe the road though.

Passenger car roads are either an unclassified highway or a track thats grade 1 or 2. Low maintenance are track with lower grades and smoothness tagging. Maybe tertiary for the few forest highways.

Whats the value of this extra tagging in the relation then?

1 Like
#5

I’ve been following OSM Americana and listening to the various challenges and victories regarding their shield rendering. Your proposal, in my opinion, addresses the consensus of that group. Since they’ve explored so many use cases and exceptions to ‘standard’ highway tagging, this seems like the gold standard if OSM were to have one.

That said, the ‘low_maintenance’ add-on seems completely irregular to any other tags I’m familiar with in network=. I don’t necessarily feel like I have a better solution. But I do wonder if we consider applying a ‘tertiary’ leg instead, even though that doesn’t match the language and coding of USFS. There’s lots of precedence where OSM ignores local/regional terminology to stay true to the database. Vertical signs definitely imply a level of maintenance below secondary, so it seems appropriate and avoids the additional ‘:’

1 Like
#6

If your goal is to render a map where you display route shields that look the same as a person would see on the actual road then track grade and smoothness tags don’t provide the information you need.

#7

It sounds like we all agree that the lower-quality roads that are signed differently ought to be tagged differently, and the only thing we’re grappling with is what nomenclature to use to differentiate the two categories. If so, we’re not far from a solution.

1 Like
#8

After having worked on a fair amount of USFS roads and trails, I think this proposal is very good and that the new tagging would be helpful. Based on what I’ve seen, the road maintenance level does not necessarily correspond to road conditions, often because low maintenance roads happen to be in good shape for one reason or another. However, it does correspond to the importance of the road in the network, so I think the distinctions are useful.

The network=US:USFS:secondary:low_maintenance tag is a little verbose. It would be fine if we chose it, but it might be nice to have something a little more compact that would help mappers with auto-completion.

1 Like
#9

Deprecating network=US:NFSR:* and standardizing on network=US:USFS:primary seems good for National Forest Highways (trapezoid shields). These primary routes seem very similar to state or county routes and it makes sense to me that they would be mapped as route relations.

It’s not clear to me that route relations make sense for the lower maintenance roads that use smaller horizontal or vertical signage. These are all generally lower classifications like unclassified, service or track and seem much more akin to local roads than long distance routes. If every National Forest road is to have a relation, that would suggest that every named road and street elsewhere should too. This may eventually make sense given the one feature, one OSM element principle, but currently that is not standard practice. For now, I would suggest we just tag these lower maintenance roads right on the ways just as we do with lower classed municipal roads and streets, but eliminate the prefix from ref. network can also be tagged right on the ways to indicate vertical or horizontal signage.

I agree that network=US:USFS:secondary:low_maintenance feels a bit awkward, but I also don’t have a better idea for a network value. Alternatively, a new tag indicating signage style could be coined. Something like ref:sign_style or ref:shape including values like horizontal and vertical could work and would be similar to the existing ref:colour tag.

2 Likes
#10

Great proposal- forest name in the network is definitely immaterial as these roads are part of a national network for the National Forest transportation system.

“Low-maintenance” I am not especially keen on. More like low-volume roads with a design vehicle being a high-clearance 4-wheel drive vehicle. Critical vehicle is usually an 80,000 lb log truck- that sets the turn radius at about 45’-50’.

Maintenance levels- USFS roads have both an objective and operational maintenance level. A transportation/travel analysis may elevate a lower standard road previously designated at maintenance level 2 for high clearance vehicles but now bump it up to ML-3 for passenger vehicles if for instance they are seeing higher use in Motor Vehicle Use surveys/national forest visitor monitoring surveys. Or budgets or may limit the needed maintenance/road work necessary to get up to that level 3. So you may have a rough ML2 road (operational) that if you base the OSM classification by using the ML3 objective designation and then people get in trouble high-centering or otherwise getting stuck in their passenger cars.

I would advocate make heavy use of the operational maintenance level rather than objective ML and also the 4wd-only tag.

1 Like
#11

So it seems like the bulk of the proposal is agreeable, though there’s some negative feedback on network=US:USFS:secondary:low_maintenance. I’ve changed this in the proposal to network=US:USFS:minor, which I think is a more succinct and adequate descriptor of secondary Forest Routes with a maintenance level of 1 or 2.

1 Like
#12

For now, I would suggest we just tag these lower maintenance roads right on the ways just as we do with lower classed municipal roads and streets, but eliminate the prefix from ref. network can also be tagged right on the ways to indicate vertical or horizontal signage.

This is probably okay as a stopgap, though there isn’t any software yet that supports tagging network=* directly on ways.

Something like ref:sign_style or ref:shape including values like horizontal and vertical could work and would be similar to the existing ref:colour tag.

ref:colour=* also doesn’t have any software supporting it and hasn’t seen much adoption outside of Spain. Not to discount the possibility of tagging the individual parameters of shield appearance, but in this case I think we can capture the distinction between horizontal and vertical signage with network=* alone.

#13

+1 eliminate name of Forest name, put it in operator.
+1 Use USFS instead of NFSR
I kind of don’t like `US:USFS:primary & secondary because it might be confused with highway=primary & secondary, but that’s what USFS calls it, so I guess it works.

As someone who has tagged quite a few roads & trails (ways), but rarely goes the next step of tying things together with route relations, I’d have to agree with Zeke, that perhaps it doesn’t make sense for the lower levels. I think it will be a while before there is significant adoption.

I see the primary/secondary/minor distinction on signs, and hard copy NF maps, but I don’t see that in any pdf’s or shp’s. Where are you guys finding this?

#14

While creating relations for each of these minor roads might seem excessive, remember that even on forestry tracks ways may be split for bridges, changes in smoothness=*, surface=*, overlapping hiking routes, etc. Grouping these ways into a single relation that represents the numbered Forest Route might be micro-mapping, but it isn’t completely pointless or wrong.