With a calm tone, I answer you.

When I say "smear," I am talking about how using JOSM (and possibly iD, I'm not sure) to edit a polygon or multipolygon member can sometimes (especially with a copy-paste) re-write the polygon anywhere from a few centimeters to about a meter or two from its previous position. At wider zoom levels, this isn't noticeable but up close it is, and when left uncorrected, causes fairly massive misalignments (and these "ripple" the more edits there are without correction, making it worse) across an interconnected set of polygons (like landuse around here).

It is not that I do not like your edits. (Many were fine, like adding a parking lot with solar panels, I have left these alone and effectively applaud you for them). It is that like bdiscoe's edits, they "upset" surrounding data (because of editor error, not the human — you — who is editing them). It simply isn't true that neither you or bdiscoe did not smear (in this sense) these polygons, he did and you did, I'm sorry to say. Some of the blame goes on the software you use to edit, but some does go upon the human editor who is not careful to keep existing data which is largely aligned to continue to be aligned (with each other).

My edit (poorly characterized as a "mass edit") wasn't nearly as large as yours of this area in the last few days has been, as I only corrected the subset of your data which left the polygons in a "smeared" state. To make an analogy, I simply "put the jigsaw pieces back together again so they fit," rather than leaving them with poorly-overlapping boundaries. I wish it weren't true that editing (re-writing) polygons sometimes "smears" polygons like this, but I have seen that it does and it is an unfortunate defect in the editing program, combined with the complexity of the data in an area with tightly-fitting polygons of landuse, as we have here.

This was not a "revert" as you describe it. (I did not use a revert command in JOSM, for example). It was a careful examination of where your edits (and software editor) left the data in a state which was (slightly) inferior to the way they were before, and which, in my opinion, needed correcting back to the more-or-less correct state they were in. This is what I mean by "OSM conventions:" polygons which overlap neatly, not "sloppily" (as I get Validator errors, as you would or did if you were using JOSM with the Validator plugin when you uploaded your data). As it appears you edit with iD most (all?) of the time, it seems likely you did not get the errors in alignment you would have were you editing with JOSM during the Validator phase, but I do, so I correct them.

Adam, I don't want to fight with you. I have been cleaning up and improving the data from a poor and hasty import by user:nmixter over ten years ago. Due to my efforts (though I am not alone) the landuse in Santa Cruz County has won accolades. Just a couple of weeks ago one of the authors of Carto told me that this county has the best landuse in California in OSM and is one of the best in the USA. When I see that others who edit around here "upset" that, it is 100% correct to continue to maintain and improve these data to that (or better) state.

I have no idea what you refer to when you say that I may not use SCCGIS Zoning data here. That isn't true. They are here, they are SERIOUSLY improved from their v1 state over a decade ago (their improvement up to the present v7 should be obvious), and there is no reason they should be redacted, not used, nor improved (which is exactly what I and other local editors do). AND, the history of all this and how to do so is documented in our county wiki.

What you call "151 pages" results from the large numbers of nodes in some of these polygons. In fact (look right below), there were two ways and one relation edited. That's not a revert and it's not massive. 3000 nodes is the OSM limit on uploading in one changeset, so it was actually larger than this (a single edit, yes, it was significant, was very slightly split across two change sets), but I still contend that editing exactly two ways and one relation isn't massive.

Please let us strive to be harmonious in this project together. I honest do not like contention and friction, especially in a project that gives me as much joy as OSM does. I believe you feel the same way.

Untruth: I have not been "blocked multiple times," simply once. It was a "zero time block."

Another untruth: I did not "verbally harass" anybody. I stated (characterized) what was said and asked for less ineffective talk.

This always goes nowhere with this person. I'm reluctant to say more.

We just read a prediction of what someone else might do, self-uncertainly, unsure belief if the adopted project is broken, an unsolicited recommendation, a commentary about others "going off," an "eye roll," a complaint about things being harder and hyperbole about needing to needlessly fawn with too much politeness (we don't, there is no need to). Respectively.

Then, "I'll go crawl back under my bridge, I'm called condescending" (as he condescends). Ending with "report them" (call the cops, or the DWG, or something).

More map, less talk. I'm likely guilty of "too much talk" right here, right now, but I felt compelled to point out the tone of the blather in the previous post. OK, there, I did.

Rein in your posts, please; exclude such twaddle.

sean2019, this changeset is a poor quality edit, much too large in area and rife with noisy data. But you're hearing that more than once now, so please heed.

Thank you, btwhite92, for addressing that Fluffy89502 often changes highway classifications with little or no regard for local concerns. I recently discovered that F was doing this in my county (Santa Cruz) and that he was applying an NHS model on highways in an "absolutist" sense rather than deigning to OSM conventions and their "relative" sense to the local and surrounding highway network semantics (which is correct).

Please see osm.wiki/Using_CPAD_data which I completed yesterday to address similar concerns elsewhere.

I have created osm.wiki/Using_CPAD_data

Feedback is welcome and appreciated.

If you'd like me to "go the extra mile" and search and purge older tags, I will do so if requested, but I consider that an annoying errand, as there isn't a great deal of this "cruft" around, and going forward, this newer protocol will reduce/eliminate it.

The wiki offers the same advice as in Santa Cruz County: "Where objectionable, these can be deleted. However, please leave intact (older) tags of ACRES and UNIT_ID."

It is helpful for me to absorb more community input about "source" tags: explicitly set on each datum or does a reference to the source in changeset comments suffice? I've watched the trend towards the latter for many years, yet I consider an explicit source tag on each CPAD datum, perhaps with a sub-namespace flavor. Whatever I do can and will be documented as "a simple thing to do when uploading CPAD data" in a rule or two.

But for now, I think I'm on track with this. Another week or month, could be a few days. I'm a busy person. Feedback appreciated.

This isn't rash, this isn't adoption. This is a live, plastic map made by humans, plural.

The process being built is not radically altered by the plastic uses of tags as they are used here; it is human and organic.

Because of the tone here, I have begun to formulate in my mind a plan, rough sketch and several ways forward. There seems a way of conflating a well chosen tag that serves as a sort of checksum of data which editors can use as a comparison token, of sorts. That's it in a nutshell, it might take me hours, days or weeks to hatch it. There are no hidden needs, rather "non-OSM specific keys" aren't seen as a major crime, more like you are seeing eraser crumbs and I'm taking a deep breath right now to blow them away. That's all.

I hear the concerns.

Thank you for your opinions.

Think of ACRES as a kind of checksum of the data, as that is how it gets used (for comparison purposes between versions of data).

Going forward (and backward, as it has been included for exactly this reason), in time, UNIT_ID is a highly-useful tag to "index" between various versions of CPAD data (so far we are up to a third, though we no longer call them v1 / 2016a or v2 / 2018a, as no v3 was coined with 2019b, we now simply say "CPAD 2019b" and will do that going forward). So, please do continue to expect to see UNIT_ID in these data, it isn't unreasonable to include this for these reasons, so we do. (When I say "we," I include many local California-based OSM volunteers who use and coordinate CPAD data into OSM, such as doug_sfba, with whom, among others, I/we coordinate these activities).

ACRES is often included because the most common thing to change from version to version is the area-size of the unit, and the value of this key changing is a clear indication this happened (and so older data should be updated with the newer data). If a unit's shape changes in a subtle way, that can be hard to see visually, but this always will change the ACRES value, even by a tiny amount, so the many-digits of precision are helpful, perhaps even crucial to detect this. Several bytes of data are not "an unrealistic number of decimal digits," as this technique of using area to detect subtle changes in version-to-version data is both clever, effective and relatively low-cost (in terms of data stored).

The keys included may be undocumented, true, but there is no secret where they come from, why they are included (to wit, this and other changeset comments like it). Obviously you have noticed that as we begin our third (only partial, only carefully) bringing-into-OSM of these data (it's not an import, more like a one-at-a-time curation), there is some evolution of process, and that has included leaving in tags which do not (always) map well to documented OSM tags. Also, OSM tags (like park, national_park, natural_reserve and protected_area) have evolved, too, over the years, so it's very much like "changes chasing changes."

Again, I have said here and in wiki, "where objectionable, the tags may be removed" as well as "a few stray tags here and there as we evolve a process to better improve protected-areas in California are not a major problem." I've documented, I answer politely in changeset comments, I do not keep secrets nor am I trying to "get away with anything" as we do these things. Don't like the tags? Remove them, please. I (and others) don't seem to find them a problem.

They are from CPAD 2019b data, as documented on our Contributors and Santa_Cruz_County,_California wiki pages.

While I endeavor during these additions to remove all tags (except sometimes ACRES and usually UNIT_ID, so that we may compare between older CPAD, OSM versions and newer CPAD versions of the data), other tags (like the ones you mention) can and should be removed.

As the latter wiki mentions, "Sometimes tags from the shapefile in ALL CAPITAL LETTERS were left in the data when they do not logically map well to OSM tags. Where objectionable, these can be deleted."

I have been and do "better tag" on these. However, I don't see some stray tags finding their way into our map as a major problem. You are welcome to delete these, too. I appreciate you calling them to my attention.

CPAD data are under construction with the collaboration of other OSM volunteers in Santa Cruz, Santa Clara and San Mateo counties. We're now on on our third version of these (2019b) and the UNIT_ID allows us to compare particular units. You have mentioned to me that ACRES can be computationally computed; our Santa Cruz County wiki states "Sometimes tags from the shapefile in ALL CAPITAL LETTERS were left in the data when they do not logically map well to OSM tags. Where objectionable, these can be deleted." I don't consider ACRES "a mistake," but you might.

Yup, that's how it's done. You're welcome and keep up the great work! (GL w/finals)

It's like bricks in a wall, you think you'll never count to a million or a billion, then you realize you have a million brothers and sisters. Voilà, an ever-better map!

All, right! Go, man, GO!

The rail elements in the route=light_rail are changed from railway=rail to railway=light_rail.

Despite the service being DMU instead of electric, everything about this says "light" rail instead of "heavy," (which would lead to a route=train for the passenger service, but it isn't, it is route=light_rail). The concomitant train=yes tags (on stations, transit centers, platforms) are now light_rail=yes

Now, finally, the question confronts us: do we change the elements of the Escondido Subdivision from railway=rail to railway=light_rail where applicable? Following the example of the San Diego Trolley's three infrastructure lines (Blue, Orange, Green, though there is also a Silver passenger route on these), I would say "yes, we should" make these changes.

It would be good to definitively know if/when there actually is any freight service on the Escondido Subdivision, the "Freight Bypass Tracks" and minor amount of freight-appearing rail just past the Escondido Transit Center notwithstanding.

I have changed relation/1371791 back to route=light_rail (from route=train). Everything I know and can find about this calls it a "light rail" and calling it a train (as in heavy rail) seems incorrect to me.

Wiki changes made yesterday were backed out (to re-reflect it is light_rail, not train). The "service=commuter" tag on the relation was deleted, as this key:value pair isn't wiki-documented and doesn't make sense in the better-established context of the "passenger=urban" tag (which does make sense and is wiki documented).

While the route is still PTv1, some platform elements (as in the richly-tagged Escondido Transit Center) do begin an ability for upgrading to a fully PTv2 route, but other intermediate platforms will need to be added to the map and this relation.

relation/6161003 (Escondido Subdivision) seems fine — it is even additionally stitched into local transit as a bus_route.

relation/1371791 (SPRINTER) was updated with the text of the change in the wiki. In short, this route=light_rail is now a route=train and is documented in the wiki as so. Keeping eyes open here, as this is a curious edge of California/Rail: the distinction between a light_rail and a train route.