Really nice work on all you have done so far on USBR 77. That's it: I simply want to thank and congratulate you on some great improvements to both OSM and the USBRS.

Haven't you got something else to do? (Even if it sounds a bit nasty)

There is an exception for SHAPE* keys.

Hello Georg. WHAT "unknown tags?" The tags on way/914890246 are documented on our county page, osm.wiki/Santa_Cruz_County,_California

The latter (semicolon converted to a comma-space) has been implemented on this and all other USMOI where there were semicolons. Thank you for the suggestion.

I did, and because of the way you stitched it into the super-relation, I didn't even have to update the wiki! (which links to the super). Thanks again!

Nice work, Russ! Thank you. I'll update our USBRS wiki.

New tagging looks great; thanks for updating my previous changes to be more accurate as of now, especially the name=* tag.

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.