July 20, 2025 - After 17 months, I have reviewed every road in the NFSR network for the Siuslaw National Forest. Below is a summary of what was involved and the process I used.

Foundational elements

The foundational elements of this project are two public domain road datasets, the NFSR data from the United States Forest Service, and the OR-Trans dataset from the state of Oregon. NFSR is the reference for road numbers, names given to roads by the USFS, road surfaces, and geometry to a certain degree. The OR-Trans data is a reference for primary road names, geometry verification, and the tag formatting of USFS roads. I was able to use additional GIS from counties to verify geometries and primary road names.

Project management

QGIS was utilized as a way to manage the entire project. I used conditional styles on manually added attributes to break the 1,977 roads from the NFSR data into workable chunks, and to keep track of what I had done. Those workable chunks were exported as KMLs to use as a reference when working in iD.

Edits on OSM

I elected to use iD for this project to force myself to manually review everything I was doing, and to remove the possibility of an accusation of a careless import.

The NFSR data contains good geometry for the most part, but there are quite a few errors that are very significant. The NFSR data also contains several discrepancies from reality, such as roads being marked as closed and not open for use, despite the roads not being gated and definitely being actively used. Blanket replacing the geometry and tags in OSM without manual review would worsen the quality of OSM data.

This was also a good opportunity to do some TIGER cleanup and resolve road/water crossing issues. Unfortunately, with the nature of the crossing issues, resolving one can lead to getting flags for multiple others along the road or waterway, which can make it appear that you are creating these issues even though they were already present.

Tag formatting

Tag formatting is somewhat in line with what is currently on the Wiki. I will explain each tag, and why it may vary from the Wiki.

“name”

There are several roads where some or all of the road shares a name with a road name that is signed and/or used for addresses. In these cases, “name” is the road name that is on signage/used for addresses. Otherwise, “name” is “United States Forest Service Road” followed by the appropriate NFSR ID number. This ranges from 2 to 8 characters. For example, NFSR ID 5800000 is a primary route with a distinctive route marker, so it is named “United States Forest Service Road 58” where it does not share a road name that is used for addressing. NFSR ID 5800410 is named “United States Forest Service Road 5800-410”.

“alt_name”

This is for the name of the road as identified in the NFSR data. Of course, there can be several alternative names, so I elected to prefix the NFSR road name with “USFS” for ease of identification. The Wiki suggests that such names be used as the primary name of the road. It is extremely rare to see these names on signs, whereas it is almost universal to see the road number on signs. In line with the “on the ground” principle, I did not use these names for the “name” tag. Also, there are multiple instances of two or more NFSR IDs sharing the same NFSR-assigned name, even in the same forest.

Where a NFSR road shares a name with a road name used for addressing, such as a segment of NFSR ID 5800000, “United States Forest Service Road 58” and “United States Forest Service Road 5800” are also included in the alt_name tags.

“short_name”

This is to make searching easier, and to provide a matching value with the OR-Trans data, which is used in ways where having a matching value is incredibly important. NFSR ID 5800000 is tagged with both “USFS 58 Rd” and “USFS 5800 Rd”, as there are signs that display both “58” and “5800”. NFSR ID 5800410 is tagged with both “USFS 58-410 Rd” and “USFS 5800-410 Rd” for consistency in tagging.

“ref”

This is where I tag the NFSR ID as a 7 digit non-hyphenated number. This provides a match with the IDs in the NFSR data. The refs are prefixed with “NF” or “FR”, in line with the Wiki. I believe a single prefix (“NFSR” or “USFS”, maybe) should be used regardless of the route marker, but that’s a discussion for another day. NFSR ID 5800000 is tagged “NF 5800000”, and NFSR ID 5800410 is tagged “FR 5800410”.

“network”

The Wiki suggests that this be reserved for route relations. I used the appropriate “US:NFSR:Siuslaw:NF” or “US:NFSR:Siuslaw:FR” values on the individual ways, as it is a unique value to indicate that the road is part of the NFSR network.

“operator”

The Wiki suggests adding the name of the national forest, or the USFS itself, as the operator value. I originally did not use this tag at all. Considering the definition of the tag, there can be multiple operators along a single NFSR route, and these can be difficult to determine. After receiving input from another editor that does a lot of work with NFSR data, I tagged the operator as “United States Forest Service”. In due time, some segments may see their operator tag change as the actual operator is determined.

Other cleanup

The project area consists of a significant amount of poor data from old TIGER imports. Several roads and segments were incorrectly identified as being NFSR roads. I used a combination of search criteria to find these incorrectly tagged elements. For example, searching for tags containing “Siuslaw”, “National”, “Natl”, “Forest”, “Develop”, and/or “NFD”, followed by manually sorting out what was applicable, was the best way I could think of to find and remove these incorrect tags.

Final review

After all of the edits, I used several different processes in QGIS to compare an export of OSM data against the NFSR data. For example, a distance matrix was useful for finding instances where I mistyped a number. Once I had identified every error I made, I corrected them, and went through all of the processes again just to ensure everything was good.

On July 18, I thought everything was good. Today, July 20, I wanted to assess any USFS data updates that may have happened since the last time I checked for them. Just for fun, I decided to download both NFSR datasets and the MVUM dataset. I was surprised to find that the MVUM dataset does not match the NFSR datasets. One NFSR dataset has two separate roads merged into one multi-part line, which overwrote the correct information for one of the roads. Fortunately, the correct data is in the MVUM file. Meanwhile, the MVUM has roads not identified in the NFSR data at all, and also has at least one road with an incorrect road number. These discrepancies have been sorted out, and the relevant updates have been made on OSM.