Please do make those changes; thank you in advance. I left the landuse=commercial tag here because of the "mixed use" I understood about the property as it was being developed. But now, I think the landuse=* tag should be removed altogether (on the building). I think the building should be tagged building=apartments, as that's what I understood the "Now Leasing" sign to offer. If there are "mixed uses" (including commercial activity) taking place here, I don't know of them. It is possible that the "parcel" polygon surrounding the building=apartments should be tagged landuse=residential, though this might "flip" to landuse=commercial if it is determined that some of the activity (ground floor units?) actually are commercial. But again, I don't know of any; it seems like apartments (only).

Mixed-use landuse poses us a conundrum: OSM forces us to choose one vs. the other. Another example locally are "family farms" which are "zoned" with a tag SCCGIS calls "RA" which means "residential-agricultural." (Both). Which do we choose when it is "both"? This property is kind of like that, so maybe we best tag the building as building=apartments, MAYBE we tag the parcel with landuse=commercial if there is commercial activity.

The name tag can be as a sign on the outside names it (and I haven't seen that in a while, if you know of a correct name, please do enter it into a name=* tag on the building). Again, thanks for reaching out, this one WAS a bit confusing!

relation/12032585 is in Santa CLARA county, not Santa CRUZ county. I allow its tags to remain, as someone else in another county edited those and seems to have coined their own version, which at least partly explains the different tags you see. Contact user_5359 and complain to him or her about that one.

The rest, I say thank you for the OT link. Yes, I did omit relations in my previous OT search but I have remedied two that needed fixing (way/857006736, way/673743413 and the rest are OK). Check the regular expression in your OT query: as of right now, the results it returns have correct tags.

Apologies, we need only one. Our Santa_Cruz_County,_California wiki documents that sccgis:shapestlen=* is the preferred key.

I made some minor changes in one area, but an Overpass Turbo search does not show any incidence of the others. If you do find these, please describe their way # in OSM.

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?!