Serious kudos, Minh. This is truly nice work!

OddlyAngled, there is no "@" prefixing my name. Thank you for noticing my error that I dropped the natural=wood tag on a multipolygon. I have "fixed the issue."

SekeRob, you sure are good at using tools to characterize what OSM Contributors do wrong — or so you and your power tools think. OddlyAngled was able to offer me a SPECIFIC problem which I was able to SPECIFICALLY solve. Can you do the same about any of my edits? Or do you simply like to notice that after 19000 edits, some tiny fraction of them (none of which are specified) can have a statistical tool applied to them to "pick out fluff" and "cause a bell to ring?"

I have absolutely no problem with my OSM contributions, as the great majority are positive. Because I am human, I, you, everybody makes the occasional mistake. If you can specify a problem, do so. If all you can to is pull the trigger on QA tools that cause bells to ring, well, have fun, but don't bother me with their summary reports, as I or anybody can do that, too.

I appreciate that you reached out to me. Yes, my approximately 20,000 edits over 12 years means I AM an experienced editor.

What happened here is that I was working on three equestrian routes that were quite local to me (within kilometers of each other) and while entering their relation numbers, I transposed two digits, referring to a relation in Ukraine. I completed my edit and uploaded, not really caring that while the Ukrainian relation was pulled into my edit session, it was not changed in OSM's database. It DID, however, drastically increase the geographic size of the changeset (all the way to Ukraine). So what?

People getting upset about gigantic changesets doesn't upset me, especially when I realize that "nothing happened." It's just a bad habit that overzealous watchers of changesets have gotten used to quibbling about. As nothing really changed, and now YOU have proven to ME that you watch for global-sized changesets, I'm not really impressed, as it's an easy thing to look for. I notice you didn't take note that the relation IN the Ukraine didn't change. So this is really "jumping at the bell ringing" when really, "the bell ringing" doesn't really mean that anything (bad, wrong...) has happened. It just means that "the bell rang." Please learn to not pay attention to that when it truly doesn't mean anything. (Or better yet, don't "listen for bells ringing").

I understand how tools like OSMCha help avoid vandalism and keep the quality of the map high (I've been a professional software quality engineer and manager at software companies like Apple and Adobe). But I found actual errors in my professional career, not simply "bells ringing" that something MIGHT be wrong. It isn't. Not in this case.

Thank you for your concern.

Personally (just me, I'm only speaking for myself), I'm OK with a loc_name has an acronym in it, as "that's what the locals call it" (and who am I to argue?!)

There are many "happy mediums" (I know, "media" is plural) to be struck in OSM, purely for practicality. This seems to be a case of that. Far-out-on-the-extremes of "must NEVER use acronyms..." (as in this case, in loc_name, we wouldn't be violating the "don't use abbreviations IN THE name=* KEY") and "way, way, too detailed to be of any practical value" (although, you never know...) are OK to be seen as "way too unreasonable" in cases like this, especially with wider community discussion (as here).

So, the old adage of "map your best" seems to hold, although it's great that so many involved, interested parties have chimed in to offer perspective here. Really, this is about communication and consensus, not so much about what actually persists in the map as "definitive and authoritative." One person's "best" sometimes becomes another's "bone of contention." As long as the right people are discussing, we're on the right track.

And just because you, him, she, they...don't know of a particular naming convention or data-flavor-casting does NOT mean that it can be glibly ignored. Again, "map your best" to be "true to the original source data," but if / as this becomes overwhelming, burdensome with too much details or outright "wrong" (locally speaking, but not officially speaking) OSM has ways to streamline, call something "local parlance" or do similar data smoothing that can avoid ruffled feathers and make (most) everybody (mostly) happy.

San Luis Valley, not Sal Luis Valley.

Brad, the "convoluted mess" you mention (our United States/Public Lands wiki) is a truly valiant effort on the part of many dedicated USA-based OSM volunteers to address what are a great many seriously complex issues. While it is clearly still "wet paint," it has evolved over years and by many to be the best we have right now. The "please join us" spirit repeated here is genuine and is earnest consensus-building, truly required in this endeavor.

I appreciate that the official_name=* tag was chosen to be used here, that's excellent. I'm not local like Brad is, but can we delete "Field Office" from the name=* tag? This vast, sprawling area truly isn't such a thing, and as Brian says, it is likely that one particular BLM field office is what administers this. If Brad knows what the loc_name=* ("vernacular by those who live there, use the area") is, it would be good to add that, too. And I'd guess that omitting "Field Office" from the name, making the name=Sal Luis Valley tag what eventually sticks, is a happy solution for everybody, especially with loc_name and official_name also defined.

Thank you!

Route redacted.

Hello fmorel: anybody there?

When you entered the "Baja Divide" mtb (it cannot be both an mtb and network=icn, as the former are unpaved and the latter are paved) from where did you obtain the route data?

In the relation itself, you tag website=bajadivide.com, however, that website clearly states "©Nicholas Carman and Baja Divide, 2016-2020. Unauthorized duplication prohibited."

This (entering copyrighted route data) violates OSM's ODBL. Unfortunately, this likely means the data will need to be removed from OSM.

BTW, we both started mapping over 12 years ago in OSM on EXACTLY the same starting date!

Wow! Thank you! And for your wiki comments and updates, too. Wow, again!

Well, you say "rendered" and I know what you mean. But it might also be "displayed in a pop-up in an overlay layer" (for example) and it wouldn't be wrong to do that. If / as you move it from key name to key note or key description, yes, you are "being accurate" in the case of the "hand-wavy" ones, I've said I'm OK with that.

But stuff like "Mason-Dixon Line" well, that IS its name. For those "solidly named ones," I'd leave it name key.

That's a discriminating task, though it is where a "more precise, reasoned, seasoned" opinion (mine) lies. Make of it what you will, and I appreciate you asking me.

The stuff about "dissolving into pieces," yes, that is what is happening. We as the "next editor in line" who must (or does) salvage the pieces / remnants of how the data were originally authored, well, we must "simply" do our best. I can tell that's what you want to do and offer the perspective of "data are seen a lot of ways through a lot of lenses" and it isn't always clear to us as authors which lens data will get looked through as we author them.

(For example, a lot of TIGER rail data from about 2006 has "smeary" edges on certain tags, it's actually a sort of interesting thing to see how it happened (sometimes this is clear, sometimes its really muddy) and how it might be fixed. Sometimes, things can't be fixed and either must get tossed or "kept, but mostly ignored."

I do NOT think leaving the name field blank is best. The name field does correctly "name" these entities and it is used by many data consumers in OSM, like renderers, editors, "presenters" (e.g. in an "overlay" layer, clicking on a route or boundary might display the name in a pop-up), etc.

It seems like what you want to do by moving the value of what's in the name key to description or note is to "hide" it from being presented in a data presentation layer/scheme or renderer. If that is your motivation, that would be wrong, as in "don't tag for the renderer."

As you note, some of these (e.g. Mason-Dixon Line) are absolutely the "name" of the boundary, and so SHOULD (I'm 100% certain) remain in OSM and NOT be changed to a note or description key. Others that really ARE more "descriptive," well, OK, I suppose if you want to take the time to do that, it is a "more correct" way of assigning these values a better key. But now the onus of determining which really ARE "real" is totally upon you.

For the ones that CLEARLY ARE "made up descriptions" ("...roughly this to near that"), I'm OK with it. For the ones that have a clear, historical name (a real name) that survives into today, those should remain "name."

Honestly (it WAS three years ago), I don't recall the specifics here. I vaguely recall examining these and might have found some "outliers" that didn't meet what seemed like "good naming conventions" so I likely decided to make them "at least good" (better than they were).

If you know of any "international standards" where good, better or even BEST! naming conventions supersede or improve upon what is in OSM (especially changing "rougly" to "roughly"!) please, do change them. The map welcomes your improvements.

Thank you! These are simply GOING TO drift over time. It's great to see them getting updated.

Not a problem, they do put erasers on the ends of pencils; I have goofed up plenty of times!

Hi Clifford: Both relations in this changeset DO have rail elements: the NP Wahluke Branch has railway=disused elements and Lordsburg Sub is full of railway=rail. The two old relations were deleted (being replaced with these).

What, exactly is the question? I'm happy to change something so it is "fixed," better or more conforming to OSM standards, but I am not clear on what you are pointing out is wrong here.

OK, I think I got the Whiskey Island north end the way you describe (and so does ODOT's application to AASHTO now make better sense).

However, any other parts, especially ones you recently biked in the last week, PLEASE, you are fully qualified to "fine tune" the route anywhere!

PLEASE change the USBR 21 relation to contain actual, better bicycle infrastructure along here. There are a lot of eyeballs looking at whether we're getting it right here, so, yeah, a local mapper who ride/rode it absolutely ROCKS at entering better route relation elements here. Yeah!

Thanks for the shout-out. Great to see your name, mapping and well, go OSM!