I have reverted this changeset. It seems like a JOSM editing error on my part, although I'm not entirely clear what I did wrong. I will certainly be more careful here and try to keep such edits "more local" rather than statewide.

I apologize for the disruption(s). -stevea

Wow, weird. I did not knowingly edit in this area, either in this changeset or another. i did delete the oro tag on ..13 and ..14. But I couldn't find "Blanding and Clement" (they don't intersect?), nor a stop_position node for them, so I didn't delete what I couldn't find. If you give me another node # I can do that, or you certainly have my blessing to do so.

I don't know the old Alameda Beltline nor do I really understand what happened here. Thank you for calling this to my attention! -stevea

Thanks for your kind reply; better late than...yeah.

There are a lot of "edges" on Earth, around here are indeed some challenging ones. I'm glad so many of us keep busy working on them, where-ever they may be. Steve

My behavior speaks for itself. So does yours.

Enough already.

Wow.

Adam, please let this go. It absolutely IS arguing and I and this community are absolutely exhausted of your argumentative tone.

1) I hope to not have to repeat and repeat this as you do: what I did was not a revert. I am not artificially semantically splitting hairs as I say that. "Revert" (in OSM) is a computer science oriented specific set of actions done to the OSM database to specifically and quite exactly remove absolutely each and every edit done to the database in a single changeset. (In database / CS lingo, this sort of action is called "atomic"). What I did was not that, I changed one relation and two ways (three data altogether), a much more minor edit to the map than your changeset(s) around here recently and nowhere near an entire changeset's worth of data. So, please: no more characterizations of what I did as "a revert" as that characterization is demonstrably false. (I have beaten it dead into the ground already).

2) You edited in an area with existing data and re-wrote those data in an inferior state. (Not terribly, but enough that our Validator software noticed and complained to me about it). I fixed three data, a relation, two ways. As you like to say, "that's it." The only fair characterization anybody could make of that is "three minor fixes to three minor errors." Making a mountain out of this molehill gets us nowhere.

JOSM is not the only method to revert. It's likely one could write a SQL command line and do the same thing (the very specific thing meant by "revert a changeset"). I haven't done that (I'm not sure I'd know how, but I could learn) as I prefer the straightforward way that JOSM presents to do it, but I didn't do that here and I repeat myself as I say that, I shouldn't have to do with you here.

None of your hairsplitting matters, as I didn't revert you. I fixed the errors you left in the map. You do that, I do that, many do that. Without complaints and without needing to do research on the definition and subtle distinctions between "revert" (which I understand) and rollback (which I'm not familiar with in the OSM context as being any different).

What I did to your data WAS justified, for this very simple reason: there were data in the map which were (more-or-less) correct and you made them (slightly) worse. I fixed that by returning them to their originally-correct state.

THAT'S IT.

If you have a complaint, I am not able to better refer you. I honestly don't wish to continue the conversation with you about it. And as you say, neither do you, so ahhhh, at long last, we are done with this.

Peace. Out. Really, this time.

Thank you for taking the time to arbitrate, DWG. The previous (and only) time both of us were blocked, I was admonished for not specifically saying who was responsible for a poor edit (as you said "it was obvious from the comments who that was") yet here I am told that calling out a specific person is a bad idea, so I am a bit confused.

I did apologize to Adam in changeset/79261829 for my poor choice of word ("sloppy") as I meant it as "definition 1" (untidy) but I can see that is inflammatory as it also could have connoted "definition 2" (little care or attention). I wished that Adam had paid a bit more attention to the alignment of existing polygons (and hope he does in future), is all.

DWG, btw, noting the acrimony by many about "foreign tags" in (especially CPAD, but also SCCGIS data), I have recently written wiki "Using CPAD data" to mitigate the propensity of such tags finding their way into OSM. I agree with you that some of these tags do not belong in our data and have for some time said "where objectionable, these may be deleted."

I do give good reasons why (in that wiki) the original datum of OBJECTID (to denote "which polygon?") and the datum ACRES (going forward, cpad:acres) is useful as a sort of checksum against newer versions. (The same checksum reasoning applies to SHAPE* tags from SCCGIS data, but I have yet to get to writing that as wiki; I intend to).

Please understand that my intentions here are to do my best to make a wonderful map with the best data (most of it from personal experience, not data from elsewhere) possible. A great deal of that has been to clean up what other people have done, improving it greatly according to the feedback that I have received. Part of those efforts have left some "cruft" in the map and I hope it is clear (from the Using CPAD data wiki I wrote) that I am very much committed to cleaning these up — I have likened this to there being some eraser crumbs on the page and I have just taken a large breath to blow/sweep them away. Our map data DO get better and better, sometimes this takes a fair bit of time (and effort!) and there are some crunchy, unpleasant, messy details as we do. I honestly try to minimize these, as everybody loves sausage, though few like to watch it being made.

At the risk of both of us being warned about very long change sets, I'll answer.

#1: This was not a revert, as that is a specific thing and this wasn't that. It was a correction to some data you changed which left them in an inferior state from how they were. I simply edited three items (two ways, one relation) so they were "back to correct." I don't know if "blaming" your software is correct, but I have seen that before (as with bdiscoe) and even done it myself (inadvertently) before I figured out how to avoid it. To be clear: in places with existing data (which is correct), there are three possible results from editing there: improvement (yay, I'm all for it), adding things while leaving what was there alone (fine, so long as what is added is correct), and altering existing data so it becomes inferior. That does happen, as it did in this case and I don't know how (exactly), except that you were the last one to edit it (and it was fine before that). Hence, I "put it back to correct." That's not a revert, it is a correction to an error to existing data.

#2: A "revert" is using JOSM's "Revert Changeset" command (for example; there are other ways to do this very specific-to-OSM's-database "software verb," but I find the JOSM method to be the most software-straightforward). This simply wasn't that, it is a verifiable, computer-science-definable fact.

#3: The data were in worse shape (not terribly, but enough to need fixing) after your edit: polygons were misaligned ("smeared," there is no pejorative associated with that word in this context, it's a sort of geometric description), they had your name on the edit and I simply "put them back in alignment." I am perfectly fine with that, OSM is perfectly fine with that. This was not a revert. That is not semantics, simply a fact.

#4: Yes, it does. The only thing that means "revert" is literally "revert" (in an OSM context). What I did was correct data edited by you into a slightly incorrect state back to the correct state it was in before your edit. And there is nothing wrong with doing so.

#5: There is vandalism (I have seen it and corrected it) and this was not that, I never said it was. THEN, there is "editing existing data to (slightly) degrade it from how it was written before." That is what happened with your edit and I "un-degraded" those data back to their "more correct" state. There is nothing wrong with doing so. Same with bdiscoe's edits.

#6: No, it isn't opinion, it is simply geometry, and the "smear" errors were substantial enough that JOSM's validator complained about "overlapping landuse polygons" and other warnings and errors I corrected. There is nothing wrong with improving geometric errors in OSM, so I do (did).

#7: See www.thefreedictionary.com/smear definition 1c: "To cause to be blurry or spread in unwanted places." No pejorative, simply the geometric effect of placing two polygons on top of one another (one correctly placed, the other not) resulting in them being "smeared" when compared with one another.

#8: https://www.thefreedictionary.com/sloppy definition 1 says "Marked by or given to a lack of neatness or order; untidy." However, it also says (as def 2) "Showing or in the habit of using little care or attention" which is NOT how I mean this, as I think that you do show care and attention to your edits. (But in this specific case, you could have shown more care towards the existing data). OK, I'll concede a poor choice of word on my part with that, and for that I apologize. (Smear, I'm OK with, sloppy, poor choice).

#9: Adam, you don't always contact every single user when you make a correction in the map which is obvious, so let's (both of us) not be the pot calling the kettle black. I and others in this map, frequently "simply correct obvious errors." This includes you doing so, too.

#10: I don't know who you mean by "plenty of people" and I don't know exactly what you mean by "do this around here." That vagueness is what doesn't cut it. I do my best to address your concerns, but when they are non-specific, I literally cannot.

#11: Your doubt is mistaken; I did review. I was quite careful as I am experienced in seeing these polygons as I have edited them many times and seen various sorts of errors associated with them. (Have you?)

There is no back-pedaling here, I stand behind everything I did and everything I said (and say).

Now, let's do what DWG just suggested in changeset/79263054 and stay out of each other's sandboxes. OSM is much better as both of us avoid each other's edits. California is a big place with much cleanup/improvement that can be done. Being hundreds of km away from me, surely you can find things to edit closer to home (and you have, until recently).

Peace. Out.

I believe my changeset comments in changeset/79261829 answer your concerns here. If not, please let me know here.

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.