I have no idea how it's decided by the USDA, but the tag is based on the access, ie.. it's "open", which to me is a description of legal access. The legality of acces may be based on other criteria.

I think it has more to do with the width and smoothness of the road than the weight of the vehicle. Bridges are about the only thing I can think of with a weight limit. A dirt road doesn't really care how heavy the truck is.

That value was in the original data file, I just double checked the shapefile. For the "TRUCK" tag, here's what it says:

Attribute Definition: Open to use of a vehicle described as "All motor vehicles greater than 10,000 pounds GVW that are designed, used, or maintained primarily for the transportation of property or equipment, such as lowboys, log trucks, chip trucks, end dumps and fire trucks licensed to operate on public roads."

When they donated the climbing access trail and cliff data, they wanted to keep is separate from Eldorado Canyon climbing for printing their own maps. I added added the polygon as a simple way to do that since "is_in" is depreciated. They already have maps, so now it's not necessary.
A better way to group climbing areas would be nice, I think of Vedawoo, 10 Sleep, Laramie Range, etc...

That was done on the request of the BCC to group those, but you are right it's not really appropriate. I just deleted it and will find some other way to group those for the BCC.

Road_Core, not MVUM. MVUM is for 4wd_only roads, Road Core is for normal cars. You can grab my converted version here:
https://www.senecass.com/projects/Mapping/SourceData/RoadCore_FS.osm.bz2. It's huge, there's poly files up one level so you can extract just what you want.

Tell me about it, I have multiple other public domain datasets, and sometimes none of then agree. I wrote software that compares all the datasets and makes an educated guess.
The USGS topo map also calls it Glade Road. so it got two votes. That's the right link, data updated a few weeks ago, and getting better. I only added the name, can't vouch for the other tags. "Main Way" didn't sound quite right to be honest. and it was a name_1 anyway. it's marked access=service as it's only for service or emergency vehicles. In an emergency. we go anywhere we want if it's necessary.

I do know the GIS person for Arapaho Roosevelt National Forest, not sure if she'd know anything more than what's in the dataset.

I updated my copy of the USDA "Road Core", and that has both the name and the ref:usfs. I'm not in Larimer County, so you probably know better till I can get up that. There's many USFS roads that cross private property, so that's not an issue. But I can't tell the access unless I was there. "Main Way" was what it was named, so I made it an alt_name.

I fixed all the Front Range ones, limited to only the ways I had edited to be safe.

You just did help! We have tablets mounted in many of our apparatus running OsmAnd, as I've fixed most of the local data. Obscure old tracks are useful to us for wildland fires and backcounty rescues.

Interesting, thanks for noticing! I'll double check this. I'm not really into off-roading, I'm in the local fire department, so knowing road conditions helps us plan our response, ie... fire truck, brush truck, or ATV/UTV.

As far as I can tell, it's an existing problem. I did remove the 2 lines mentioned, I'll look for more. I've mostly just focused on cleaning up the highway tagging to support multiple highway names and refs, so touched many highways. Usually any thing I've changed uses "ref:usfs FS 525", not "name=Fs 525", since that's what I'm fixing.

I'm digging into it now, might have to finish tomorrow morning. I don't see them in JOSM, but do in osmcha. I did trace some of those tracks off sat imagery, so something went wrong that missed JOSM validation.

All I did was fix name, ref, ref:usfs, and ref:blm, based on discussions on the tagging list. I didn't touch the highways, but I'll double check to be sure. That may be an existing problem. The old Tiger data for SW Colorado isn't very good.

The Colorado aggregate data comes from the Counties anyway, sometimes I even find the same spelling mistakes. I'm not using your processed data, sorry. I processed the same data files with my own software since I also does validation of street names so navigation works.

There are multiple projects here in Colorado using the exact same address data, City of Denver, Mesa County, etc.. And Bing footprints too of course. These have been approved before, so I didn't think there would a problem. All I did was merge them together. I'll delete it all if you want, but addresses are important for emergency response, which is why I was adding them.

As a GNU developer, and long time FSF and EFF member for 30 years, I'm very conscious of licensing issues, and understand why this is important. I also understand I have to be careful not to screw up, and fix my own mistakes.

The bing footprints and aggregate addresses in Colorado are both public domain, and used for other projects. All I did was merge them together.
I did screw up by uploading more than I intended, fixing that now.

Yes, and other people are using the same data. This upload was a my mistake which I'll fix today. I was making a small change, and accidentally uploaded the entire raw data.

Yes, with validated address from recently updated public domain data, and conflated against current OSM data. Rural Colorado maps look different after you realize how many buildings here are. I do have to double check the Bing footprints, as it thinks rocks and snow fields are buildings.