Ah, I see: the Santa Clara Valley "Open Space Authority."

I'm not the author who I think you are talking to (user:UnrelatedResearch). BTW, what is "the OSA?"

I did bring in the data that has the OBJECTID and Shape_Area and Shape_Length tags. If you read our wikis at osm.wiki/Santa_Cruz_County,_California#Additional_landuse_tags and osm.wiki/California/Using_CPAD_data .

These explain these, what are sometimes called "foreign tags."

Nice, Clay! Thanks for the efforts. I frequently look for Northeast Corridor data to polish up so it's nice and shiny. NEC is North America's premier "gem" of rail infrastructure and the more OSM can do (tag, detail, finesse...) to show it off, the better!

Wow, it was five years ago I did that from a five-year-old source (now ten years old). Apologies, but that's a long time for anything to not turn into a dead link on the web and I don't have a good source for NE Corridor speed limits — it's actually a dataset I've been looking for (high-quality, of course) for quite some time. Unfortunately, I did not download a copy of the PDF file.

If you do find such a source, please update our osm.org/wiki/United States/Railroads wiki with a link; thank you!

Looking at the history of way/34519577 (Jogging Path), it's presently v24, though what has essentially changed from v23 is from highway=path to highway=footway. It's possible my tagging didn't like the "dashed" rendering in v23 of highway=track, so what if you change it to highway=track (again, this is for "agricultural paths in the forest" that are double-wide, though it IS a "track" in the US English vernacular sense). If you added tracktype=grade1 (mostly "paved," which it is with rubberized surfacing,) that is still "more correct" and it would be a solid (rather than dashed) brown line. I realize we're getting close to tagging for the renderer, but I do strive for accurate tagging and I think highway=track and tracktype=grade1 are both accurate and will "render pleasingly."

This could rear its ugly head yet again, someday, so be prepared for a changeset comment about this coming into YOUR inbox in a not-too-distant-future, too!

Hi Joey, if you'd like to tag this as a running track (it is one, after all), I encourage you to do so. I haven't researched what exactly-proper tags might be for a rubberized running track, but if you think you know better tagging, by all means, please apply them. Thanks for asking.

Frederik, with what justification do you incorrectly re-tag these three areas? Having a protect_class=24 tag means that you must have a boundary=protected area tag. However, these have a boundary=aboriginal_lands tag AND a protect_class=24 tag, clearly wrong.

I'd be OK with changing boundary=aboriginal_lands to boundary=protected_area (keeping protect_class=24), I'd be even better deleting the protect_class=24 tag as superfluous (as Brian did), but I am not OK with the tagging you reverted, which is incorrect according to our wiki (24 needs b=p_a, but doesn't have it). In short, this tagging suffers from "pick one, but not both" and yet you've reverted to "both."

Please consider that the tagging that Brian did took the map from "slightly incorrect" to "correct," yet you changed these back to "slightly incorrect." I think (as does Brian) you have over-reached in your reversion here.

(BTW, I was born in Michigan and have friends there which should address your concerns of "first-hand knowledge of the regions involved." But I don't think that matters, as we can simply read our wikis on boundary and protect_class to see that this tagging is incorrect. So, let's correct it.)

Thank you, although after 11.5 years in this project, I certainly have a working knowledge of how the History tab works.

OK, so editors who are "in" the area contained within my edit will see my edit. So what? This happens to me all the time (in my area, people edit large areas that "contain" my area) and I look at their changeset comments and decide (virtually 100% of the time), nothing to worry about here.

My changeset comments say what I did (changed 316 nodes, but over a wide area, not a massive change, but yes, over a large area). This should make it clear to anyone whether they might be "inconvenienced," though I assert they won't be. The reason? The changes were to data which are not allowed by our wiki (nodes can't be tagged type=boundary). That's all this edit did.

Is there a problem? I assert no. Of course, in an open project like OSM, you are welcome to analyze the data in the changeset (both before and after), but I'd consider that a tedious waste of time. But sure, if you want to, you can. Some rather simple analysis on the data (not necessarily "one-by-one," it could be machine-assisted / mechanical) could determine this. All this did was remove a single tag from a data structure (nodes) which do not allow that tag. Not hard.

My question above remains unanswered. (How large is TOO large?) Thank you in advance for any answer you might (still) offer.

Yes, I realize that this is an extremely large changeset, certainly the largest ("worldwide") edit I've ever done in my 11.5 years of OSM. In all that time, I've never heard of a changeset getting TOO large and I ask you to tell me what is the threshold for that.

I am also quite aware that this is a worldwide mapping project and certainly don't want to confuse or inconvenience anybody, but I ask: how my edit might have done that? (for you or anybody else)? I mean, if the data that I corrected were wrong (and they were) and I simply corrected them, how have I confused or inconvenienced anybody? Thank you in advance for your answers.

Mis disculpas, el número de elementos cambiados se mantuvo deliberadamente bajo mientras lo hice (solo 14 formas y 1 relación en este conjunto de cambios).

Por ejemplo, trabajé para mantenerlos en países individuales de América Central y del Sur, uno o dos a cada changeset.

El área puede ser grande, pero como la densidad es baja, lo que cambió en cada changeset (¿conjunto?) de cambios no es demasiado, espero.

Read the entire section, understand the tags in context. They are curated data and these are left as tags to act as either an id into the source data or as a "checksum" to compare against newer versions. It's explained in the sub-section "Additional landuse tags."

So, yes there IS a "word about what this is, what the value is." Perhaps you might not be able to use the information, but others who curate SCCGIS data understand this and "use the information" to both identify and "checksum" previous against newer values, to see if they have changed.

If you cannot understand this after several explanations, I'm not sure I can help you. Ask specific questions of what you don't understand.

Wiki or Google aren't going to explain this, our local wiki does. (And some knowledge of how curated multiple-versions of data over time use both ID #s and "checksums" to see if the data have changed from version to version. Get it? No? Sorry, maybe you need to read a book or something. This isn't a terribly difficult concept to understand about adding and updating data in a database.

Find it where I specified above, in the county page of the county where you edited. You could even simply click on it. Bye!

I don't need to avoid this kind of discussion, as I haven't done anything wrong. If anything, you were wrong for your redaction. I DID "provide proper documentation. You neither found nor read it, even as it exists. Is that my fault? (No).

The wiki-internal function can't find things with commas and colons (sometimes). That's not me, please file a defect report with the wiki admins.

There IS a description of the tag. And now you know where.

I'm done with this.

Yes, they are: osm.wiki/Santa_Cruz_County,_California#Additional_landuse_tags.

Looks like your search didn't find these.

It seems we've had this conversation before.

These tags are fully documented in our county wiki. Redacted this changeset and restored the tags.

Oops, "I know, huh?!"

I know, hun?!

Thank you. You might want to mention DWG Ticket # 2020072410000029 in which I complained about him around the end of July.

When you close your edit (save changes), please use a MUCH more descriptive text besides "adding/correcting info." That is distinctly Unhelpful and actually looks like you are hiding something. Use highly descriptive text like "changed some buildings from aerial imagery" or "added a restaurant I visited."

I learned how to sail at the MBAC almost fifty years ago (and I think it once saved our lives when I was caught in a sudden storm on a ketch).

Use changeset comments well, please!

My friend in the great Pacific Northwest (Glassman), I see you have run in to Fluffy89502 edits like this, even local to me (a ways from you, that's fine). So far away that you correct it shows how egregious is this users mapping, in fact I an hour ago cleaned up more of the natural=heath mess around the Mojave Desert.

Thank you for your redactions, sir.

Fluffy89502, I have told you again and again that the road classifications that you do are far to broad and far too sloppy in their semantics.

Highways in OSM in the USA (this includes California, I believe your home state as well) simply do not fit into a federal classification system like "primary" and "secondary" were initially defined in the UK in this map's database.

Many people tire of your edits and having to clean up after you. Your behavior does not seem to improve, you simply move to another area and hope you won't get caught entering foolish and simplistic data which is easily refuted my those who see it. Clean up your mapping or OSM will see that you stop vandalizing. I, for one, continue to unappreciated your sloppy edits, especially after repeated admonishments.

You seldom engage in conversation and your changeset comments are atrocious.