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

10 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.

4 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.

1 Like
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.

2 Likes
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.

2 Likes
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.

2 Likes
15

Creating relations for each minor road doesn’t feel excessive as much as duplicative. I would be very happy with a data model where a road’s common tags like name and ref go only on a relation, and the only tags necessary on the member ways are those that differ by segment like bridge, surface, and smoothness. Of course this is not the standard today, and instead common tags need to be included on both the relation and ways since most map renderings still don’t pull data from route relations. Contrast this with multi-polygons where tags are only required on the relation, and the member ways can be left untagged. If the goal is to promote a similar use of relations for all sorts of linear features where member ways could eventually be left untagged, then I’m all for it! However, this would take a lot of time and energy to gain support for this style of mapping. The more likely outcome I’d imagine would be perpetual duplicate information for all roads because some data consumers read if from ways and others read it from relations.

3 Likes
17

Creating relations for each minor road doesn’t feel excessive as much as duplicative.
…
The more likely outcome I’d imagine would be perpetual duplicate information for all roads because some data consumers read if from ways and others read it from relations.

Some counties assign numbers to all their short dead-end streets. It would be just as much effort to do the same for all of these. I would love to figure out a tagging scheme that would reduce the duplicate effort involved in mapping these, but we’d need to reconcile refs with and without prefixes in ways and relations, and that would need to be a longer discussion.

18

Are we ready to adopt this? If there aren’t any significant objections in the next 72 hours, I’ll go ahead and update the wiki.

8 Likes
19

I gave a thumbs-up to @clay_c to show my support / lack of objections to the proposal.

20

If you don’t know if it’s primary, secondary, minor, is it OK to simply use US :USFS, ot best to not create the route?

21

I think we should discourage the use of ref prefixes on National Forest road ways. None of the signs I’ve seen include these prefixes and I don’t see the point when we have the network tag to indicate the type of road. I propose that we keep it simple by making the tagging exactly the same whether on a relation or a way:

  • Un-prefixed ref value
  • network=US:USFS:* (primary | secondary | minor)

I consider it perfectly valid to map these minor forest roads either with or without route relations depending on mapper preference and the particular situation being mapped. Having consistent tagging regardless of data type will be simpler for both mappers and data consumers.

1 Like