piebro/osm-data huggingface dataset:
naoliv (2017-12-15 11:16:29+00:00): Hello, NeahRenee.
On multiple occasions you have modified this way https://www.openstreetmap.org/way/76730141 sometimes with changes that were not very correct.
Maybe you have some doubts about editing or representing something on the map?
SomeoneElse_Revert (2017-11-05 04:47:31+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
JJIglesias (2017-10-26 22:14:04+00:00): Si hay algo repetido hay q verificar cual tiene claramente mas informacion y que datos o proyectos respresentan todos los marcados como #POBLACIONESBOLIVIA NO PUEDEN SER BORRADOS, pero SI pueden ser colocados en una posicion mas exacta si fuera el caso.
Gracias
SomeoneElse_Revert (2017-11-05 04:47:33+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
M!dgardAutomated (2017-10-26 15:03:11+00:00): This changeset reverts some or all edits made in changeset .
M!dgardAutomated (2017-10-26 15:06:08+00:00): This changeset reverts some or all edits made in changesets 53133758, 53150516, 53159147, 53159181, 53182750, 53182906, 53183087, 53183232, 53183285, 53183350, 53183425, 53183523, 53185333, 53185463, 53185508, 53185623, 53185689, 53186050, 53186286, 53186346, 53186414, 53186488, 53211841, 53212303, 53213907, 53213984, 53214309, 53214412, 53215131, 53215173, 53215215.
SomeoneElse_Revert (2017-11-05 04:47:19+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
SomeoneElse_Revert (2017-11-05 04:47:20+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
JJIglesias (2017-10-26 22:43:57+00:00): Gracias por editar en #OSM_BO
SomeoneElse_Revert (2017-11-05 04:47:16+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
SomeoneElse_Revert (2017-11-05 04:47:24+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
DaveF (2017-10-26 18:44:07+00:00): I'm intrigued what is/are "Array positions - Bats".

Tags need to be added to the way if is to make sense.
SomeoneElse_Revert (2017-11-05 04:47:12+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
Polarbear (2017-11-02 11:54:28+00:00): Streichung "natural=sand"
Warum entfernst du den Sand aus dem Sandkasten?
geozeisig (2017-11-02 16:28:09+00:00): natural=sand vertägt sich nicht mit leisure =playground. Man könnte surface= benutzen, ist aber auch nicht wirklich besser. Anders augedrückt ein Spielplatz wird in grün gerendert und nicht gelb.
Polarbear (2017-11-03 01:23:28+00:00): 1.
Wenn dir die Farben bei bestimmten Tag-Kombinationen in einem bestimmten Renderer nicht gefallen, dann mach bitte ein Ticket auf Carto auf, und lösche keine Daten. Der playground-Tag war ja da, also steht in der Datenbank, dass es ein Spielplatz ist. Wir taggen nicht, um eine bestimmte Farbe zu pinseln. 
2. 
Was heisst, die Tags "vertragen" sich nicht? Das eine beschreibt die Nutzung, das andere das Material.
3.
Sand ist natürlich. Ob hier Mutterboden abgetragen wurde und die eiszeitliche Streusandbüchse hervortritt, oder der Sand aufgeschüttet wurde, ist dabei sekundär. Ganze Badestrände werden aufgeschüttet. Insofern halte ich natural=sand für sinnvoll, siehe Wiki mit dem Beispiel der Sandflächen auf Golfplätzen.
4. 
Warum ist surface= auch ungeeignet?
geozeisig (2017-11-03 08:07:11+00:00): In OSM gilt One feature, one OSM element.
Vielleicht ist der tag playground:sandpit=yes hier die richtige Eigenschaft die man hinzufügen kann.
Polarbear (2017-11-16 23:50:42+00:00): Nein, playground:sandpit=yes bezeichnet, dass es innerhalb der Fläche einen Sandkasten gibt, nicht dass die Fläche selbst der Sandkasten ist. 
Da aber laut DOP 2017 dieser langsam zuwuchert, können wir bis zum nächsten Subbotnik das Tagging lassen wie es jetzt ist.
Harald Hartmann (2017-11-05 09:17:03+00:00): Hello Tama Louisius. Why do you tagged `layer=1`? Is it a bridge? And what is the so far unkown and undocumented key `actionoif/oef` for?
SomeoneElse_Revert (2017-11-05 04:47:15+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
pitscheplatsch (2017-10-27 12:18:01+00:00): Hi Annie C Mar, welcome to OSM. You're new to the project and you created almost 102,000 map changes within 24h. Most of the data looks like an import. Could you describe your contributions? Thanks.
radha_madanu (2019-04-16 04:21:07+00:00): Hi  Irwan,

Trust you are well. While reviewing the road network in Bandung, I have come across way 535666450  classified as 'Unclassified'. However, going by the aerial imagery and other ways around,we don't find any connectivity.
Please look into this and share your observations


Thanks in advance.
irwan hidayatullah (2019-04-24 04:06:12+00:00): Hi @radha_madanu
I have come back to this area. For me, some unclassified road around it should be residential road, because it connect the community and way 535666450 should be connect to trunk road

Thanks
SomeoneElse_Revert (2017-11-05 04:47:34+00:00): This changeset has been reverted fully or in part by changeset 53501753 where the changeset comment is: Reverting some imported or semi-imported buildings including many overlaps in Zambia.  An attempt to contact the mapper failed and communication via someone that appears to be the project co-ordinator also failed
yzal (2017-10-27 13:27:17+00:00): I am looking at bing maps and the road is not there. So how do you know the footway and road are connected?  Whats the real source of your edit?
ratrun (2017-10-27 16:30:07+00:00): The node was such close to the footway that OSMI (http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Routing) detected an error. Now I set "noexit=yes" with "fixme=check".
kayle (2017-10-30 07:22:43+00:00): My fault, bad tagging. :(
Road is not connected to footway
https://www.mapillary.com/map/im/iIv2VH3kajpL4Yy0Oa8lEw
gurglypipe (2017-10-26 16:32:13+00:00): The cycle path (non-segregated pavement on the west side) on the A591 needs some work still. Needs a re-survey to work out which bits are cycle path and which bits are foot-only, and whether any of it is NCN6 any more. Probably best to move it into a separate way and set sidewalk=separate on the A591.
lakedistrict (2017-10-26 17:37:25+00:00): NCN6 has been completely rerouted through Bowness and the western shore; I surveyed the new route last year. Another user deleted much of the original route along the A591 when it was moved, so there are just a few sections of cycleway left on the map now, although it all still exists as a cycleway irl, just not part of NCN6 anymore. 

The pavement is a shared cycle and footway from the Calgarth Park junction until just before the Langdale Chase Hotel. Going southbound, there are also some sections of cyclelanes painted on the road.
gurglypipe (2017-10-27 13:18:42+00:00): When was it re-routed? Are these Mapillary images still relevant? https://www.mapillary.com/app/?lat=54.39510819999998&lng=-2.9230128000000377&z=17&pKey=tFVjjGT7imBo538aI65P_Q&focus=photo

Sounds like the cycle lane needs to be reinstated on the A591 (but not as part of the NCN6 relation). I’d probably do it as a separate cycleway way since it diverges from the road a bit by Brockholes, and that would keep it consistent with the cycleway between Ings and Windermere.

For the moment, this is all left as a fixme tag on the remaining bit of cycleway, so I don’t forget about it.
lakedistrict (2017-10-27 16:55:11+00:00): It was rerouted last year (http://www.openstreetmap.org/note/584690), the current NCN6 relation is up to date (http://www.openstreetmap.org/#map=12/54.3880/-2.9464&layers=C). Nothing's really changed since those Mapillary images were taken so they're good to use.
lakedistrict (2018-04-15 16:31:37+00:00): Cycle path reinstated in https://www.openstreetmap.org/changeset/58114194
transilien_cartocite (2017-11-03 08:44:28+00:00): Hi Zverik.
We are looking after railway stations data on behalf of SNCF, the french railway company.

You removed most of the members of the stop_area "Gare de Lyon". These relations are being used to extract the data so for now we need to keep the station infrastructure, equipments and services within the relation. I'll put them back if you don't mind, however I'm curious to understand why you removed them.

Regards,
Antoine.
Zverik (2017-11-03 09:31:19+00:00): Hi Antoine,

You have been using a stop_area type wrong. That type of relation was made to group elements relevant to transit data: stops, platforms, entrances, stations. Not to group everything in sight, from footways to shops and information signs.

For your use case, the type of relation is "site": https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site . Using it will make it less likely to be changed because it doesn't fit some software that has certain expectations about stop_areas.

I have modified the relations, because stop_areas should not contain railway tracks. There is nothing on that on the corresponding wiki page, and having tracks in a stop_area makes it very hard to process and validate.

Is it okay if I change type=public_transport + public_transport=stop_area to just type=site for the railway stations?

Ilya
transilien_cartocite (2017-11-03 15:37:03+00:00): The wiki also says that amenities such as "shelter, bench, bicycle_parking, taxi", are valid in the stop_area relations (https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area#Members). This suggests other facilities such as toilets, tickets offices and so on also make sense : they are useful to travelers.

I take your point that using a site relation might be more appropriate to gather all the things we have in railway stations, including footways for some of them. This Proposal (no vote on it so far is it ?) didn't exist at the time and it may well be a good option for us. We need to evaluate what this implies though, in terms of adapting our procedures to use the data.

In the meantime I suggest putting back the stuff into Gare de Lyon (except railways tracks). It is unfortunate you also changed data in Genova in the same changeset, this stops me from doing a revert : I'll put the data back if that's okay for now. 

Let's keep in touch for further changes (please use transilien 'at' cartocite.fr). 

Cheers,
Antoine.
Zverik (2017-11-03 16:16:03+00:00): Okay, I am reverting the four railway stations I've modified, but also changing the relations' type to "site". I believe you are relying on relation identifiers, so this should not break anything.
transilien_cartocite (2017-11-03 17:24:06+00:00): Thanks for that. This should be okay however I'll double check. Does that mean you'll produce new stop_area relations forthose stations ?
Zverik (2017-11-03 17:52:42+00:00): Yes, I have already done that.
transilien_cartocite (2017-11-08 16:52:03+00:00): Hi Zverik.
I'm coming back to you as it turns out that your change broke several applications in SNCF. We are handling 385 railway stations and migrating them all to Site relations needs to be carefully thought and planned. How urgent is it for you to 'lighten' those stop_area relations ?  Do you mind if we revert back your changes for a couple of weeks, which would enable us to check with the community that using Site relations is the way to go. I'm concerned that this proposal has not been voted for, and on the impact on Nominatim : there will be two stations for each station name (ie. searching for "Gare de Lyon" will produce 2 results).
Are you okay if we put back all that "stuff" in the 5 stop_area relations ?
Antoine.
Zverik (2017-11-08 19:53:47+00:00): Sorry, I don't understand your process. Nominatim does not use any relations: it returns only nodes and ways for railway stations. Regardless of relation types, you won't get neither "stop_area", nor "site" from it.

Depending on OpenStreetMap in this way, but storing hundreds of overweight relations and hoping nobody touches them, is a way to failure. If not me, then somebody else would fix these relations. I'd suggest you redo the entire process, untying your system from specific collections and using spatial relationships instead. But of course that takes a lot of time.

Proposals don't have to be voted on to take effect. Wiki in general has a little say over OSM data. Site relations has been used for more than ten years, and now there are half a million of these in the database.

How do you reference these relations from your system? If by identifiers, they have stayed the same. If you download a raw planet data and filter relations based on tags, you'll see a great change over the next few weeks.

But I assume you've been using these special tags like "line:SNCF" and that's what broke your app: I didn't remove these tags from new relations. I've just done it: please check how your applications work now.

I'm against reverting relation types, since it breaks virtually every practical application except yours. But I'm willing to find a solution that benefits both your company, my station parser and OpenStreetMap mapping in general.

Ilya
transilien_cartocite (2017-11-09 10:08:04+00:00): Hi again.
(The point with Nominatim was not about our process but a general concern with the possible impact.)

The stop_area wiki is rather blur on what fits into a stop_area : the table listing the possible members includes amenity=* and gives as examples bench, taxi, parking... 
I saw your Metro mapping proposal, which proposes to only keep platform, stop et entrance members. Fair enough, however you went ahead with editing the data without waiting for the vote which is not so fair...

We are extracting the data based on the stop_area relations, based on the uic_ref tag (not line:SNCF tag). You claim these relations break "virtually every practical application" expects ours. I'd say the opposite : these relations have been there for a while and broke your station parser when you started to include them. What exactly did they break ? It seems the rails were the initial issue, right ? I propose a compromise : in the short term we only remove the rails from the stop_area relations, which gives us time to work on another solution involving site relations, to extract the rest of the data. What about that ?
Cheers, Antoine.
Zverik (2017-11-10 20:28:18+00:00): Hi,

I've reverted my changes and then removed railway tracks from the five stop_area relations.

There is another issue with these stop_areas: such relation should have only one station node, while four relations have two or more. In that case the common way is to remove these station nodes from a stop_area and create separate stop_area relations, one for each station, adding there objects that are related to that station. Other object can be shared between the relations.

What I mean is, do you need all the station nodes — for subway, RER and others — to be in the same relations for railway stations, or may I remove them into their own relations?

In the meanwhile, please do come up with a solution not relying on grouping every OSM object (even untagged objects — what do you do with these?!) in a relation. An intermediate option using a site relation is okay, but in general cramming all the objects that are linked only by their geographic position is against OpenStreetMap principles: you can do spatial requests using tags and coordinates instead. It is not much harder, but a magnitude easier to maintain.

My email is ilya@zverev.info if you want any tips on working with the data.

Ilya
majid1359 (2017-10-26 16:38:32+00:00): آخرین تغییرات اعمال شود
literan (2017-10-27 10:19:03+00:00): добрый день! пожалуйста, не надо использовать тег crossing=zebra/pelican/toocan. Это английская классификация переходов, в России такую не применяют. Для нерегулируемых переходов используйте тег crossing=uncontrolled
majid1359 (2017-10-26 16:40:14+00:00): آخرین تغییرات اعمال شود
SomeoneElse (2017-10-26 18:22:25+00:00): Hello and welcome to OpenStreetMap!
I'm not sure how it happened, but some data got added in the middle of the Atlantic Ocean here.
I've deleted it.
Best Regards,
Andy
SomeoneElse (2017-10-26 18:23:12+00:00): Bonjour et bienvenue sur OpenStreetMap!
Je ne sais pas comment c'est arrivé, mais certaines données ont été ajoutées à l'océan Atlantique ici.
Je l'ai supprimé.
Meilleures salutations,
Andy
Martin Borsje (2017-11-06 20:07:31+00:00): Is dit een permanente afsluiting? En zo ja: voor alle bestuurders/verkeer? Je hebt niets aangegeven en volgens mij is er geen (permamente) afsluiting?
Twotert (2018-09-26 07:33:10+00:00): Het is een permanente afsluiting voor het sluipverkeer tegen te gaan. Deze afsluiting geld voor gemotorischeerd verkeer; uitgezonderd afvalophaaldiensten en hulpdiensten.
Twotert (2018-12-15 18:13:27+00:00): https://www.limburger.nl/cnt/dmf20181202_00082679/nieuwe-maatregelen-verkeer-ulestraten De barrière is weer opgeheven.
b-jazz (2017-10-27 03:20:22+00:00): Why was way 5343133 deleted exactly? It didn't quite line up with the sat imagery, but it was close enough that it should be left IMO. Some of your deleted ways were clearly bogus and should be deleted, but some seem like they could have been left. As someone that has been lost on logging roads, I'd rather have something slightly off than completely deleted.
JJIglesias (2017-10-29 23:54:22+00:00): Thanks for editing at #OSM-BO
Hjart (2017-10-26 17:28:23+00:00): Bemærk venligst at mosen her i forvejen var korrekt tagget og at den ikke er en eng.
Leif Lodahl (2017-10-26 19:17:37+00:00): Du har ret, 
Jeg beklager.
naoliv (2017-11-13 02:39:37+00:00): Hi, Jaya.
Construction areas should be used only in areas where something is being built, and not on places where there are buildings (recently built or not).
See https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dconstruction for more info, please.
Nakaner (2017-10-27 11:51:51+00:00): Hallo pirat21,

als Name wird in OpenStreetMap erfasst, was der Name ist, nicht was auf der Karte erscheinen soll. Wenn du meinst, dass der historische Name erfasst werden soll, so sollte dieser als old_name:de=Insterburg erfasst werden, nicht als name:de=<Name> (<alter Name>). Daher möchte ich dich bitten, deine Änderungen rückgängig zu machen oder zu verbessern. Dies gilt auch für vergleichbare Änderungen, die du in vorhergehenden Änderungssätzen getätigt hast.

Siehe dazu auch https://wiki.openstreetmap.org/wiki/DE:Names und https://wiki.openstreetmap.org/wiki/DE:Taggen_f%C3%BCr_den_Renderer

Zudem möchte ich dich bitten, außerhalb des deutschen Sprachgebiets in Änderungssatzkommentaren (die die man beim Hochladen eingibt) entweder die Landessprache oder Englisch zu verwenden.

Viele Grüße

Michael
literan (2017-10-27 10:31:11+00:00): entrance=7 - это неправильно. Корректный тег для подъезда №7: entrance=staircase+ref=7. Тогда он будет показываться на рендерах.
apm-wa (2018-10-14 08:48:24+00:00): A consulate is not an embassy.  I am changing all amenity=embassy tags to amenity=consulate in Istanbul.  The embassies are in Ankara, the capital of Turkey.
johanemilsson (2018-10-17 09:23:15+00:00): Hi! I'm on the clear that a consulate is not an embassy. Most use the tag diplomatic=* to indicate which type diplomatic mission it is.

https://wiki.openstreetmap.org/wiki/Key:diplomatic

/Johan
apm-wa (2018-10-17 10:44:03+00:00): Nevertheless, amenity=consulate is correct and amenity=embassy is not.  I’ve been a diplomat for over three decades and have served in a consulate as well as multiple embassies, and had the difference drilled into me. Please refer to the Vienna Convention on Consular Relations, which is the international treaty on consulates and consular affairs.
naoliv (2017-10-28 16:24:37+00:00): Bom, aparentemente teve vários casos em que o nó foi movido pra via.
Infelizmente ficaram incorretos após isso (como expliquei nos outros comentários).
Vou reverter estar edições posteriormente, OK?
naoliv (2017-10-28 16:33:32+00:00): Para deixar mais claro, ficaram incorretas as que possuíam relações de enforcement e que se aplicam a vias de mão dupla.
Fidelis Assis (2017-10-28 22:42:15+00:00): OK, obrigado pelo aviso. Esses de relações passaram despercebidos. Vou melhorar meu programa de extração de pontos de alerta para identificar corretamente os casos que não fazem parte de relações.
Fidelis Assis (2017-10-28 23:28:00+00:00): Antes que você reverta, dá uma olhada com calma. Parece que dos 30 sensores que movi em SP, apenas um ou outro fazia parte de relação. Vou conferir com calma depois.
naoliv (2017-10-28 23:39:00+00:00): Ah, sim. Não quis dizer que vou reverter tudo, mas apenas os afetados.
Deve ter dado uns 4.
Fidelis Assis (2017-10-29 03:49:12+00:00): OK. Consegui identificar. Movi 46 sensores e 45 lombadas em SP e RJ. Dentre os sensores de SP, 11 são devices em relações e foram identificados pelo meu script  por engano. Como é esse processo de reversão? É possível voltar todos os 11 ao que era antes ou preciso mover cada um para o lado?

IDs dos devices movidos:
3156575647
3291761093
3291759620
3291761092
3291759659
3291759619
3291746274
3077513375
3077513376
3137625969
3156575647
Fidelis Assis (2017-10-29 15:53:36+00:00): Reverti os 10 sensores de relação  (repeti um id acima) movidos para a via. Por favor veja se está OK.
naoliv (2017-10-30 10:33:23+00:00): Bom, você já reverteu :-)
Não sei se você fez exatamente desta forma, mas eu selecionaria todos os nós e mandaria reverter os changesets onde eles foram unidos às vias, com a opção de reverter apenas os objetos selecionados (usando o plugin "reverter", igual você utilizou)
E como seria esse seu script? Utiliza o que para encontrar os nós que não estão conectados?