piebro/osm-data huggingface dataset:
iandees (2020-10-11 17:16:57+00:00): Thanks for adding this building! Keep up the good work. The only thing I can suggest is that you look for a better category description of the building. In this case it looks like a house, which has its own category in the editor.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/92307665
SomeoneElse (2021-01-17 00:14:32+00:00): Hello Eoin

I hope you don't mind me asking about something added to OpenStreetMap in October.  https://www.openstreetmap.org/way/857848000 was added with a "source=Google Maps" tag on it. We can't actually use that as a source in OSM because the Google's licence doesn't allow it to be used here. If it's somewhere that you've actually been and are familiar with then "local_knowledge" is a perfectly good source for OSM, so if that's the case (and is also the case for anything else that you might have used the same source tag on) then please let us know.

If not, then we'll have to remove Google-sourced things that you've added to OSM that can't be derived from licence-compatible imagery.

Best Regards,

Andy Townsend, on behalf of OSM's Data Working Group
Own Oh (2021-01-18 11:30:59+00:00): Thanks Andy. Will adjust.
SomeoneElse (2021-01-18 12:30:41+00:00): Thanks
PT-53 (2022-04-18 08:07:08+00:00): Hallo okilimu,
diese beiden Wege
- https://www.openstreetmap.org/way/857848230/history
- https://www.openstreetmap.org/way/28132762/history
haben einen gemeinsamen Knoten aber unterschiedliche layer. Das paßt so nicht.
Schaust Du Dir das nochmal an?
Fragende Grüße

PS:
Gefunden mit keep right:
https://www.keepright.at/report_map.php?schema=95&error=122998045
okilimu (2022-04-18 13:13:08+00:00): Hallo PT-53,
ich habe einige überflüssige layer=1 Tags entfernt, danke für den Hinweis
MatthieuMartin (2021-11-11 17:49:13+00:00): Bonjour,

La balise name=* ne doit pas avoir de nom tout en majuscule.
Voir :
https://wiki.openstreetmap.org/wiki/FR:Bonnes_pratiques#Respectez_les_conventions_d.27.C3.A9criture_pour_l.27attribut_name

Bonne carto!
Cordialement,
sovereign_ch (2020-10-11 17:37:38+00:00): This change isn't discussed with the local mapping community, nor is it sanctioned or approved in the wiki. "railway=site" is used for undefined objects on a _node_ (Betriebsstelle, Dienststation), not in a relation. So please stop semi-automatically changing the specific use (railway=station, railway=halt) to 'railway=site' and restore the stop_area-Relations. Thank you.
Diego Sanguinetti (2020-10-12 15:46:32+00:00): Greetings. Sorry I did not respond in time. Although I assumed this was a minor change. According to the OSM wiki I looked for information on railway = station and public_transport = stop_area.

About railway = station is applied to nodes and buildings. But it is not established that it is in relationships other than buildings. As I see it should not be merged between railway = station and public_transport = stop area, unless part of a role. https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area

So I looked for suggestion railway = site, but as it says it is not a suitable option. So should railway = station be removed in relation to stop area?
Diego Sanguinetti (2020-10-12 15:48:58+00:00): In this change I added the train station role in the stop area instead of combining the labels within the stop area relation.
Diego Sanguinetti (2020-10-12 15:51:27+00:00): This case happened in a similar way with Austria with stop areas that had a different interpretation than the wiki. To avoid confusion, could you explain to me how stop area relations is applied in your country?
Diego Sanguinetti (2020-10-12 15:57:02+00:00): Another point, in the subway of several cities, the stop areas are structured without railway = station. https://wiki.openstreetmap.org/wiki/Metro_Mapping As public transport, such as S-Bahn or U-Bahn, there is a validator in this regard. http://osm-subway.maps.me/index.html What do you think about it or if you found a consensus that explicitly indicates otherwise?
Diego Sanguinetti (2020-10-12 16:05:11+00:00): It wouldn't make sense to argue outside of this changeset, but I have explained every possible detail to justify it. The only detail that explains about railway = station is at https://wiki.openstreetmap.org/wiki/Switzerland:Public_Transport/Railways but it says that it is only for "saving records", when the correct thing would be to add a node of railway = station and enough.
Diego Sanguinetti (2020-10-12 16:06:29+00:00): * I do not speak Swiss language but I assume it is the only accessible wiki page.
Diego Sanguinetti (2020-10-12 16:28:36+00:00): In short, is it okay to remove railway=station in a stop area relation and instead add as a "station" role to a railway=station node? This is the most standard solution applied in other countries and transport networks. There is no point in adding another railway=station in relations when it is already displayed with the node or area with that tag.
Diego Sanguinetti (2020-10-13 15:54:22+00:00): Extra: I created new stop areas for Zurich S-Bahn and add some info in routes. Source: https://www.zvv.ch/zvv-assets/fahrplan/pdf/sbahn.pdf
sovereign_ch (2020-10-13 16:59:15+00:00): I don't understand what exactly the purpose of (mass-)editing an object is, whose function one don't seem to fully understand, but anyway...

First point: you're mass-adding with iD a JOSM-specific tag (public_transport:version=2), which in this case isn't useful, nor required by JOSM. It's pure spam. I didn't notice it was mentioned on the en-wiki, so I rectified this now.

Second point: the stop_area-relation holds the PTv2-stop_position and PTv2-platform elements together. This is however more of a gimmick for software that isn't able to piece the elements together by uic_ref – or in the absence of such data. By original design stop_area should only hold those two element types with appropriate roles (which JOSM assigns automatically).

Third point: someone, at some point felt obviously the need to add the old PTv1-station/halt nodes, to stop_area-relations. While there is absolutely no need, nor function to it, at least it serves as "label node", because it is rendered by most general purpose renderer, while PTv2 elements aren't.

Fourth point: no, it isn't necessary to put 'railway=station/halt' onto a stop_area-relation, but it helps identifying the stop_area as belonging to a railway station or halt. To be more precise: railway=station on a node being a PTv1 abstration, the same tagging on a relation equals a PTv2 abstraction.


Personally I don't see any benefit in removing the station type (railway=station/halt) from the stop_area-relation. It makes the whole concept less useless. The wikidata object or wikipedia article of a railway station logically also applies to the stop_area elements. And technically it isn't correct at all to include the PTv1-node in a stop_area-relation – it's the abstraction of the whole station and by logic the "parent element" of the stop_area elements, and not the other way around.

@datendelphin: any additional thoughts on the topic?
Diego Sanguinetti (2020-10-13 20:44:27+00:00): Ok, I will summarize what you have explained. The railway=site and public_transport:version=2 I discard it to avoid future confusions since they are not explicitly recommended, in this case I apologize. One solution I can think of would be to use the key "train=yes" to indicate that the relationship is for trains. However, for this suggestion that would be to update the OSM wiki to make it more standardized and avoid some "legal loophole" fault of the localization.

What matters and I keep the point is that only the nodes or areas are maintained with railway=station. You yourself indicate that this method occurred years ago (PTv1). Now ID generates a warning when a stop area relationship is added with railway=station, perhaps because of the transition to PTv2.

For the Zurich area, I was correcting relationships that did not have public_transport=stop_area but public_transport=station. Initially I did with JOSM to speed up the procedure ("semi-automatic" as you say but under the concept of "minor fixes from Wikipedia") and then I edit it with ID. I also apply with new places that have no stop area so that the S-Bahn network is a standardized transport system along with other countries in Europe and the world (and using apps like OsmAnd and Maps.me).
Diego Sanguinetti (2020-10-13 20:45:47+00:00): * Sorry is "relation", no relationship. But the concept of this word is similar.
datendelphin (2020-10-14 20:03:56+00:00): Thank you for the explanations. Indeed tagging railway=station on the stop_area seems bad. It duplicates the station and I don't see why this should be handled differently in Switzerland. But the =site is also odd and undocumented. I would rather remove the tag. Train=yes is probably intuitive and unambiguous, but indeed data consumers should be able to figure out what it is from the members.
Thinking about "this article applies to all these elements, and we have a relation, so we can apply it there" is useful, but should not be taken to any extremes. Relations are not there to model real world relationships. It is only there because sometimes, we can not solve something with nodes and ways exclusively. But we strive to use them as seldom as possible. Applying articles only to a station node or area makes sense to me.

sovereign_ch please omit such personal attacks: "whose function one don't seem to fully understand". The public transport topic in OSM has suffered from a decade of strong opinioned people rule lawyering and little compromise. There is no single correct understanding, there is just working with this mess and trying to make a map none the less.
Diego Sanguinetti (2020-10-15 21:20:29+00:00): @datendelphin Thanks for understanding this explanation. It would be interesting to propose new preset in ID to easy create  "stop area" relations with train = yes, bus = yes or tram = yes, to make differences with various types of transport.
Nakaner-repair (2020-11-18 09:01:58+00:00): This changeset has been reverted fully or in part by changeset 94342670 where the changeset comment is: Revert all changesets by user joperle (likely copyright violations becauser user did not prove permission). See comments of changeset 93619337 and user blocks 4181, 4190 for details.
opendcc (2020-10-11 18:29:43+00:00): Hallo,

bitte verwende Bayern DOP80 als Hintergrund. Der hat deutlich weniger Parallaxefehler und ist i.d.R. aktueller. Simbach wurde am 12.06.2020 beflogen, momentan erfolgt die Freigabe der neuen Bayernbilder Schritt für Schritt.
santon (2020-10-12 05:55:43+00:00): Danke für den Hinweis, genau daran habe ich mich gehalten.
Frans S (2020-10-12 13:52:10+00:00): Hello Dolly.  Please keep in mind thant not all round objects are buildings.
A lot of them are enclosures to keep livestock or storage. You can recognize them by the fact that they have a shadow on the inside as well as the outside. Also the color differs.
Best regards
DeBigC (2021-07-25 13:49:33+00:00): @Eoin O'Mahony the parking area here, while this is what it is used for is not formally designated for this. Very probably a tree clump was left here and the tree died or was damaged. The use of it as a parking area is not signposted. I  don't see an issue with representing it as having a capacity, but 10 seems high. I reduced down the size of the area, as you drew it with the roadway included. I also removed the private=access, there is no such private holding over ground that is clearly in the public realm.
ma-rt-in (2020-10-11 17:41:41+00:00): Hallo,
ein zusätzliches motor_vehicle=no bei bestehendem vehicle=no ist überflüssig. Bitte schau dir die Daten ganz an.
Zudem ist der Name 64 hier falsch. Diese Verbindung (Way) hat keinen Namen, die 64 befindet sich bereits im ref.
vg
Nakaner-repair (2020-11-18 08:59:38+00:00): This changeset has been reverted fully or in part by changeset 94342670 where the changeset comment is: Revert all changesets by user joperle (likely copyright violations becauser user did not prove permission). See comments of changeset 93619337 and user blocks 4181, 4190 for details.
Nakaner-repair (2020-11-18 09:01:10+00:00): This changeset has been reverted fully or in part by changeset 94342670 where the changeset comment is: Revert all changesets by user joperle (likely copyright violations becauser user did not prove permission). See comments of changeset 93619337 and user blocks 4181, 4190 for details.
user_10059623 (2020-10-12 14:31:53+00:00): That's called vandalism.
Instead of adding berber and your french language under name: br and name:fr properties, you make native and official names look horrible.
Ahras (2020-10-13 06:27:40+00:00): Dear Osm users,

Following the vandalism that my modifications suffered from our colleague mapper user.  مهدي شينون
I put an end to all my contributions to the cartography of Algeria from today

I am approached by an Algerian government body to promote the Amazigh language on a voluntary basis which I accepted with pleasure

Our goal is to bring together the three languages spoken under the name then each language labeled with its tag
if we remove one of the three languages, some will be frustrated not to have their desired language on the map

I am convinced that the Tamazight language will soon be transcribed into Latin according to the sources I have had from linguists
The Algeria of tomorrow is not built on exclusion, hatred or racism

I wish you all good luck
user_10059623 (2020-10-13 10:25:56+00:00): Algeria has only two languages (Arabic and Berber) not three (french is not a constitutional nor a national language).
The best approach is to name each place according to its native people and then put other languages' names under properties so the user see the name according to its UI language that's all. For example Tizi ouzou and Bejaia names should be written in Berber with latin transcripts and Khenchla and Batna names should be written in Berber with Arabic transcripts.
Putting three languages under one name would make the map just look horrible and unusable.

Thanks,
km2bp (2021-02-28 15:26:34+00:00): https://www.openstreetmap.org/way/158242976#map=19/59.92039/10.82436  This is a fairly recent map change made by you  On Norway Orthophoto 
This building doesn't look like that.  Has it been rebuilt?  Greetings
Tractor (2021-02-28 16:08:38+00:00): Indeed, it doesn't look like that.

I think I only changed the tagging from building=yes + building:type=industrial to building=industrial.

The building has probably been demolished since it was mapped 9 years ago.
km2bp (2021-02-28 16:17:28+00:00): Yes, you are right https://www.openstreetmap.org/way/158242798/history 
You can draw it again
If you want to
Wulfmorn (2021-02-28 16:45:41+00:00): I re-traced it because Tractor is too slow off the mark! ;) Also, I changed it from industrial to commercial. It's a car-dealership.
km2bp (2021-02-28 16:54:13+00:00): Good job. I didn't expect it to be fixed so quickly :-)
Tractor (2021-03-01 05:08:54+00:00): Excellent.
aceman444 (2020-11-23 21:21:16+00:00): Hi, you duplicated the relation https://www.openstreetmap.org/relation/11744035 here. I will remove it, but hopefully the other changes are OK.
datendelphin (2020-10-11 18:16:44+00:00): I don't understand this change. What was outdated? What is railway=site? I can't find any documentation about it.
Diego Sanguinetti (2020-10-12 15:47:08+00:00): See changeset 92307823
pio2_122 (2020-10-11 20:15:39+00:00): Edycja niezgodna z zasadami OSM (https://forum.openstreetmap.org/viewtopic.php?pid=646897#p646897)

Wycofane
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/92309231
jptolosa (2020-10-11 21:49:58+00:00): Hola, revertí esta edición pues le cambiaste el nombre a la comuna completa. Mover las islas de comuna se hace de otra manera, pero me gustaría saber de dónde obtuviste esa información, pues los decretos afirman que pertenece a la comuna de Valparaíso.
eggie (2020-10-11 19:02:20+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht.

Review:  Kennelijk heb je de richting van de 'oneway=yes" omgedraaid. Dat lijkt me niet verkeerd als dat zo is. 
MVG,
Eggie
SamosaBelz (2020-10-11 18:07:37+00:00): Przepraszam za opis zmian. Powinno być "przebudowa drogi gminnej w m. Piotrowice".
Jordi MF (2020-10-18 20:01:52+00:00): Hola Monchet,
Permíteme que te haga una pequeña aclaración sobre el uso de la etiqueta "access". Si usas "access=no", estás indicando que nadie puede pasar por ese camino/senda/carretera. Es decir, es posible que los navegadores GPS entiendan que no es posible transitar por ahí y, por tanto, no permitirán trazar una ruta por ese camino/senda/carretera. Concretar "foot" "bicycle" "motor_vehicle" es suficiente y más correcto. Es más, en una senda o camino se sobreentiende que las personas y las bicicletas pueden pasar, por eso sería mejor conretar si lo vehículos motorizados no puede pasar. En un track se sobreentiende que los vehículos también puden pasar, pero en una senda "path", no.
En resumen, mejor no usar la etiqueta "access" si los diferentes medios de transporte no coinciden en el tipo de acceso.
Saludos.
Jordi MF (2020-10-18 20:05:15+00:00): Perdona que me autocorrija. No es incorrecto lo que has hecho. Las etiquetas específicas de acceso deberían sobreescribir lo que indica la etiqueta "access": https://wiki.openstreetmap.org/wiki/Tag:access=no
Así pues, si los navegadores GPS interpretan bien la información (esto deben hacerlos los programadores de dichos navegadores), no debería haber ningún problema.
Arun Madhavan (2020-10-12 02:43:58+00:00): Hey your mapping is wrong. the School is already mapped well.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/92309909
Erin76 (2020-10-16 07:23:16+00:00): hey Joris, ik weet niet of het zin heeft om deze begraafplaats expliciet de naam "begraafplaats" te geven ;-) Ik zou voorstellen ofwel "Begraafplaats Schellebelle", of anders de naam weglaten.
Jordi MF (2020-10-18 00:09:30+00:00): Hola Monchet,
Abans de res, moltes gràcies per millorar les dades d'OpenStreetMap.
Tanmateix, des de la comunitat d'usauaris hem vist que estàs modificant alguns topònims del Desert de les Palmes i tenim dubtes. Necessitem saber d'on estàs traient la informació que estàs afegint i modificant.
En primer lloc, la toponímia oficial del terme municipal de Benicàssim és valencià, per la qual cosa, l'etiqueta name hauria de ser en valencià (si afegixes l'etiqueta name:es, també cal afegir name:ca).
En segon lloc, el Pla de les Muletes, s'escriuria amb U (Muletes) i no amb O (Moletes) segons el Nomenclàtor Toponímic Valencià. Estaria bé saber d'on traus els topònims per a poder verificar si són correctes.
Moltes gràcies. Salutacions,
Jordi
Ramón N (2020-10-18 06:29:10+00:00): Cierto, corrijo lo del Pla de les Muletes
Los nombres los cojo mayormente del visor sigpac:
http://sigpac.magrama.es/fega/visor/#
Algún nombre he puesto en algún sendero según se les conoce en wikiloc o komoot, si no son los oficiales le agradezco que los corrija.
Tendré en cuenta el resto de consideraciones.
Un saludo
Jordi MF (2020-10-18 18:11:59+00:00): Hola,
Gràcies per l'aclariment. Al llarg del temps hem comprovat que la toponímia valenciana que apareix en l'IGN i, per tant, en la web que hs consultat conté errors. El Nomenclàtor Toponímic Valencià conté la toponímia oficial segons un Decret de la Generalitat (tal com passa el temps, l'IGN va incorporant la informació d'eixe nomenclàtor). A banda d'això, no tenim permís per a utilitzar la informació que apareix en webs com Wikiloc o Komoot. A més, molta gent afegeix noms no oficials en les descripcions d'eixes rutes i, per tant, no ens podem fiar. Si hi ha algun nom no oficial que és utilitzat per la població local, existeix l'etiqueta "loc_name=*" per a afegir eixe tipus de nom.
Amb el teu permís, faré una revisió dels canvis que has fet per si de cas, però ja he vist que n'has corregit alguns.
Moltes gràcies i t'animem a seguir millorant les dades d'OpenStreetMap. Salutacions,
Jordi
Tumanyan (2020-10-14 14:24:34+00:00): Hi Aroche,
why are you not tagging the houses with their respective addresses?
In most countries associatedStreet relations are getting deleted.
Sorry for asking this question, I've just been an OSM "spectator" until very recently.
--Tumanyan
mdelatorre (2020-10-17 04:30:47+00:00): I reviewed your changeset and determined is GOOD.

You can add more information to the node.
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/92310290
LL Sendbearer (2020-10-15 11:06:24+00:00): Dear Hassan,

please stop with childish political edits during war times.

Thank you very much
BCNorwich (2020-10-12 07:02:17+00:00): Hi, Welcome to OpenStreetMap.

I've unjoined the path from the private road at north and south. Then joined footpath 10 where it crosses the private road.

Regards Bernard.
Craig West (2020-10-12 08:46:17+00:00): Thanks; looks good now.
VitalieS (2020-10-11 20:35:48+00:00): Bună, 
Puteți confirma că Blin'OK s-a deschis unde se afla anterior Moki? 
Deasemenea, am adăugat Dammex și Blin'OK ca locații care se află în această clădire care lipsea, puteți să spuneți care e locația lor exactă pe hartă (Dammex la vale de Blin'ON sau invers)?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/92311012
VitalieS (2020-10-11 20:39:23+00:00): Sau de fapt, Dammex se află în vârful scărilor unde anterior era Maroni? 
( https://fastly.4sqi.net/img/general/width960/51407352_WzO1PsLLx1ZkLGXqKp6l11Rj9EdqEJHViDXL9US2ZVo.jpg )
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/92311012
Jrachi (2020-10-12 10:24:12+00:00): Scusa.
Volevi mappare la valle del Po o la pianura Padana?
Dalle righe che hai tracciato non si capisce.
Comunque mi sembrano righe tirate a caso e non un qualcosa di utile.
MitjaJez (2020-10-13 20:51:28+00:00): Padsko nižino seveda. Padska dolina je menda v Zahodnih alpah (točneje Ligurskih alpah), ne?
Razumem, rob nižine še ni oster, a dovolj dober, da je bolje kot nič. Relacija tako velikega geografskega elementa kot je Padska dolina še ni obstajal. Na severu jih bom popravil do relacije 2698607.
Jrachi (2020-10-13 21:59:07+00:00): Padska dolina ima robove, ki niso dobro opredeljeni. Katero metodo uporabljate za določitev ravnice? Višina nadmorske višine? In glede na to, kakšna največja kvota? Katere sisteme hribov vključite / izključite?

"Vidim, rob ravnice še ni oster, a dovolj dober, da je boljši kot nič."
Po mnenju skupnosti osmer ni nič boljšega.

Oprostite tudi odkritosti, toda v kateri šoli ste se naučili teh geografskih pojmov? Padska dolina velja za Alpe in Apenine, ne pa za Ligurske Alpe !!!!! Ste prebrali stran wikipedije, ki ste jo povezali?

Na koncu še opomba o prevodih imena: v angleščini je "Padana Valley", če bi radi postavili Padsko dolino, bi se morali povzpeti po Padski dolini, ki se v provinci Cuneo (medtem ko se vaši črtači ustavijo v Torinu) vzpenja do Pian del Re, kjer tradicionalno najdemo njegove vire.
MitjaJez (2020-10-14 21:05:48+00:00): Alora fa corregere.

Il piano è considerato stabilito sulla base della derivata di altezza (variazione di altezza).

Pianura Padana è Po Valley https://en.wikipedia.org/wiki/Po_Valley (come io scritto in changelog)
(Padska nižina in sloveno)

Questo non è dal:
Valle Po non hai differente nome in inglese https://en.wikipedia.org/wiki/Valle_Po
(Padska dolina in sloveno)
chi è come Lei ha scrito in Alpi (Pian del Re).

Spero di essere stato comprensibile.
ivanbranco (2023-04-08 09:33:36+00:00): Ciao MitjaJez,

so è che una discussione di 2 anni fa ma ti linko una discussione correlata nata sul forum italiano nel caso fossi interessato a parteciparvi: https://community.openstreetmap.org/t/rimozione-elemento/97794

buon mapping
MitjaJez (2023-04-08 20:41:39+00:00): tnx!
Stalker61 (2021-01-31 17:41:47+00:00): Доброго дня. Будьте так любезны пояснить по поводу наличия второго моста?
@Алексей (2021-02-05 09:37:08+00:00): Что конкретно пояснить ? Был мост, построили еще один. на каждом по 2 полосы движения.