I don't add the operator, just that you can get a cell connection. Nothing displays this tag, but it's searchable since I have data loaded into postgresql on my laptop. Cell phone access is everwhere for many people, so seems silly to map it. But in remote areas it's useful for emergencies (or field work) to save long drives on jeep roads.

I'll change what I added to internet_access=yes, and can still filter that through camp_{pitch,site} when I'm looking for a cell connection. I'll adjust my XLSForm to do the same thing.

Hum, I thought I had seen that tag in use, but checking taginfo I see no such thing. Cell access in remote camp spots is a pretty important detail when working out in the field. I can change it to internet_access, but that's not the best solution either, as sometimes you find a cafe with wifi, but no cell connection. I'm open to suggestions, but can change the few I added to internet_access.

Interesting, as that those were recorded via GPS while I was standing by the information signs for each town. Most of these were small and short-lived towns, typical of the mining area. These are on the Alpine Loop, a famous backcountry jeep road between Lake City and Ouray.

In this part of Colorado most of the roads are dirt. Some maintained, some not. The difference is whether they can be driven with or without a high-clearance vehicle. Most of these are for access deep into public land. If you reference my talk at SOTM-US last year, I'm a huge fan of adding the surface tag, as it's an important detail for emergency response. Also smoothness is important, but that needs ground-truthing to be really sure.

It is a road in a national forest, and doesn't connect any settlements at all. There are many roads like this in that remote part of Colorado, primarily used by hunters, fisherman, and campers. If it's possible to drive in a normal car, I usually use unclassified, if it needs a high clearance vehicle then I usually use track. Course the difference between the two is subtle, and depends on the driver.

It was a typo, looks like you already removed it. Most County roads aren't tracks, but unclassified in a remote area like this. Whether it's 4x4 only is up to the driver. Probably better to assume it's a track so people don't try to drive it in a normal car, I don't remember the specific details when I was camping there.

I use postgres instead of Overpass, it's more efficient. Obviously the address for Silverton aren't very good. I'll go remove the addr:housenumber == 0 addresses, and see if later I can find a more recent version of the file with an appropriate license. Al of those addresses were added to help the local volunteer fire department, but obviously 0 is meaningless.

Good catch! Obviously a typo in the original address data I missed, thanks! I deleted it for now. I see some other weirdness in that part of Silverton I should ground-truth. I'm currently in Nepal, but will drive by there when I get back to Ouray.

Good catch! There are a bunch of other issues in this area, more than just CO 131 (which is a mess). This area hasn't seen much mapping activity, there are many per-exisiting issues beyond the tags I was fixing. As we use OSM for wildland fire fighting here in Colorado, fixing the issues is important, but can't happen in just a few changesets. I'm about to be deep in the woods offline, but plan to continue with the cleanup beyond just fixing the tags when I get back online.

If you had bothered to check, these are not duplicates, but different segments of the same highway. All I did was fix the tags. Who is "us" ? As a long time mapper in Colorado, telling me not to work on my own state is impolite. Threatening to revert changes is counter-productive, the usual process is to suggest fixing any mistakes. We're supposed to grow the OSM mapper community, not to discourage contributions.

I changed the tag, but the chances of mapping hundreds of campsites as polygons is probably not going to happen very fast. Some I could probably trace using imagery, most are in the forest, so I'd have to walk the perimeter of each site.

Having each camp_pitch as a node with the ref has been invaluable to my fire department for medical response. While there are tags for bearboxes, firepits, or picnic tables, they are not geo-located, so wouldn't display the way you want anyway.

When I changed from camp_pitch to camp_site was while the proposal was being discussed, I kindof jumped the gun, so changed them back. That is now an approved tag, and supported by the renderers, so I'll change the tag again this weekend. I will note that our local fire department has been using the ability to find campsites incredibly useful.

All our official camping areas do have a boundary polygon, except for the more dispersed camps. These are all in my local area, btw.

I added foot=yes, so figured I was just "correcting" the tags. :-) I can add it back, it doesn't matter to me one way or the other. I never checked the wiki about it, I just thought I was bloating out the tags unnecessarily, so removed it. I do live 2km from this trail.

Since it's highway=path, and has a sac_scale=hiking, I just thought foot=yes was redundant. Some of the tags are from the original import, which after our discussion about lhv=yes, I though I was cleaning up. I don't really care, but didn't think foot=yes was necessary unless it was foot=no, which none of those trails are.

As a local fire fighter who sometimes responses to this area, what exactly is used to determine "unsanctioned" ? We do use these type of trails for our response, could they be marked as private or emergency access only ?

I'm not sure if either is necessary, my temptation is to delete hiker=yes, instead of changing it to foot=yes. I think those would only be appropriate for =no, not =yes.

Maybe. It's an access tag, so maybe extraneous. It was in the original data. I'm doing as bunch of cleanup now ever since you mentioned lhv, and validating tags, and deleting a bunch of old stuff as "too much useless detail".. :-)

The additional tags added and any changes are based on public domain USDA map data. Access=private does seem potentially wrong, I'll double check. I don't think service is appropriate, note the current long discussion on the tagging list.

I think the key part of the definition was the number of axles in the vehicle, which rules out logging or fire trucks.

Thinking about it, I think I'm just going to delete it from any highway I added it to as incorrect.