@SomeoneElse you are right, I was thinking about that, but right now tools doesn't really help this kind of activity, and it takes exponentially more time to manually conversate hundreds of changes.
In the later changesets I have checked tag combos and when it was highly probable that "u" meant "unpaved" (especially for parts of ways) then I replaced that.
I may try to check how simple would be programmatically asking the question and process the reply stream... I am not quite sure it could work feasibly though.
Until then a completely invalid tagging isn't much different from no tagging at all, that's why I worried just a little deleting.

@Lee Carré you have entered a completely unrelated and really unnecessary comment directed against me. You do not honestly believe that I am not aware that this is OSM and not Wikipedia and that you really needed to remind me. Also I am sure you completely understood what I meant.

@Lee Carré I see people already told you in the linked discussion how to filter these changesets, so you really should do that. I also have linked the related issue above, since the solution for your problem is not stopping QA edits but fixing the tools you use.

@MxxCon: https://github.com/mapbox/osmcha-frontend/issues/572 may be the one helping you, provided someone from the developers implement it. Unfortunately I do not have the time to implement it by myself.
In the meantime achavi can handle these if you press "cancel", select your actual local bbox and press "load" again; the reason is that overpass API does not like huge bbox queries.

Reviewing *cases*, emphasis on "cases". All changes were fixing one case, and it was verified before and after, including automated tools (eg. validator, and checking related tagging). Yes, it was _all_ checked, and surprisingly fast: that is exactly the point of doing it.

But if you read the wiki you will notice that it's written with unattended code in mind, not manually observed, changed and verified ones. (Also covers a lot of non-applicable cases like large imports, which is very different from fixes covering a few but very scattered objects.) Also the wiki says that there always be an unhappy minority and I shall try to communicate with them, so here we are.

482 objects isn't much, and I hardly ever touch 1000+ objects "typos" since it's rather "non-standard usage" than typo. (Still, 1000 objects are 0.13 ppm [part-per-million] of the dataset.)

@MxxCon: Unfortunately I cannot provide a personalised solution for everyone. You could check the QA tools and choose which is best for you, or convince tool authors to make changes according to your needs. There are various realtime or history browsers, you may find one of your liking.

@MxxCon: yes, it is the solution for those who get _annoyed_ by large bboxes. They definitely shall skip those.

For everyone else there are various QA tools around, and I do not say I know them all. As an example I am using WhoDidIt (https://simon04.dev.openstreetmap.org/whodidit/) which filters on real chhange coverage. I have collected a large amount of tools on osm.wiki/User:Grin/bookmarks#QA but I shall probably review/extend the list again.

@MxxCon: find "BBox size bound" in filtering. Giving "2" filters out anything larger than twice of yor selected target bbox.

@MxxCon: find "BBox size bound" in filtering. Giving "2" filters out anything larger than twice of yor selected target bbox.

This comment of yours show quite plainly that you don't strive to cooperate and understand but to stand against and criticise. Please stop that. If there is something in the world you don't like you do not have to attack it immediately. You could instead try to find things you do happily, which make you satisfied, not stressed.

Global level QA works this way, if it makes you unhappy, exclude them from your view, please, to spare the attacks and needless debates.

If you need help, please tell me what system you're using and we'll try to find a solution.

@glglgl: you should avoid letting yourself annoyed. If you know a large bbox annoys you then try to skip those.

@Friendly_Ghost, @Zaneo: thanks.

@InsertUser: it is not a mechanical edit. Read the wiki please.

Dear Mr./Mrs./Ms. @fghj753! :)
Thanks for actually responding related to the changeset. :-)

One problem is that some people are indeed using defected methods to filter for local changes, since bounding-box based filtering hasn't been useful for a decade now. Many tools are intelligent enough to actually filter by content instead of the box, and other tools can filter boxes with corners the active area. If all else fails it's pretty obvious even visually to see if a bbox is larger than target area, and leave it for people with higher tolerance of bbox sizes. :-)

Other problem is that the fellows commenting here can't decide whether they absolutely want specific changesets (and resulting dozens of global changesets) or they want one merged changeset (global with lot of unrelated changes), apart from the ideas that the work shall take 100 times longer, which is pretty easy to give out as an advice (and I could have replied "why don't YOU do that then?" but QA doesn't work that way), but clearly unfeasible.

These kinds of changesets always will be global, simply because these kinds of problems are not restricted to areas, more often either to mappers making same mistakes all over or people making the same typical typo everywhere scattered (example to see: people counting on autocomplete and giving "surface=u" instead of "surface=unpaved").

What I can do is that I try to upload mechanical change and manual changes separately, but it means uploading errors which I do not quite like: some mechanical fixes reveal mapping/tagging problems. I'll see whether it's feasible.

The method/tools are nothing magical: go to taginfo, find obvious problem tagging, send over to JOSM, select all, fix all, verify, upload. (@MxxCon: any such idea would mean N-times amount of work for nothing; peopel complaining should rather use better filtering.)

One can open any changeset for viewing/editing in JOSM: File»Open location»insert changeset URL.

@gurlypipe: some changes may be in some countries, others may not. What you say may be true for one change and false for others. Most aren't.

@lee: the word "spamming" means something else you think it does. I wonder if you attack people accidentally putting unrelated changes in a changeset with the same vehemence...

It was [[Chuck Sites]], not me. I only removed the buggy surface tag. I haven't tried to fix stuff I have no information about, and there are some REAL weird stuff in various countries. :-) Feel free to fix it further! Thanks!

Try to tell me how *practically* you imagine "multiple changeset" in this case.

I tell you that right now it takes time to find the problem (that's the longest part, usually), then get all the problematic objects in one turn (from overpass), then select all problem object (at once), fix up the tag, this last phase takes about 30 seconds; then verify multiple ways and visually check a few times and places (2-3 minutes unless it's broken), then upload.

Now I wonder how you plan to do it when, say 50 countries are involved, and I do not even know which ones, since I do not download boundaries. I guess it would take few hours(!) to do what you propose and you don't realistically expect me do to that. Or anyone. Also it would create separate changesets for _related_ changes, which is exactly the opposite of why changesets exist in the first place.

You see it also correctly that if my changeset would have a problem it would be reverted _globally_, quite right, since if I screwed it up in Timbuktu then it'd be problem in Niue too. :-)

I am very familar with the wiki (as you may have seen on my HDYC page), also with global sized changesets, osmcha and other QA tools. When I say that I am aware *and* I am sure this is the correct way then I really mean it. It is rarely a good thing - this is the case when it is.

@mordechai23: if I uploaded one fixed value a time there would have been 10 times *more* global bboxed changesets. Is that what you mean?

Please also realise that I am very well aware what a bbox is, how it's working and why the large box is proper in this case. Repeating a wrong claim does not make it more valid and does not help the discussion. Also see my other changesets for parallel discussions, as well as contradicting advices from various people, which is normal in cases where all their advices are improper.

It is not possible, what you say is not related to the changeset. Please examine carefully what happens there: it fixes _global_ problems, not country specific ones. (Or, in other words, it may contain 100+ countries in one change, or "one change in every country".)
Please do not send out warnings without actually examining the changeset since it is possible that the changeset is right and you are wrong. Global changes may be unusual for you but it doesn't mean they're not valid.

It is not possible.