Én az ortofotóhoz igazítottam. A törést gyógyítottam.

Pot, kettle, black. Again.

You chose to ignore all questions and not to respond to problems. You have not been constructive. (And I've been warned that you aren't with other people, either.)

Please recognise that you can't handle such problems with constructivity and simply skip them. There are possibly other areas you can work on without artificially generating conflicts.

Have a nice day.

@hfs: because I have tried to fix only one problem in one changeset. (Exception is when the uploading data contains obvious additional errors.)
(I was fixing surface tags and not keys with an asterisk. That one's a good idea, too, I'll check it someday.)

But you know that it doesn't work this way. 100 typos all around the world would be extremely time consuming to cut apart, it would make its handling harder and cause more grief anyway, separating logically connected changes into separate changesets.

@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!