I reported my mistake to the DWG, thanks for pointing it out. I didn't realize cut & paste in JOSM creates duplicate features. I've got a better way to fix my original bug.

Hum, I really screwed up. The few changesets show up in OsmCha as "possible import". It might be easier to revert them. I was trying to fix my own old bug in highway refs, but obviously did it wrong.

I'm deleting the duplicates, as I noticed the error, and stopped. It was an error in how I was using JOSM. This is my local area, I'd prefer to fix the problem than have the changesets reverted.

That's what get for using MS Bing footprints... I later discovered I can trace good buildings faster than validating the Bing data. Sorry you had to clean up my old mistakes, I prefer to fix my own bugs. Should I go check current OSM, or did you delete them all ?

To me the only difference is which apparatus to respond in. I reversed the ref:usfs change in Cimarron NF (Kansas), that broke the refs from displaying, now working my way through Colorado again.

I minor note, very few of the MVUM highways in OSM are in a route relation, just highway segments. I thought it was "don't map for the display". :-)

I modified my data cleaning software to reverse this when I make another pass through the data and use the semi-colon since it would be nice to have the reference numbers get displayed along with the name.

I went back and reviewed that thread on the tagging list. Using ref:usfs is mentioned several times, and even suggested it's usage: https://lists.openstreetmap.org/pipermail/tagging/2019-August/047463.html

However using a semi-colon is also mentioned several times, so to me there isn't a clear decision one way or the other. It'd be easy to make that change to semi-colons when I conflate county refs, I'm not 100% sure it's necessary. I'm flexible.

This is a good discussion to have before I make another pass through the data.

This was just the first pass. There was a long discussion on the tagging list to use ref:usfs for USFS numbers (and ref:blm), and ref for county roads, so that's what I use. Updating the county road refs is next, although I'm starting in Colorado. The next pass will catch anything missed in the first pass.

Sorry you have to fix my edit! I usually try to fix my own mistakes, but you'll save me the road trip to ground-truth it. That's one of the few really confusing road names I've seen in Colorado. Does all that actually fit on the street sign ? There's some pretty interesting roads names in remote areas of the West, which is part of the fun digging through lots of data.

There was a long discussion on the tagging list some years ago, and the rough consensus was to use ref:usfs, or ref:blm, etc... instead of adding them all into the ref tag separated by semi-colons. Easier to parse and then doesn't depend on the right "FR, or "CR", etc.. to know the operator/maintainer. Using FR instead of FS is on the wiki, I'm also updating my older changes to use that.

I'm just over the hill in Gilpin County, but do spend a lot of time in Grand County. You're the local, so the name is whatever you prefer. Often the name in the MVUM/RoadCore dataset isn't something locals actually use. My plan was to go there and see what the signs say, ground-truthing being the ultimate reality check.

Sounds like an accident during cut & paste, so I just changed it back after referring to the original unmodified RoadCore dataset.Good catch btw, thanks for the bug report! I've seen rural highways go through all sorts of changes over time, which is why ground-truthing is important.

I haven't been updating the surface tag, as that's something that really needs ground-truthing. Often roads that were gravel at one time become just dirt. I've been focused on only cleaning up the name and ref tags. The surface data is in the MVUM/RoadCore datasets though, and I just checked, surface=gravel was already in OSM.

I still had the Rwanda data including the post converted file from FMTM as a guide to fixing the tags. I guess that's a good reason not to cleanup old files. :-)

@KingVik, thanks for jumping on this quickly! Learning can be painful at times, but thanks for helping map your community during the flooding! Looking forward to your future contributions, hopefully not during a local disaster.

It looks like what happened was the data from ODK Collect was uploaded without running the conversion process FMTM uses. Rwanda was one of the very early FMTM field pilots, we learned a lot. We appreciate OSM Rwanda's help. But a lot of the conversion and conflation code wasn't fully working then. It is now as the 1st FMTM beta release will be soon.

It looks like the file was directly downloaded from ODK Central and uploaded to OSM. The data is still on our ODK Central server, so could be converted cleanly, but it's probably easier to just suffer through the manual change. The conversion from ODK forces only approved OSM tags and values. That's the whole point. That then gets conflated with OSM data and validated in JOSM.

There are two, and yes, one goes downhill to the local hydro power plant (the penstock), and the other is the other plumbing for the Ice Park, which is separate from the penstock. Yes, the Ice Park is unusual. A few weeks after I mapped the Ice Park, a landslide took out a big section of the penstock and our plumbing, and having it mapped made it much easier dealing with the insurance company.

https://ourayicepark.com/

Oh, if the current MVUM says it's ok for a passenger car, then yes, 4wd_only is over-kill.

Unfortunately 4wd_only is somewhat subjective. Me, I spend a lot of time driving rough roads. The fire fighter in me though has rescued more than a few people driving where they shouldn't, so at one time I was adding 4wd_only if that's what was in USGS data. You're welcome to change the tags based on your perception of reality. 4wd_only might be overly paranoid.

Since I had ODK Collect as the source, the data was collected while standing there. It is sometimes hard to tell the difference in surface between a poorly maintained road or a dirt one in imagery. I'll dig for my ODK data files to make sure it isn't a conflation error. I ground-truth in that area every few months, so can double check next time I'm out.

Since I'm looking at the data now, yeah, there are layers of other changes, so reverting the changeset would potentially create a mess. Better to just edit it the current data. Sorry if another local mapper is going to fix it, as I do believe we should fix our own mistakes. If somebody else doesn't fix it, let me know and I'll dig into the data.

If I added a relation to "all the trails", it was a mistake. I rarely ever add relations, and if I did, it'd be for just one trails. Are you sure this was my edit ? I can revert it, this is my local area.