This project is focused on improving OpenStreetMap (OSM) metadata in remote areas. This includes Motor Vehicle Use Map (MVUM) from the USDA, and hiking trails for all the national forests, national parks, and wilderness areas in the United States. These remote jeep roads and hiking trails are often used for wildland fire fighting and back-country rescues. Some of these remote highways have been traced from satellite imagery, and others imported from older version of the MVUM dataset. When the datasets don't agree on the proper name and reference number for a remote highway, the only way to really know is to ground-truth it. Reality is what you see with your eyes, and while way out on interesting roads, good free campsites.
Since these are remote areas, they haven't gotten much attention in OpenStreetMap, much of the time the metadata is lacking beyond highway=track. My process is a mix of data conflation and ground truthing. Most of the external datasets have typos, bugs, etc... Accuracy is important when trying to navigate in these areas, as often they are a nest of poor jeep tracks. Many of these change conditions, so it'll be smoothness=bad, then sudden gets narrower and more eroded and becomes smoothness=very_bad. These changes in the highway are important for emergency response when deciding on which apparatus to respond in. For a wildland fire, it's a big advantage if you can stage bigger fire trucks where the condition changes, and use that to supply water to smaller brush trucks.
I try to spend a lot of time in the field doing data collection and ground-truthing external datasets and test my free software for OpenStreetMap. It's much easier to do this when not deployed as an emergency responder. Since these are remote areas, there is also great free camping, awesome views, and really fun (smoothness=very_bad) jeep tracks. I'm usually focused on three things when mapping, amenities in remote small towns as I drive through, good campsites, and updating the highway or trail metadata.
Some of this software is already being used in a production environment as part of the back-end for the Field Mapping Tasking Manager (FMTM) project. That project supplies a Tasking Manager style project organization for group field mapping. But these projects also work standalone when working fully offline. Whether mapping solo or in a group, the data processing is the same.
Software by itself is of course boring, but it's just tools for the work we want to do. Each of the projects have reasonably good documentation, and it's all been used in the field. I've written a bunch of tech articles on field mapping, how to work offline, mapping highways, etc... These explain how I use these software tools for field mapping trips.
Boundaries are critical if you want to split huge files into smaller ones to make editing the data more manageable. These boundaries have been extracted from official administrative sources. These are for all the public lands in the United States. These are in both GeoJson format for ogr2ogr and osmium . or a poly file file for osmconvert. Some of these have been manually been cleaned up where there were issues with the geometries that prevented them from working.
While the source datasets are easily available, it can take a bit of work to filter them down to a smaller, more manageable size to edit. To make this easier for anyone else wanting to contribute to this project I've chopped them into national forest or park sized data files. There's a lot of options to each program that have to all work together for good conflation. If you are curious, you can dig the various options out of this script, which is the one I use to do all the splitting work.
You can get the source data files online from their official sources, I'm only adding the converted data files for review of the conversion process.
Each national forest or park directory has it's own sub directory. Each directory contains the MultiPolygon task grid for the entire area. There are also data extracts for each of the area of interest that are used when splitting further. In addition, each of those is split further into 10km sq tasks, with data extracts for each of the small tasks. These are the easiest ones to work with. I'm supplying these to help others that may want to work with this data.
These are large data extracts, one for each national forest or park. These have not yet been split into task sized pieces, but these are here for others interested in working with this data and/or the software just to save you the time and hassle. Since many of these public lands cross state boundaries, I have them categorized alphabetically.
It's become obvious there are major bugs in the official highway reference numbers in the MVUM and RoadCore datasets. These old datasets are now considered legacy, and don't get updated. Newer datasets are more oriented towards the web, or mobile devices, but unfortunately those can't be used for improving OSM except by using an entirely manual process. I've attempted to reverse engineer the problem in these old datasets, and these files have the corrected reference numbers, which I've validated using newer official datasets.
Anyone motivated is welcome to contribute to both the software, or just using these tools and the data for your own map improvements. This is a huge amount of data, as the original source files are nationwide. I'm just focused on my part of the western US. Help improving OpenStreetMap accuracy in remote areas of your own state is a good idea, and can save lives in an emergency.