piebro/osm-data huggingface dataset:
woodpeck_repair (2022-01-17 18:11:26+00:00): This changeset has been reverted fully or in part by changesets 115987058, 116256242, 116201510, 116088865, 115961205, 115909054, 116246495, 116169440, 115907273, 116190493, 116097969, 116215378, 115858878, 116102205, 116089702, 115892693, 116209638, 115858095, 116169906, 115945264, 115997653, 116173151, 116203612, 116159666, 115917562, 116211414, 115940656, 115999487, 116182419, 116231762, 116194866, 115982719, 116163488, 116115731, 115901956, 116100067, 116016301, 116132274, 116138293, 115861170, 115954008, 116036573, 116130633, 115938707, 116111612, 115860184, 116166788, 115891057, 116220349, 116073948, 116076098, 116058603, 115932463, 115854450, 115900071, 116148640, 116048017, 116241969, 116224272, 116171543, 115957131, 116022990, 116080033, 116056361, 115947919, 116233436, 115857162, 115877026, 115850650, 116004641, 116177461, 115929128, 116249159, 116113713, 115896313, 116205510, 115883321, 115915525, 116251678, 115943146, 115866802, 116129806, 116174374, 116192503, 116136374, 116196233, 116086007, 116161599, 115984534, 115950322, 116239965, 116213416, 116142949, 116001023, 115848475, 116133876, 115989603, 116168898, 115894172, 115925419, 116258652, 115927631, 116071930, 115913517, 116086956, 115868585, 115952312, 116179230, 116126682, 116202690, 115958750, 115955551, 116129122, 116009704, 115887413, 116078274, 115920862, 115863779, 115967683, 116200009, 115975730, 115933567, 116094069, 115926630, 115895376, 115899448, 116119946, 116084875, 116092164, 116261057, 116063166, 116150818, 115928494, 116046074, 116232654, 115929587, 116007937, 115963744, 116204711, 115995802, 115969455, 115870684, 115930466, 116198840, 116124815, 116265983, 116031891, 115903472, 116038451, 115881101, 116165161, 116170468, 115889260, 115922240, 116122375, 116004006, 116045119, 115879107, 115963129, 116087727, 115898028, 116180648, 115960252, 115875029, 116049224, 116132972, 115971511, 115900840, 116234692, 116175765, 115930042, 116088329, 116096072, 116020795, 116168000, 115852688, 115966038, 116006521, 115897064, 116235490, 116024970, 116090839, 115862283, 116060792, 116203152, 115930961, 116207912, 115873052, 116227766, 116229157, 116052340, 115978064, 115964730, 116040401, 116109235, 115991758, 116141089, 115897597, 116155392, 116003243, 116034560, 116002436, 116236672, 116054351, 116005404, 116029310, 115898888, 116188418, 116170992, 115855971, 116200856, 116172218, 116144870, 115935050, 116222506, 116184294, 116230562, 116217637, 115936711, 116186305, 115923725, 116244174, 116157650, 116104506, 116117821, 116081696, 115911369, 116050711, 116131458, 115859460, 116206601, 115973628, 116027067, 116234060, 116067530, 115961954, 116226056, 116018438, 116069855, 116065512, 116202141, 116083456, 116046717, 116146732, 116128090, 115905278, 116197629, 116011710, 115931594, 116044045, 115865164, 116106711, 116042591, 116153122, 115885353, 116204137, 116254060, 116047266, 115994107, 115962544, 116134926, 115919393, 116238162, 115898455, 116263538, 115980503, 116013913 where the changeset comment is: revert an undiscussed and buggy building import in (mainly) Baghdad
LySioS (2021-09-15 12:01:01+00:00): Salut,
Bien vu pour le bld Jean Jaurès en D 5b. J'ai remis la partie haute aussi en D 5b car c'est ce qui est indiqué sur le plan IGN et ça correspond au sens de circulation opposé à celui de Jean Jaurès
hoancat (2021-09-15 12:24:42+00:00): Salut,
J'avais fait cet édit par rapport à la signalisation sur place, qui était indiquée sur le boulevard jean jaurès mais rien sur la rue gaston clos. En effet, le plan IGN inclut les deux.
Kovoschiz (2021-09-15 09:34:10+00:00): This is debatable. They are considered separate towers on the podiums. Should be `building=` + `building:min_level=`.
CranaeIsland (2021-09-17 13:52:42+00:00): Hi Kovoschiz, thanks for asking about this. I was following OSM policy for complex buildings and feel that building:part is relevant to this case per the OSM wiki description (https://wiki.openstreetmap.org/wiki/Key:building:part). This is also described on the 3D modeling wiki page https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings. Let me know what you think, thank you!
Kovoschiz (2021-09-20 11:32:30+00:00): Ok let's discussed here. 
First of all, you need to notice that not all "overlapping" towers-on-podium `building=` are highly structurally dependent (although I'm not familiar with this), eg using a transfer plate to transfer the load of the tower to the base's columns. Many towers have columns extending to and directly supported on the ground. Many structures are also simply linked together, but are separate. Here, at least the 2 hotels look more separate (there are some geometry or alignment issues relative to the deck extending over the road).
The page started by " Note that building:part=* are optional areas used in addition to a building=* area. building:part=* areas should be always within a separate building=* area representing the entire building. ". By this factor, the towers are not "optional" to podium structure, but significant and considered independent buildings on their own. 
If this to be a `building:part=`, then you still to harmonize the entire thing: 
1. Change to or create a `building:part=` for the base. 
2. Make a `building=` for the outline, with correct attributes.  
3. Correct `building:levels=` and `building:min_level=` accordingly
CranaeIsland (2021-09-24 06:48:15+00:00): Thank you for your detailed explanations on this. It would be very difficult for me to make the changes on the last 2 points you made with the available Mapillary photos. I know that building:part=* is the optional area but here it is not possible for me to view or understand the “base” from this image as I can not see the min_level. Therefore, it would be inappropriate for me to add building:min_level= tag without all of the information. If this is something you have knowledge of please feel free to update this!
ivanbranco (2021-09-17 16:15:22+00:00): Hi octel,

https://www.openstreetmap.org/relation/1759757/history
you added "마이단와르다그=주" but tags are by convention in English language, can you fix it?
0000FF berries (2021-09-19 20:57:45+00:00): Hi there :) Welcome to OpenStreetMap :) 

Thank you for deleting that node https://www.openstreetmap.org/node/6068681288/history I'm one of the volunteers. If you ever want to ask any questions, you can do so at our forum https://forum.openstreetmap.org/viewforum.php?id=27

Happy mapping :)
快乐的老鼠宝宝 (2021-09-15 05:37:14+00:00): In https://www.openstreetmap.org/changeset/87546877 , a user use Tianditu, which is a copyright protected layer, to draw a part of G302.

The way 823047947 has been deleted and I will re-check this area with current authorized layer such as Maxar, Esri

Best wishes
快乐的老鼠宝宝
ynx (2023-05-09 12:45:40+00:00): Добрый день!
А откуда у вас информация что вот эта парковка - https://www.openstreetmap.org/way/173305019#map=19/54.19184/37.61455 - платная?
Dimacn (2021-09-15 17:11:10+00:00): Пожалуйста не пишите детской площадке название "Детская площадка". Это и так ясно из тега.
Dimacn (2021-09-15 17:12:58+00:00): Тег у детской площадки должен быть leisure=playground, а не парк
literan (2021-09-16 08:55:38+00:00): да и "приклеивать" границы площадки к дорогам не следует. Линии дорог проводятся по их центру, получается, что детская площадка до середины дороги простирается
literan (2021-09-16 08:56:03+00:00): адреска на детских площадках также не нужна. Адреса назначаются зданиям
Mannivu (2021-09-15 12:09:58+00:00): Perché hai inserito in un multipoligono tutti i farmland? Non hanno nulla in comune, se non l'essere campi. Non ha senso fare un multipoligono per dei campi coltivati.
morsi (2021-09-16 14:59:35+00:00): Se non hanno nulla in comune perchè hanno tutti lo stesso tag? Perchè non ha senso fare un multipoligono dei campi coltivati?
ivanbranco (2021-09-16 15:44:03+00:00): Hanno in comune lo stesso tag perché sono tutti campi coltivati ovviamente. Ma ha ragione Mannivu, le relazioni non sono categorie: https://wiki.openstreetmap.org/wiki/Relations_are_not_categories

Un multipoligono si usa quando c'è un inner (un "buco" in un edificio, un isola all'interno di un lago ecc.).
Mannivu (2021-09-16 15:51:50+00:00): Come dice Ivanbranco, il multipolygon ha senso se l'area da costruire utilizza più di un segmento, ma in questo caso l'area di ciascun campo è creata da un segmento solo. Ci fosse stato all'interno un laghetto, una pozza o simili avrei capito, ma così è insensato
morsi (2021-09-17 05:45:56+00:00): E se due aree con due tag diversi hanno un lato sovrapposto? Come vi comportate?
ivanbranco (2021-09-17 06:28:02+00:00): Ciao morsi,

non mi risulta questa casistica costituisca alcun tipo di problema per i dati.
Mannivu (2021-09-17 11:37:08+00:00): Esattamente come hai fatto per il grosso campo coltivato a EST che condivide i confini con l'area residenziale: si crea un multipoligono. In quel caso è corretto.
SomeoneElse_Revert (2022-03-01 18:42:57+00:00): This changeset has been reverted fully or in part by changesets 117961003, 117970393, 117965218, 117980733 where the changeset comment is: Following a complaint about invalid edits, and a lack of decent reply (see https://resultmaps.neis-one.org/osm-discussion-comments?uid=414659 , https://www.openstreetmap.org/user/Max_Kritic/blocks ) reverting changesets where _only_ osmose was used.
tordans (2021-09-15 05:49:58+00:00): https://www.mapillary.com/app/?pKey=861080137832630, https://www.mapillary.com/app/?pKey=440219697363302
user_5359 (2021-09-15 14:25:14+00:00): Hello! Please use the osm key building instead of buildings!
dhaird (2021-09-15 06:23:26+00:00): Adding the source as "Driver feedback" for further clarification.
Supaplex030 (2021-09-16 07:21:39+00:00): Solche Situationen meinte ich bei meinem anderen Changeset-Kommentar mit "kann zu sehr ungünstigen Routing-Situationen führen"... Stell dir vor, wie das Fußgänger-Routing aussieht, wenn du von der Richard- durch die Zeitzer Straße willst ;) So sollte es mMn auf keinen Fall bleiben, denn für die allermeisten User ist eine Querung ja möglich bzw. sie würden diese dort auch tun. Statt dessen sollten wir uns ein eindeutigeres Tagging für solche Situationen überlegen – also falls "barrier=parking_lane" nicht ausreichend erscheint – sowas wie "informal=yes" oder "wheelchair=no" oder so...
tordans (2021-09-16 08:27:51+00:00): Ja, das dachte ich mir.
Ich sehe das aber anders. 

Ich setze es mal auf unsere Agenda für nächste Woche https://wiki.openstreetmap.org/wiki/Talk:Berlin/Verkehrswende/Meetup_2021-09-21. Das ist einfacher zu besprechen im Meetup. Folgend aber schonmal meine Gedanken:

Wenn die bauliche Situation keine Querung vorsieht, sollten wir keine mappen.

Kriterien sind für mich: Abgesenkter Bordstein und/oder Markierungen der Querung durch Farbe, Poller, Schilder.

Wenn wir einfach jede Kreuzung mappen, auch wenn kein Kriterium zutrifft, können wir auch einfach alle 200 Meter auf jedem Straßenabschnitt eine Querung mappen, denn für diese gelten die gleichen Regeln: Bestimmte Menschen können da durch. Und für die Router ist es besser.

Analogie: Wir mappen nicht jede Ausfahrt, wo ein Tor ist, sondern nur, wenn mehrere Kriterien zutreffen.

Analogie: Das ist das gleiche für mich wie U-Turns für Autos. Ich kann in vielen Wohnstraßen mein Auto drehen; das mappen wir aber nicht. Entsprechend wird der Router auch immer einen Umweg vorschlagen. Als Fahrer mache ich dann trotzdem eine Drehung und der Router passt sich daraufhin an.

Es ist für mich eine Frage, was das Minimum eines Gehwegübergangs ist. Es ist für mich nicht "es muss ein/e schlank gebaute/r Erwachsene/r (zwischen Autos schlängeln) mit gutem Schuhwerk (holpriges Terrain durch Bordstein und Co) und eine Mindestgröße von 1,x (sonst kann man die Straße zwischen den Autos nicht einsehen) durchkommen".

Dass das beim Routing zu längeren Strecken führt, macht nur sichtbar, dass die Infrastruktur schlecht ist.

Diese Betrachtungsweise ist natürlich stark auf Großstadt/Berlin gemünzt, wo ich weiß, dass jeder nicht geschützter Übergang auch nicht zu nutzen ist. Wenn wir über Gehweg-Mapping in einem dörflichen Wohngebiet sprechen, würde ich meine Kriterien-Liste oben vermutlich anders formulieren.

Aber solange wir in der Community noch keinen etablierten Konsens haben (damit meine ich, dass Router ein bestimmtes Tagging supporten), wie mit solchen Kreuzungen in einer zugeparkten Stadt wie Berlin umgehen wollen, sollten wir sie IMO nicht "regulär" eintragen. Das führt zu absehbarem Fehl-Routing.

Ich sehe also drei Optionen

a1) An Kreuzungen an jedem Knoten eine Querung eintragen + "barriere Autos", wenn vorhanden. Router werden diese Route (bis auf weiteres) immer mit anzeigen ohne Warnung.

a2) Einen barrier-tag verwenden, den Router verstehen. Dann wird die Route nie verwendet, aber visuell angezeigt.

a3) Access-Tags wie von dir vorgeschlagen anhängen. Dann würden bestimmte Router die Auswerten; der Default wird aber sein, die Querung im Routing zu verwehen (wie a1).

b) An Kreuzungen nur die Querungen eintragen, die auch rechtlich als solche gedacht sind (siehe meine Kriterien oben). Router zeigen dann längere routes.

c) Die Querungen, von denen wir wissen, dass sie nicht funktionieren eintragen, aber mit sowas wie lifecycle-tags. Bspw. "blocked:highway=footway + blocked: footway=crossing".
Damit können wir den Community-Prozess weiter treiben und auf Beispiele referenzieren ohne, dass die Router Fehlinformationen liefern.
Supaplex030 (2021-09-16 14:05:50+00:00): Ja, das ist ein gutes Thema fürs nächste Treffen! (Ist darüber hinaus aber auch eine Grundsatzfrage für die gesamte OSM-Community – aber wir leisten ja nicht nur hier "Pionierarbeit" sodass eine Richtschnur unter uns schonmal sehr wertvoll ist ;)
Mateusz Konieczny (2024-02-20 10:29:13+00:00): Hello! https://www.openstreetmap.org/node/5621288583/history has 2=construction key that was added in this edit (if I checked things correctly)
What you intended to express by using this unusual key? Is this tag needed? Or maybe can it be expressed in a more typical way that would be easier to understand?
KhoraKavat (2024-02-20 22:27:46+00:00): Hi. This is definitely a mistake. The tag was added in 2021, I was just starting to edit then. Thanks so much for showing me that! I've corrected the error.
Mateusz Konieczny (2024-02-21 09:16:01+00:00): Thanks for fixing!
Kovoschiz (2021-09-15 09:38:39+00:00): This was discussed in https://www.openstreetmap.org/changeset/110835972, and raised in a separate case with your team in https://www.openstreetmap.org/changeset/111223568
Kirkepladsen (2021-09-17 13:04:21+00:00): Hi Kovoschiz, thanks for linking those two changesets. Can you please explain why this would be a separate building instead of a building part? It seems like this scenario as well as the one that you sent to my colleague are in-line with what we expect a building:part to be according to the OSM wiki  (https://wiki.openstreetmap.org/wiki/Key:building:part). Happy to discuss further to come to an agreement!
ualios (2021-09-20 10:35:10+00:00): Ciao, ma che senso ha mappare trunk 3km su 7km della tangenziale Est e 5km su 14km di una sezione di SS87 (tra l'altro in presenza di una attività privata con accesso non conforme a trunk)? Di questo passo la mappa si popolerebbe di tratti trunk in maniera del tutto incoerente con le caratteristiche di base di un'arteria stradale.
Fra00 (2021-09-20 10:47:22+00:00): Beh, di certo quel tratto risponde ai criteri per i trunk. Non tutta la lunghezza di una strada deve essere taggata allo stesso modo, e questo è un caposaldo della mappatura in OSM. L'unico accesso a una proprietà privata è comunque con divieto di attraversamento con doppia linea continua e, come dicesti tu, un unico accesso in 8 km non osta di certo al tag trunk. Detto questo, se vuoi riportare a primary fa' come vuoi, ma, ti ripeto, la mappatura in differenti tag di un unica strada è la norma su OSM (per questo, ad esempio, non mettiamo i tag highway sulle relazioni stradali, poiché ogni tratto potrebbe avere caratteristiche differenti).
ualios (2021-09-20 16:25:10+00:00): Che la differente mappatura di una stessa strada in OSM sia la norma ho qualche dubbio, ma ovviamente il problema non è quello. Quello che invece mi pare strano è che un piccolo tratto di strada diventi improvvisamente trunk solo perché privo di incroci a raso e accessi non a norma. Può bastare perchè 5+3km ci sembrano comunque abbastanza? Andrebbero bene anche tratti di 4km oppure 2km? C'è scritto qualcosa nelle linee guida?. 
Eppure la caratteristica della strada (anche al netto delle eccezioni) rimane la stessa, stessa rilevanza, fondo, corsie, velocità mediamente bassa e quindi pericolosità. Con lo stesso criterio si potrebbero taggare diversi trunk su innumerevoli strade primarie e ne uscirebbe fuori una mappa caotica, arbitraria e fuorviante per chi la legge.Eppure la caratteristica della strada (anche al netto delle eccezioni) rimane la stessa, stessa rilevanza, fondo, corsie, velocità mediamente bassa e quindi pericolosità. Con lo stesso criterio si potrebbero taggare diversi trunk su innumerevoli strade primarie e ne uscirebbe fuori una mappa caotica, arbitraria e fuorviante per chi la legge.
Fra00 (2021-09-20 18:39:02+00:00): Sul primo punto non puoi avere dubbi, è così: una strada intesa come arteria portante lo stesso nome o facente parte della stessa classificazione non deve essere taggata allo stesso modo nella sua interezza. Una strada statale può in alcuni tratti essere trunk (quando rispecchia determinate caratteristiche), in altri primary (da standard), in altri secondary (quando, ad esempio, vi è una strada di nuova costruzione in variante). Per quanto riguarda il tratto in questione ho spiegato i motivi della mia modifica e, anzi, ero abbastanza convinto che la situazione con le strade molisane di nuova costruzione (o adeguamento) come trunk fosse abbastanza buona, forse migliore di quella attuale con solo primary, date le diversissime caratteristiche tra le diverse statali. Il fatto che una strada con una corsia per senso di marcia sia classificata trunk o altro dipende esclusivamente da caratteristiche fisiche, non di classificazione, per lo standard usato in Italia. Questo tratto rispecchia appieno i parametri, come altri che sono stati ritaggati come primary, altri invece solo in parte (per questo non era comunque un'idea assurda quella di taggarli come trunk). Non vi è un minimo di lunghezza, se un tratto rispecchia le caratteristiche può essere trunk, ma, ovviamente, usando sempre una grande dose di buon senso.
ualios (2021-09-21 08:06:21+00:00): Che il primo punto sia consentito, in qualche caso doveroso, è indubbio, però non è la norma, tutto qui, basta scorrere la mappa per rendersene conto.
Per il resto, ci si richiama sempre alle linee guida ma poi ognuno fa un po' come gli pare. 
Per me l'importante è dare informazioni più chiare (o meno equivoche) possibile. Ora chi legge la mappa e improvvisamente vede la strada che hai mappato diventare improvvisamente trunk cosa può pensare? Maggiore rilevanza del tratto stradale? Corsie più ampie? Aumento velocità consentita? Tratto progettato con standard di sicurezza più elevati? Niente di tutto questo, solo il fatto che incidentalmente in quel breve tratto non ci sono (quasi) accessi laterali diretti, il che rappresenta una casualità, e non una caratteristica intrinseca del tratto stradale. Con questo ragionamento, ripeto, si moltiplicherebbero i tratti trunk su strade di "primaria" importanza generando altrettanti equivoci e non rendendo nemmeno giustizia al rendering (ti prego non mi dire che non si mappa per il rendering).
Fra00 (2021-09-21 08:22:22+00:00): Parto dalla fine: "non si mappa per il rendering" è un altro concetto fondamentale. Per tornare alla questione principale, ti ripeto che a mio avviso tutta la strada poteva essere taggata come trunk, tranne i tratti con grandi incroci a raso e senza obbligo di svolta a destra per le immissioni (comunque molto minori). Se proprio vuoi taggare per il rendering allora riporta tutte le strade a trunk, così un lettore della mappa si rende conto che queste strade sono effettivamente a scorrimento veloce, seppur con alcuni ingressi/uscite senza corsie di accelerazione, ma, sempre e comunque, senza incroci a raso che tagliano la linea di mezzeria.
ualios (2021-09-21 09:56:16+00:00): Curioso, appena un mese fa eri proprio tu che mi sollecitavi a ritaggare primary tutta la Bifernina perché non aveva le caratteristiche di trunk!
Ma io stesso ho dovuto prendere atto che taggare quella strada trunk, così come la tangenziale est o la porzione di ss87 a servizio del capoluogo, per quanto di rilevanza regionale, avrebbe fatto perdere il dato ben più importante, e cioè che nella sostanza rimangono strade prive dei requisiti di sicurezza e di scorrevolezza delle strade di categoria superiore. E qui, purtroppo, non c'è rendering che tenga!
A proposito degli incroci a raso, suggerirei di ritaggare a primary questa rotatoria con tutta la rampa B di accesso. Più coerente e anche Josm sembra d'accordo.
https://www.openstreetmap.org/way/367259082
Fra00 (2021-09-21 10:03:05+00:00): Ti ripeto che se riporti il tag a primary me ne faccio una ragione. Per quanto riguarda quella rotatoria, trattasi di una rampa in tutti i sensi, anche in classificazione ANAS, non è per niente una primary.
Fra00 (2021-09-21 10:07:11+00:00): PS: per fortuna JOSM non opera da solo, ma si appoggia su utenti umani che possono discernere le situazioni in maniera più accurata.
ualios (2021-09-21 10:37:07+00:00): Josm effettua controlli che aiutano a mappare più coerentemente, te lo consiglio. E ci dice pure che un umano aveva già provato a correggere allo stesso modo ma evidentemente non te ne sei fatto una ragione.
Fra00 (2021-09-21 10:40:00+00:00): Spiegami il motivo per cui sarebbe coerente. Sono strade chiamate "rampe" ufficialmente e la loro unica funzione è quella di unire un trunk a strade minori: definizione da manuale di "trunk_link".
ualios (2021-09-21 11:12:57+00:00): Perchè un link di norma non termina su un altro link, soprattutto quando sono tutti trunk e il trunk_link centrale è una rotatoria e quindi un incrocio a raso.
Fra00 (2021-09-21 11:16:55+00:00): È pieno di link che hanno incroci al loro interno, questo non è di certo un caso unico. Vi è una linea guida in proposito? Ah, giusto per aiutarmi a capire, in quale modo JOSM segnala queste modifiche consigliate?
Fra00 (2021-09-21 11:35:22+00:00): Ho trovato questo, ma non so bene come interpretarlo: "_link tags should also be used [...] in roundabout designs that physically separate a specific turn from the main roundabout" (https://wiki.openstreetmap.org/wiki/Highway_link). In questo caso vi sono una rotatoria (quella taggata trunk_link) che separa le entrate/uscite da un trunk e la rotatoria principale (quella primary); mi sembra il caso descritto nella wiki.
ualios (2021-09-21 17:29:49+00:00): In questo caso Josm segnala che "lo svincolo stradale non è collegato ad una strada/svincolo adeguato" e che la rotatoria da trunk_link dovrebbe essere trunk. Anche modificando rimane però la segnalazione degli svincoli non adeguati. Il problema sembrerebbero proprio i link che portano ad altri link.
Cambiando la rotatoria in primary oppure tutto (rotatoria e link) in trunk la segnalazione scompare. Sinceramente il quadro non mi è del tutto chiaro e probabilmente c'entra poco con la nostra questione che però a mio avviso rimane. Se è vero infatti che un highway_link ha le stesse caratteristiche della highway principale di collegamento allora una rotatoria trunk_link è ugualmente problematica, soprattutto laddove non rappresenta, ad esempio, una semplice inversione di marcia, ma un vero e proprio incrocio a raso.