Parking (on-street): note/2698551

From someone older, wiser & more experienced than I: http://linuxmafia.com/~rick/faq/crybaby.html#respect

Plus at least one other entry from that list.

Sad that you refuse to engage (constructively & honestly), yet then blame others for the effects of that, and lack sufficient self-awareness while readily projecting (wildly) upon others.
To then resort to schoolyard antics; very mature.
Remind me what you said about ‘attacks’?
Takes two to tango.

For someone who exhibits SJW-grade sensitivity, you don't seem to embrace diversity or tolerance. Sounds awfully privileged.

I'm most curious which questions I've ignored (there's (so far) only 1 question mark in this changeset discussion) and which problems I've not responded to (which I should've responded; I can't take on the global set). Seems factually erroneous. I can't help but notice the contradiction between this and your assertion that I won't engage constructively. I predict that this question will go ignored, too; rather proving my earlier points.

I would much rather discuss the actual issue, but when you refuse to, you make that impossible. Only you can change that, because only you can control what you choose to do.

If you don't like the consequences of your choices, then make better choices.

You don't have to respond to me, if it upsets you so much.

If you would prefer me to not comment on your changesets, then you already know the solution; ensure that they don't overlap my locale. That much should be obvious. You caused it to appear in my (very) local list of sets, I certainly didn't go seeking it as you might suggest.

You seem to imply that I should, instead, follow your example (unless you're not attempting to set one, while criticising others), yet from what I've observed (I don't need backroom whispers, myself, especially when they're used to make ad-hominems) that would be most unwise.

Ironically, part of my referencing that this isn't wikipedia, and being thankful of it, is in knowing what wikipedia has become (socially & culturally, within its own (former, now pseudo) community). It saddens & concerns me to see signs that such corrosive attitudes are creeping into OSM too, lately.

You're welcome to try again, when you can muster more rigour & take some responsibility (which includes less projection).

Best of luck.

Instead, perhaps go outside and do some surveying, if people with whom you don't agree (& whom don't pander to your wish of simply dismissing their concerns) upset you.
Visit an actual forest, in person. You might find it peaceful.

Since you've indicated that it's fruitless to respond until you're willing to engage on the matter at hand, I doubt I'll bother. The only exception being any necessary requests re the chosen size of your changeset bboxes.

Be well & enjoy productive mapping.

“the solution for your problem is not stopping QA edits”

Ignoring the projection & presumption over what the problem is; by ‘QA edits’ do you mean edits made in order to remedy tagging problems (like the ones you're doing), or edits made as a result of reviewing changes made by others?

I ask, because I'm going somewhere with this, but it depends on what you meant in your original.

@grin

“tools doesn't really help this kind of activity”

Considering how strongly you advocated this point in other changeset discussions, you should be only too keen to fix the tools you use, or use better tools.

Oh the irony of having to say those words.

“it takes exponentially more time to [do quality work]”

Welcome to OSM. Nay, any project. Nay, life.

As a surveyor (on-foot), I can muster no sympathy, given how long all sorts of things take to do well enough to be worthwhile.

I'm sure that a similar attitude re time for quality was taken by those who uploaded the tagging you're taking it upon yourself to refine.

“more time to manually”

Sounds dangerously like you're performing (as the DWG define it) automated edits. I don't recall you citing the relevant approved proposal; would you care to, now?

“separating logically connected changes into separate changesets.”

Yet geographically very distinct.

At best they're only connected by your desire lot fix them all simultaneously. Otherwise, what does one forest have to do with another (other than both being forests, since that's a very silly argument, and the implications make it ridiculous)?

“I have tried to fix only one problem in one changeset.”
But, hold on, what happened to them being logically-related? It's the very same element, this time.

Seems horribly inconsistent.

“Rather than removing something that was "obviously wrong" (which adds no value), why not ask the mapper what they meant? In that case "ground" would be a guess, but you'll find out if you ask them.”

A wise suggestion, @SomeoneElse . I wish more folks would ask before assuming wrongness.

For the benefit of the lurkers, re casually deleting: osm.wiki/Keep_the_history

@Friendly_Ghost

“Love you too, Lee ❤”

Aww, shucks. Group hug? 😄

Oh, wait, that only works with fleshies. Hmm.

@grin (et alli)

I'm in the same boat as MxxCon, re the ineffectiveness of tools to show only local changes including of large bboxes.

Further, the dismissive & presumptive attitude is disingenuous (thus I'm going to ignore your projection, baiting, and other dishonest nonsense). Especially when ignoring a cited quote from a developer of such a tool stating that, currently, there is no solution.

When OSM policy is small bboxes, then the problem is large ones (or, people ignoring sound policy for dubious reasons). Filtering is, at best, addressing the symptom. Thus it can never be a solution.
Same as with mail-abuse; telling people to ignore the problem isn't solving it. Filtering might help individuals reduce the effect for them, but that's no excuse to ignore the origin of the problem.

Just as ignoring a toxic human might preserve one's sanity by reducing the effects, but doesn't stop the toxic human from being toxic.

Large changesets have other problems.

“the word "spamming" means something else you think it does.”

Please do tell me what I think it means.

“people already told you in the linked discussion how to filter these changesets”

Please cite this viable solution, which doesn't involve ignoring a developer and/or hoster of any relevant tools. Especially given that, shortly before, you had said “Unfortunately I cannot provide a personalised solution for everyone.” which seems self-contradictory.

The attempt at changing the frame is interesting. An attempt which I reject, for many reasons, since it detracts from fundamentals.

The actual, real solution is obvious, which is what I've been pursuing (with a proven track-record) from the outset. Beyond that, was indulging my curiosity of the psyche involved in disclaiming any responsibility for one's own actions, and other evasive manoeuvring.

People have told you what the actual solution is, but you either (depending on interpretation) rejected or ignored it. Yet, when you receive the same response to your own suggestions, that's somehow a different story, and you merely repeat yourself. “Fascinating” as an observer of human idiosyncrasies might say.

I find it interesting that, given the nature of the cause of the true problem, and the advocacy of filtering, that said advocates fail to see where that thinking leads in the end (hint: filtering of something other than changesets).

Plus, that a very simple & reasonable request was made, yet the response is consistently evasion & deflection.

“fixing the tools you use.”

What do you propose, which is rational, effective & reasonable, in the meantime?

A tad more flippantly / facetiously, I might suggest that I was attempting to do precisely as the quoted text advises, in my opening comment. But, not all tools cooperate.

Beyond that, when using a definition of tool that only includes software, then the tools to be fixed are editors, in order to prevent misuse in the first place. Thankfully, I'm not the first to think that, and work is already underway.

Besides, contributors should be using tools to ensure that they avoid obvious problems with the changesets they choose to upload via their account. You've been told how to do that.

“why they have to be present on the same object”

Conversely; what's the harm of using multiple schemes?

If only a new one, instead of the old, had been used, then I would entirely see the point and accept the argument. However, that wasn't so in this case.

What was the gain of removing the alternative of which you disapproved?

“endless rant”

I was responding to your questions. Seems like you don't want responses with which you disagree.

No comment on the ladders question, I notice. Though, perhaps you've not seen that, yet.

“You still haven't explained what the supposed difference between type2:cable and type2_cable is and why they have to be present on the same object.”

Except that I did. Either you didn't read or didn't comprehend.

“How about making a proposal for new keys?”

How would that change anything given the basis of your objections (to new keys)?

Separately, a real-world problem re tagging. Since you like things a certain way, then I'm most interested in your solution.

Take a look at Gorey Harbour (east coast, near the castle). While surveying, I noted several ladders (between the surface of the pier / breakwater, down into the harbour). That's ladders, not highway=steps (there were a few of those, too).

I couldn't find a preset, relevant documentation in the wiki, or an obvious candidate in TagInfo.

The closest thing was for either scuba divers or for mountainous hiking trails. Neither of which applied to the context.

So, how would you not only tag, but also map (viz as a node, a way connecting the pier & marina, or something else) said ladders?

Gorey isn't the only place, here, with such ladders. Most of the marinas have them, and I've seen some non-marine ladders too.

At the time, I had no idea, hence leaving a note.

Apparently I'm not the only one to have identified this problem, either. See: http://www.github.com/simonpoole/beautified-JOSM-preset/issues/155

Once again, I'm commenting about what's sound, rather than argument-from-authority (or popularity).

“… undocumented … documented …?”

If I change the documentation, would you still use the same argument?

You've also cited the counts in TagInfo, before, as justification for why one string over another. So, I don't recognise your self-contradictory ‘undocumented’ gambit, here.

When the arguments are inconsistent, yet the desired outcome is always the same, that strongly suggests presuppositions, rather than starting from first-principles.

“What makes an undocumented colon more "backward-compatible" than a documented underscore?”

The backward compatibility is by using the ad-hoc *_cable in addition to more rigorous keys. Instead of only a more structured replacement.

We've discussed, before, this preoccupation with minimising key-count regardless of all other factors (including accuracy).

The consensus is that underscores (except in some legacy cases) are for separating words of the same part of the key, whereas colons are for separating parts (usually hierarchically).

The connector is still type2, all that's different is if it's only a female socket, or a tethered male plug. That's a sub-property, rather than a different type. Much like the electrical properties are.

Much as we have internet_access:fee instead of internet_access_gratis & internet_access_fee, especially since the answer is (commonly) a binary / boolean one.

Thus, especially since there were, as I recall, only about 1000 instances of the ad-hoc *_cable, meaning that it's still new and not even a de-facto convention yet, it seemed appropriate to offer a different suggestion.

This is how things change & improve. Do you not want OSM to improve (or change)?

Why must the first suggestion, even if flawed, be adhered to? Especially since there are examples of replacing ad-hoc convention with structure (diet:* being a very nice example).

By this line of argument, you would have deleted the first amenity=charging_station since it was the only instance of an undocumented tag. What about when new connector types come along?

This is all the more folly since, where I live, there are many differences, which would warrant at least different values to keys, if not entirely different tagging. Some may be unique to the island. That they're uncommon (elsewhere) isn't a valid argument against them.

For example: addr:city makes no sense, here. Jersey has 0 cities. It has only 1 town. For larger places, I can see how using the word city in a key-name often makes sense. What we do have, are parishes, and several villages. Yet, would you still argue that addr:city should be used instead of addr:parish ?

You seem to make a point of seeking such cases. When it's a genuine mistake by a newbie who doesn't know about a well-established tag which means exactly what he intended, then sure (but how do you determine that without asking?). However, when it's not that case (again, how do you determine that?), then it's (frustrating & tedious) interference. Especially that you presume to undo the work of local mappers, instead of asking for the rationale. That goes against the policy of local communities having authority (compared to outsiders) over how their area is mapped.

OSM is about accurately mapping the real world, not trying to make the world fit into predefined categories. Tagging syntax is to serve that end & purpose, not the inverse.

The world isn't a uniform place. It's messy. I've even encountered parking signage which was ambiguous (see note/2698617 ).

If you want newbies to make fewer mistakes, then it's all the more important that tagging syntax be structured & clear, rather than convoluted. So, I wonder how much of this is a self-reinforced (& self-inflicted) problem.

I'm only going to repeat this so many (a finite number of) times. This might be the last time.

“There is a tag to explicitly state if a type2 charging station has a cable. Why do we need another, new tag?”
That argument works both ways, actually. Especially since *_cable doesn't follow syntactic conventions.

Why would you want an unstructured syntax, instead of an existing structured one?

I could also make an argument about what'd be easier (in terms of keeping code simpler) for data-parsers.

Pot, kettle, black. Again.

Besides failing to engage (meaningfully) by (not) answering my question / request, you seem to be engaging in presuppositional reasoning, which is intellectually-dishonest, and prevents constructive discussion.

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

note/2725147

note/2718174

It would make a lot of sense, since your bounding box covers nations which saw no changes by your set.

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets