OSM had come a long way in the last 5-10 years, but the biggest deficiency for my use is National forest and BLM roads. It looks like there is some data out there which would help to speed this up and improve the accuracy.
There will be lots of areas like that where someone has already improved the map and the import would have to leave that better existing data (and also not duplicate it), not just wipe it out for expediency.
Unfortunately much of the mess with forest trails started with imports, and the generally used method for making things better is manual editing in association with various layers (particularly the USFS layer, but sometimes old Topo maps can be helpful resolving which logging roads are more significant). On-the-ground knowledge is superior to both: sometimes it’s impossible to reconcile aerial images, the USFS map & topo map: either because several of the sources are out-of-date or because recent logging has taken place. (My last contributions have been in Central Oregon in an area where my family used to ranch, but which now appears much less populated than it was in the first half of C20).
Richard Fairhurst, owner of cycle.travel, has been doing extensive work on improving this type of highway so that his website produces sensible cycle routes. He may have specific advice too.
I’ll continue to clean up my area, but I think there are way too many miles of roads and trails in the western US, and not enough OSM contributors to count on manual editing. Also, an aerial image wouldn’t help to pick out roads that have been closed. In my area, there are legal roads that haven’t been imported at all.
BTW, as a reply to the way back original post about importing the MVUM data from USFS.
That would be a bad idea. I’ve looked that that data and some of that is based on some old inaccurate scans of topo maps. Not all of the roads in that data has been verified and can be significantly different from reality. There are enough bad roads, tracks and trails in that data that a bulk import of all that data would make things much worse.
Not just scans of USGS Topo maps, but a lot of USFS roads were digitized from early 1990’s USGs topo orthoquads so you had the added distortion of sometimes questionable orthorectification. For instance the 1993 topo ortho quads available from the National Map are direct matches to USFS road GIS data in Siskiyou County, California. Better to use the Lidar data as suggested.
How about other off road trails is there a place or layer for that data?
I have about 15k miles of off road GPS data from mostly Arizona but includes some in Nevada and California that was collected while driving a 2010 Polaris RZR-S
Some of the data was on named roads/trails (BLM) so there might be some overlap, my methods for finding off road trails is to find power lines, the bigger the better, there is always service roads for them, off the power lines there is always a spider web of off road trails, then you encounter Pipeline’s same deal there is always a service trail or road that leads to more trail systems.
In the past 5 or so years most the off road enthusiast I have met all are mapping where they ride, it would be great to start a Open Off-Road Map layer to accommodate the off road groups, we all take Street Maps to get off road.
OpenStreetMap doesn’t have a concept of “layer” the way other mapping systems do. Instead, it’s based around the idea that objects have attributes. For example, “track” (or “unmaintained track road”, as the iD editor calls it) is a catch-all for logging roads, ranch roads, field access roads, and similar things. You can then add tags for other attributes such as surface type, access rights, who maintains the road, and so on.