OpenStreetMap logo OpenStreetMap

Changeset When Comment
82364764

I have redacted this user's changeset in addition to addressing his wrong-headed approach in changeset/81521535 's comments.

81521535

They are trails and they have every right to be mapped, especially as they are mapped with access=no. If you KNOW that trails are "illegal" then tag them as such with access=no.

However, you may NOT remove them from OSM with a heavy-handed, "let's make what truly exists invisible" attitude like you are the "trail police."

These are not being "advertised" in OSM. They are being "stated as existing" in OSM. That's all a map does: it asserts the existence of a feature. You are welcome to "richen up" any feature on the map with an additional tag that adds an additional semantic (like access=private or access=no), but you may NOT simply delete these from the map.

I am not the only person in OSM watching your activities to assure you don't continue to do this. Please abide by what OSM is: a MAP. OSM is not your mother shaking her finger at you, a fence, the police or God issuing a Commandment. So, please, don't delete, rather, tag properly.

81521535

WTF!? Who are YOU to say these "don't exist" when you only assert they are not "LegalTrailsOnly." I'm reverting this vandalism of redaction and you should be ashamed of your OSM self.

82184541

I bow deeply in obeisance in your general direction, sir.

82083244

I continue to be truly impressed with the combination of local knowledge and good OSM tagging. Please, keep up the great work!

81886987

Nice work! I recall walking this almost 40 years ago and I appreciate the update to the tagging.

14853920

It was a poorly mapped imported polygon. I have deleted it as such. Thank you for bringing this to my attention.

79626874

OK, I think I've got all the updates into OSM and downgraded the wiki from "green" (OK) PTv1 to "yellow" PTv2 (as all 4 light_rail routes are missing platforms).

79626874

Still fixing Orange and other routes, give me about twenty minutes, please.

79626874

Just to be clear: the Orange Line in San Diego is missing quite a few platforms and this is noted in a fixme tag.

Whoa, now I SEE! SDMTS changed the terminus from Santee to El Cajon. That must've JUST happened: fixed. Thanks to you and your tool for catching this.

79626874

Can you please be more specific about HOW Orange Line differs? (And I have taken this train many times, but getting the final OSM details on it seems to be difficult, partly because it also has freight traffic, that is still sorting itself out as you'll see if you read California/Railroads wiki).

I'm looking at Orange line now, but I'd appreciate a way or node ID that can help me zero in on the problem you are seeing.

79664699

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

79664489

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

71263390

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

79261829

My behavior speaks for itself. So does yours.

Enough already.

79261829

Wow.

79261829

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.

79263054

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.

79261829

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.

79263054

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