piebro/osm-data huggingface dataset:
Kovoschiz (2021-08-29 12:00:05+00:00): This case is more complicated, being a hotel complex. It was improperly fixed before.
philippec (2021-08-29 19:57:33+00:00): Kalmthout Heide kerk aed, ik hoop dat er nog een Imgur komt, dat is nuttig als backup.
Pieter Vander Vennet (2021-08-29 19:59:08+00:00): Nee, ik had geen tijd om die nog te nemen - ik moest een trein halen.
philippec (2021-08-29 20:03:37+00:00): Ik had jarenlang dat probleem met kinderfoto's.  Toen ontdekte ik dat in Android een instelling bestaat die de foto app opent als je 2 seconden op de aan-knop duwt.
maraf24 (2022-04-30 10:44:23+00:00): W tej edycji w paru miejsach przerwałeś ciągłąść trasy dla rowerów - tj. pojawiły się odcinki footway zamiast path czy pary footway+cycleway.
Przykład: https://www.openstreetmap.org/way/613953431/history
Mordechai23 (2022-04-30 20:27:48+00:00): rzeczywiście był to błąd
limes11 (2022-10-22 11:00:09+00:00): Hi,

was genau macht H+S hier? Design? Produktion? Lager?
Verkauft werden hier doch keine Fahrräder, oder? Ist das wie bei Canyon in Koblenz, dass Probefahrten möglich sind? 

shop=bicycle ist vermutlich nicht korrekt. VG, Limes
berndw (2022-10-23 14:36:12+00:00): Hier ist kein Shop, nur Versand bzw. Verwaltung.
limes11 (2022-10-23 16:15:50+00:00): Schön. Wollte gerade vorschlagen, es mit building=warehouse+office=company zu erfassen, aber da warst du schneller. Vielen Dank!
Kenneth Pion (2021-08-29 11:21:05+00:00): Afgeschafte voetweg en nu privaat eigendom 
http://docs.vl-brabant.be/gisdata/abw/BIN/Wijzigingen/Document/BIN_PW_015.jpg
Jakka (2021-08-29 13:37:54+00:00): Niet een goed idee deze te verwijderen. Vermoed binnen afzienbare tijd staat die er terug op. Is fysiek aanwezig..... Beter access=private erop zetten. Met de nodige attributten aan beide kanten..
Er kruist daar een voetweg diagonaal bij de kruising is daar iets te merken van private weg. Wandelaars kunnen die onbewust inslaan....https://osm.org/go/0Eo7xtbek-?layers=N&m=
Kenneth Pion (2021-08-29 19:48:14+00:00): Die weg is ook op de kruising met voetweg afgesloten als private weide.
Kenneth Pion (2021-08-29 19:48:45+00:00): Hoe zet ik deze terug?
Jakka (2021-08-29 19:53:33+00:00): Als de track dicht is met weide noordwaarts en zuidwaarts en afgesloten dan is deze weg er niet meer....
Kenneth Pion (2021-08-29 20:01:48+00:00): De sporen van de weg zijn nog zichtbaar, maar helaas niet meer begaanbaar.
SafetyIng (2021-08-30 10:02:08+00:00): Hey, du hast hier u.a. Streckenabschnitte hinzugefügt, die nicht mehr existent sind. Ich würde dich entsprechende Inhalte wieder zu löschen. 
Grüße
Robin
Alexey Vazhnov (2021-10-08 17:31:47+00:00): Why did you set amenity=photo_booth for Kaufland supermarket https://www.openstreetmap.org/way/30266315 ?
Alexey Vazhnov (2021-10-08 17:35:40+00:00): Removed in https://www.openstreetmap.org/changeset/112275668
aleo26 (2021-10-18 11:23:40+00:00): Hi, there is a photo booth inside the Kaufland, but seems that I have accidentally set it for the entire building.
Alexey Vazhnov (2021-10-18 11:28:37+00:00): @aleo26, no problem :)
You can add a point with a booth and put here a link to your final changeset.
快乐的老鼠宝宝 (2021-08-29 11:47:08+00:00): 关于这次修复的Tag总计：

cuisine=中餐
cuisine=饺子␣(jiaozi)
cuisine=烤肉
cuisine=中餐，酒，饮料
cuisine=中餐;早餐
cuisine=炒菜，干锅，面条，米饭
cuisine=北京味道;炸酱面;饺子;炒饼
cuisine=热干面;包子;饺子;炒河粉

一共是这些，全都非常傻逼
迎春心情 (2021-08-29 22:33:04+00:00): 不文明词汇……
Supaplex (2021-08-30 12:03:23+00:00): It is very kind for use to correct the restaurant in Taiwan. Maybe you could split the changeset much smaller. Make it mangageable and know what is changed
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/110409409
Warin61 (2021-09-01 00:26:59+00:00): Hi,

Can you correct way 977500980? 
See https://tools.geofabrik.de/osmi/?view=areas&lon=151.67070&lat=-30.21722&zoom=17

You may like to keep an eye on that site to see if there are any more errors of a similar nature?
Davie Dean (2021-09-01 03:06:09+00:00): Sure. Should be fixed now: https://www.openstreetmap.org/way/977500980. Weird that I didn't notice that in the JOSM validator on uploading.
Hanan Tikveša (2021-08-29 12:12:27+00:00): Why don't you create a changeset for each place?
Zaneo (2021-08-29 12:56:45+00:00): That sounds like a silly idea. This changeset groups the change topically. +1 for topic grouped changesets.
julcnx (2021-08-29 13:16:30+00:00): If everyone does large geographical changesets, then no one will want to review local changes in osmcha.org. What if a country has its own specific guidelines? Have you even considered that?  -1
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/110409629
Mashin (2021-08-29 14:08:48+00:00): Though a fair point is that it is the limitation of tools like osmcha and archavi than the extent of geographical area that prevents people from reviewing 

https://dev.overpass-api.de/changeset-map/#110409629
https://dev.overpass-api.de/achavi/index.html?changeset=110409629
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/110409629
tekim (2021-08-29 18:28:45+00:00): Regardless of the large bounding box, this looks like an edit that would fall under: https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct, and as such should have been discussed with the community on the mailing list before taking place.  If it was discussed and I missed it, my apologies.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/110409629
ouleyang (2021-08-29 19:15:02+00:00): Thanks everyone for the feedback. 

First of all: this is not an automated edit, I made each change manually and did not use any script or even "search and replace". I did filter planet.osm to find the nodes with issues, but edited them one by one and steered clear of any that could be problematic (elevation in feet, approximations, comments and names in languages I did not understand, etc.). There are still 274 nodes with non-numeric elevations. 

I was also not aware of a limitation of size for the area covered by a changeset. What would have been the correct way of doing this? I will keep it in mind if I do another edit of the same nature.
tekim (2021-08-29 19:38:49+00:00): @oulenyang
thanks for your considerate response.

Good to hear that these edits were individually reviewed, that is the safest manner in which to go about this.

Regarding changeset bounding box size, I couldn't find anything on the wiki about it.  It has been a general understand among some (but obviously not all) in the community that smaller is better if possible.  To split into smaller changesets geographically you might load in all of your candidate objects to JOSM, use the select tool to select all in suitably sized region, add them to the todo list, step through, upload, repeat.  There could be better ways, but off the top of my head, that is how I might do it.
Lee Carré (2021-08-29 19:59:58+00:00): “If everyone does large geographical changesets, then no one will want to review local changes in osmcha”

This is one of the troubles I have. While I do use OSMCha to filter-out changesets with large bounding boxes (because, otherwise, for my locality, the noise (irrelevant changesets) exceeds the signal (locally-relevant changesets)), this then means that large-area changesets which do change something local to me are also filtered-out. Thus, I'm not aware of them in order to review them.

“limitation of tools”

I notice that this dismissal frequently arises. Regardless of whatever ideal of how things should be, they're not currently that way. Until they are (capable tools being readily available) then it's a moot and/or academic point. We have to work with what we've got, until what we've got is improved.

More capable tools, besides being hosted at all, will require more resources (both from developers (time, experience, complexity), and the computing variety).

Various lessons from computing history suggest that it is preferable to keep algorithms simple, and for whatever necessary complexity to be in data (as opposed to the inverse). This is based on human cognitive capabilities regardless of any particular development environment (or whatever other technical concerns).

If people rose from their armchairs and went outside to do more surveying, then giant changesets would be less of a problem in the first place.
Mundilfari (2021-08-29 20:28:38+00:00): Could anyone explain what's wrong with using overpassapi +changesetmap or achavi for reviewing whether a changeset affects your particular local area as suggested above?
Since it's the same group of individuals complaining about large changesets regularly, I'd be curious to hear their perspective.
Mashin (2021-08-29 23:02:32+00:00): @Lee Carré
Check those two links I posted above (they are from dev version of overpass run by user mmd). I use those for viewing large bbox changesets.
Generally algorithms should adapt to users' needs and help us work less not the other way around.

Also if people would have got out and do surveys, there would be barely 10% of the data we have in OSM today.
julcnx (2021-08-30 02:05:25+00:00): The links are good to know but you omit one basic thing: productivity. Thousands of volunteers review during their limited free time dozens/hundreds of changesets per day to maintain a certain quality in their area of mapping. They do not have time to manually construct links, jump from one tool to another.  So until the tools are improved and those technical issues are solved, the very small minority of mappers making changesets spanning over multiple countries/regions are basically disrespecting the work of thousands of reviewers across the world. Got plenty of time yourself? Then please go improve the tools so we don’t have to argue about this again.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/110409629
Mundilfari (2021-08-30 03:50:26+00:00): Mh, so it's not a lack of proper tools but a lack of willingness to use a tool that's actually fit for the purpose (finding out whether a change set affects your area of interest or not) then?

One could turn that productivity argument around very easily - thousands of volunteers work on improving the map around the world during their limited free time. They do not have the time to create a separate change set for every node they touch, writing a half page essay for a change set comment every time.
I get the "it's disrespectful" argument to a degree - but, that one as well can be seen differently: Forcing thousands of editors around the world to trade their productivity because a smaller number of individuals isn't willing to use the proper tools can certainly be seen as being disrespectful too (think: "I can't be bothered to use a better workflow, so everyone should do everything they can to make my personal life easier"). 
What one person considers an appropriate change set size (country? state? county? city?) may still be unacceptably big for others (say, someone who focuses on a particular neighborhood only).
On the other hand, cutting change sets like this one (which do one thing only, just spread over a large bbox) into potentially hundreds of individual change sets is not exactly fun to review either. IMO there is no sweet spot - you'll always find somebody who will be offended.

Finally, the "if you have plenty of time then go fix it" argument isn't fully consistent either. Some individuals clearly have the time to comment on almost _every_ big change set. It would have taken a second or two to copy/paste the change set id into one of the tools linked above - much less than this whole discussion. Also the logic seems a little off. It would stand to reason that the individuals feeling they need better tools should have the highest interest in driving the improvement of the tools. Delegating that seems completely backwards (think: "Until I get the tool I want, I'm gonna enforce an arbitrary set of rules that I myself consider appropriate and if somebody doesn't like them they're free to give me said tool").

All of that being said - I'm not saying big change sets are good per se (in all honesty I'm not exactly a fan of them either, especially when all they touch is one park bench in california and one turn restriction in china); I'm just saying that there's other perspectives as well and this whole "all big change sets are inherently evil" attitude feels a little over the top sometimes; and grouping changes of the same type in one (potentially large) change set can make sense.

If anyone is interested in an actual solution to navigate to achavi from osmcha without having to copy/paste the changeset id: you may be interested in the osm smart menu browser extension*. It adds a little toolbar button that lets you jump between all sorts of osm related websites and services. That way, the achavi site with the correct changeset selected is literally two clicks away from osmcha.


* https://wiki.openstreetmap.org/wiki/OSM_Smart_Menu
Kovoschiz (2021-08-30 04:14:55+00:00): You shouldn't remove the explicit `=*m` unit, even if it's the default.
Zaneo (2021-08-30 07:58:28+00:00): That seems like an arbitrary rule that you just made up.
Mashin (2021-08-30 12:53:42+00:00): @cmoffroad
with free projects it works as such that if you need something, you do it yourself or you go to someone who knows how to do it and you ask them nicely if they can do it for you: https://github.com/mapbox/osmcha-frontend/issues

IMO with words like "disrespecting" you are pulling a lot of assumptions about someone's motivation and giving too much credit to the importance of other people
Friendly_Ghost (2021-08-30 21:08:33+00:00): Thank you, ouleyang, for your contribution. If I can be of help with similar cleanups, I'm happy to lend you a hand. 

Also, I would like to echo Mundilfari's message. You said that well.
mmd (2021-08-31 07:34:34+00:00): Tool co-author here.

Today there's no workable solution available to analyze large changesets.

The two links posted earlier on point to experimental Overpass instances on a development server which I run.

These are strictly meant for demo purposes only.

Neither does it make sense to add links to those sites in OSMCha nor in any other external tool as suggested before.

Thank you.
SekeRob (2021-08-31 08:36:51+00:00): Hi all,

Lurker here watching the conversation. For / against and middle ground positions been shared so not going to add on that but to say that any, ANY tool that can purge these continental and global CS's from my 50x60 km history view, area of interest and watched like a hawk, is welcome to share their pointers. I see a dozen WW a day, several will happily insert themselves in my eyesight for days on end regardless of the max of maximized zoom in (readers between the lines get the gist of where I stand). Anyway, Smart Menu is another added to my mega active tool box.

Happy mapping.
s_SoNick (2021-09-01 06:49:00+00:00): Adding another data point here, I map the mostly-unmapped areas of Western Kansas in the US. Very few others in the area ever touch the maps, and changesets covering gigantic geographical areas have rendered the history for my area unusable; if someone other than me has added something to the area then the only time I can review it to fill in missing details is if I happen to notice a minute change.

Not a lot to add here, another than another voice to add to the "please don't do this" polite requests.
Lee Carré (2021-09-03 17:01:32+00:00): “so it's not a lack of proper tools but a lack of willingness to use a tool that's actually fit for the purpose (finding out whether a change set affects your area of interest or not) then?”

No (that is: incorrect). This is fallacious in multiple ways. The question isn't even factually correct.

Besides other factors, I'm in a similar boat as s_SoNick, who articulated the problem more clearly than my own attempt: “Very few others in the area ever touch the maps, and changesets covering gigantic geographical areas have rendered the history for my area unusable”.
For me, using OSM's native UI, the vast majority of what I see are global changesets, compared to a small count of local ones which I must then hunt for.

Further, when I must resort to filtering out any changesets larger than my jurisdiction, as I explained (perhaps poorly) earlier, this also matches some large changesets which do make local-to-me changes. So, I'm in a no-win situation.

This becomes yet more frustrating because there are only a small handful of locals contributing to the area.

“Check those two links I posted above (they are from dev version of overpass run by user mmd).”

Dismissively directing me to proof-of-concept prototype implementations (which isn't a criticism of their author(s), or the tools) that either are troublesome to use on a nano-computer, and/or which have banners stating that they're not intended for production-grade usage, misses the point (and previously stated criteria), as well as being disingenuous if not (intellectually-)dishonest.

If participants aren't gonna be (intellectually-)honest, then this whole topic is already at stalemate.

mmd already addressed the obvious technical problems with such a (‘brave’) proposal, and is more qualified to do so. Thus, I'll defer to him instead of making my own attempt.

“They do not have time to manually construct links, jump from one tool to another.”

Especially when out surveying, or otherwise using a limited device. Even checking the history of an element is a pain in the butt. Reading documentation is also sometimes challenging; stood outside (in front of whatever I'm trying to determine how to add) after a lengthy walk (to reach (or even discover) it), when it's dark, cold, and otherwise less than comfortable …. Often I either simply don't add something, or drop a note, or only do the minimum, because that's preferable to making a silly mistake due to adverse environment.

This is part of why, sometimes, quality surveying takes so damn long.

My overall point, here, is that many of the arguments made in this discussion appear to assume the considerations and/or perspective of armchair-mapping. Plus, neglecting that survey-time is precious.

“Today there's no workable solution available to analyze large changesets.”

@mmd
For those with a tech background, is there an existing write-up of the problems from a tool-dev perspective?

It certainly seems a non-trivial task, but I don't know enough about what'd be involved (being a relative newbie to OSM), and wish to learn & comprehend.
Mundilfari (2021-09-03 19:12:56+00:00): @Lee Carré: Trying to filter these change sets out is kind of trying to tackle the issue when it's already too late (and so is complaining in the comments once these happened). Here's a thought:
Essentially, there's three types of big-bbox-changesets
1. beginners not knowing that unrelated changes far apart should be submitted in separate change sets
2. more experienced users who do know that, but create giant change sets by mistake (I just recently created two of these myself -unintentionally- and didn't notice until it was too late)
3. intentionally big change sets that touch a large number of similar features over a large bbox (this change set specifically would be an example that falls into that category).

In my perception, types #1 and #2 account for the majority of the global bbox changes. 

Maybe a better way to deal with the issue would be to have the editors (most importantly id and josm, I guess) display warnings when modifying a feature in the editor (not when committing the changeset, but the moment you touch the feature). The warning could be something like "You are about to modify an object that is more than x miles/kilometers away from all the changes you've made so far. It is generally preferred to only group geographically close changes in one change set. Please consider uploading your prior changes before continuing". 
One could probably even do multiple escalations - say 1/10/50/250 (tbd) miles apart.

This would hopefully discourage most users from creating type #1 issues, it would likely solve type #2 issues altogether, but would allow the fewer remaining instances of type #3 to still go through.

It doesn't give you 100% of what you want (no global change sets ever) - but the status quo (=complaining about them when it's too late) clearly isn't super effective either. 

"Dismissively directing me to ..." - seriously? The tools may be proofs of concept and may not be perfect or fully feature complete - but I guess they're better than nothing, no?". Interpreting somebody's hint that there are tools that are better than nothing at all as being "dismissive", "disingenuous" and "dishonest"  is certainly an _interesting_ point of view. I guess everybody should pay attention not to tell you about solutions/workarounds that work for them.

Finally, please keep in mind that while your time is certainly precious, that doesn't mean that everybody else's is not (and I'm saying this specifically referring to the type #3 changes I described above).
Some changes are simply done much more efficiently through arm chair mapping (we don't need no survey to see that the surface on a street is "asphalt", not "asphaalt").
Mundilfari (2021-09-03 19:40:36+00:00): I forgot to mention - if you don't like the tools linked above for the fact that they're experimental, maybe the changeset by comparison visualization [1] is an option for you. Also two clicks away from osmcha if you use the smart menu, with no need to enter the changeset id manually or build the url or whatever.
I believe it also lets you bookmark an area of interest as a rss feed which (if I'm looking at it right) only includes the ones that actually changed something in the bookmarked area but excludes anything that has an overlapping bbox without actual changes in the area of interest. Please don't question my intellect for bringing it up though.

[1]
https://resultmaps.neis-one.org/osm-change-viz?c=110409629#1/49/1
Mashin (2021-09-03 21:10:29+00:00): I think Mundilfari here pretty much summed up my opinion on this topic.

But if anybody wants to bring this issue to attention of iD maintainers or propose a solution to type #1 and #2 cases please do so here 
https://github.com/openstreetmap/iD/issues/8590
mmd (2021-09-08 20:35:12+00:00): Changeset discussions are not a great place for any sort of technical discussion, so I'll keep it brief. https://github.com/mmd-osm/Overpass-API#hourglass-performance has a list of performance topics. However, not all of them are relevant to the topic at hand.
Arlo James Barnes (2021-08-31 22:17:01+00:00): Thanks for the edit. It was a subjective tag and therefore inappropriate for OSM, but 'troll tagging' means something different: https://wiki.openstreetmap.org/wiki/trolltag
yrtimiD (2021-09-04 17:42:36+00:00): Hello, may I ask why you downgraded Ben Gurion Avenue from tertiary to residental?
Car162 (2021-09-08 14:23:38+00:00): Because the Ben Gurion Avenue has a dead end without a roundabout.
yrtimiD (2021-09-08 18:42:36+00:00): I never saw a rule in OSM which disallows tertiary road to have a dead end. 
In any case, there is no a dead end but a proper u-turn. 
Additionally, other maps like https://www.govmap.gov.il/?c=185800,659691.48&z=6 do define this appendix with same class as whole street (you can tell this by the fact it's still rendered on a high zoom)
eggie (2021-08-29 12:34:29+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 

MVG, 

Eggie 

Namens de OSM Community
eggie (2021-08-29 12:41:34+00:00): Beste Joviland.. Zou je dan kunnen aangeven wat het dan wel is?

MVG
eggie
Tilia_J (2021-08-29 14:58:41+00:00): Ik had een poos terug hier ook al abusievelijk een grafheuvel toegevoegd. Na discussie en verificatie is deze door mij verwijderd om vervolgens door user Aetiusjp weer te worden toegevoegd.

Dit stuk grasland ligt nét buiten een archeologisch waardevol gebied.
eggie (2021-08-29 15:11:33+00:00): Oke.. duidelijk....
Gr eggie