piebro/osm-data huggingface dataset:
utack (2016-04-10 17:03:06+00:00): Steht das Haus aus dem letzten Luftbild hier noch oder ist da was neues inzwischen? Falls ja zeiche ich es mal ab
https://i.imgur.com/FIYQAu2.png
m902 (2016-04-10 22:52:48+00:00): I changed amenity=bar to amenity=pub, also corrected the name of the pub (Rose & Crown). It is a pub, but the name is not 'Pub'.
mueschel (2016-04-11 19:06:25+00:00): Hi,
you put the tag 
minspeed:forward:lanes on some ways - the usual order is minspeed:lanes:forward (i.e. :lanes follows the base key immediately, the the direction in the end). I just fixed that for you.

Cheers and happy mapping,
Jan
polkillas (2016-04-16 16:52:23+00:00): Hi Jan,
Thank you very much for the fixing. I wasn't actually sure about the order and I didn't look for that, so thank you again
Supaplex (2016-04-10 18:47:39+00:00): 解救烏來
user_717463 (2016-04-11 20:04:42+00:00): крепко жму руку)
mavl (2016-04-12 02:36:56+00:00): Это ещё не все адресные данные. Будет ещё какое-то количество пакетов правок с таким же комментарием.
GerdP (2017-08-26 05:45:11+00:00): Hi!
Please review https://www.openstreetmap.org/way/226829423
The tag highway=mini_roundabout should only be used on nodes, I think what you meant is a junction=roundabout or maybe
just a circular road without special rights of way. See also https://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout#Possible_misinterpretations
SomeoneElse (2022-12-02 22:17:18+00:00): Hello,
Any idea if the bit of road outside the church should be part of https://www.openstreetmap.org/relation/91128#map=19/52.45276/0.69071 , or whether it's the northern bit of the relation that's wrong?
Best Regards,
Andy
Robert Whittaker (2022-12-05 14:59:23+00:00): I'm not sure I'm afraid, but I'll try to take a look next time I'm out in that direction. From what I recall, the signing on the ground around there is somewhat patchy, so any route is probably a mix of interpolation and guess-work. The route would probably have supposed to follow the official Rights of Way: Lynford FP 6, then a bit of the U33346, and finally Lynford RB 7 (i.e. closer to the southern option). But the route of Lynford FP 6 doesn't exist on the ground. See https://osm.mathmos.net/prow/progress/norfolk/breckland/lynford/ .
Robert Whittaker (2023-01-02 17:14:13+00:00): I've been to have a look at the ground today. There are no signs on the ground for the Hereward Way round there, so I've routed the OSM relation along the riverside route that's used by the other Long Distance Trails, and most closely follows the PRoWs.
SomeoneElse (2023-01-02 18:53:43+00:00): Thanks, that makes sense.
user_7622 (2016-04-10 20:03:08+00:00): Neben meiner Frage zu changeset 38456595, welche sich auch auf dieses changeset bezieht, hast du hier unter anderem mit Punkt 4112033719 einen gemeinsamen Knoten zwischen Wassertunnel in Layer -1 und Straße im Layer darüber erstellt. Ist das Absicht oder Versehen?
Carnildo (2016-04-10 18:32:50+00:00): Two points about this edit:

1) Streams need to point in the direction of flow.  You've got the lower section of Hog Creek flowing uphill.

2) Where did you get the data for the trail to the outlet of Hog Creek?  My notes from my hike yesterday don't show a trail junction there, and there's nothing obviously trail-like in the aerial photographs of the section near the main trail.
Carnildo (2016-04-24 05:10:06+00:00): I re-surveyed the area today, and could not find any evidence of the upper section of the trail.  Given the continued absence of evidence that that part of the trail exists, I'm removing it.
poornibadrinath (2016-04-25 12:19:15+00:00): Hey @GardeniaMartinez, highways or any other entity on OpenStreetMap shouldn't be named using personal names or osm ids. The name tag is for name of that particular point, line or polygon you have updated on the map. 
Adding your own name on a street does not add any value to OpenStreetMap. So, I have gone ahead removing the name here. I'd suggest you to refer to best practices of OpenStreetMap mapping before you go further.
http://wiki.openstreetmap.org/wiki/Good_practice
Best, 
 Poornima Badrinath
user_7622 (2016-04-10 19:53:17+00:00): Du scheinst gerade ziemlich grossflächig im Süden von Deutschland Bundesstraßen von primary nach trunk umzutaggen. 
Zumindest die B31 am nördlichen Bodenseeufer ist größtenteils weder Schnellstraße noch autobahnähnlich ausgebaut noch Kraftfahrstraße noch kreuzungsfrei, was das rechtfertigen würde. 
Bist du dir mit deinen Änderungen da wirklich sicher?
MarcRvB (2016-04-10 18:33:31+00:00): Ik zie dat sommige wegen in Ijselveld geen maxspeed hebben. Daar komt binnenkort een 2de versie van. Ook heb ik het gehucht Heeswijk een andere postcode gegeven en een andere type (Hamlet)
ElliottPlack (2021-01-29 22:10:44+00:00): After five years and many edits, I've reunited the park under one protected area. The individual sections are still preserved, but each one does not have the protected area tags because they would be duplicative. See https://www.openstreetmap.org/relation/12250276#map=12/39.2774/-76.8204
Chetan_Gowda (2016-04-13 05:33:52+00:00): Hi @Verdy_p, 
 This is huge changeset which covers the whole world. What are the changes that you've made here?
Verdy_p (2016-04-13 05:38:11+00:00): No it is not huge, a few nodes updated in Saint-Pierre-et-Miquelon, reference the land-area relations for French overseas from the territorial relations (because of a previous contact by someone that did not find these relations), and nothing else !
Do you know that France covers areas on all continents except asia ?
Only the bounding box is large, but changes are minimal.

My comment was accurate: look at the details on the changeset, you'll see it is in fact very small in terms of data
Verdy_p (2016-04-13 05:49:03+00:00): In summary the affected zones are only islands of the French Antillas, Saint-Pierre-and-Miquelon where a a sline lake was updated to include an islet and refine the border, two islands in New Caledonia,  the small island of Cliperton and a few tags for islands in New Caledonia (fixing also a terrestrial border between two provinces on the main island). All these in France overseas, but none on continental areas you see in the bounding box. No other country was affected.
Verdy_p (2016-04-13 05:57:44+00:00): As you are working in India, India is in the bounding box of the changeset, but there was absolutely no change in India (or anywhere in Asia).
The computed bounding box of the changeset is a bad indicator here. the affected zones are small maritime areas in North-West Atlantic, in the Caribbeans, and in South-West Pacific where there were minor geometric corrections, and North-Eastern Pacific only for a missing relation member (not for the geometry).
Verdy_p (2016-04-13 06:01:46+00:00): In fact the "computed" bounding box of the changeset that you see here is even larger than the reality (it is rounded by "quadtiles")
SomeoneElse (2016-04-13 12:21:07+00:00): It'd also be useful to know what the source was :)
smaprs (2016-04-14 01:01:45+00:00): Now the name of our neighbor in the map is France, not French Guiana anymore : http://www.openstreetmap.org/relation/1260551
Verdy_p (2016-04-14 02:29:36+00:00): So what is the problem?

This is effectively France, whose "Guyane" (official French name of the French Guiana) is a standard region and a standard department. French Guiana is not a self-governed and sovereign country. In the past it has been a territory, but it opted locally for the full integration.

The international boundary of France includes boundaries with Brasil and Suriname in Guyane (and the boundary of France with Brasil is the longest terrestrial boundary that France has). It has always been included in France in OSM data even if there were a few missing tags for some kinds of requests.

This was regularized excactly like all other French overseas.
Verdy_p (2016-04-14 02:39:40+00:00): In fact there's a single exception with a different tagging only for one of the districts of the TAAF that is located in Antarctica (the inclusion is partial.

But the change on Guyane was not related to this: I only attached its land area to its territorial area, and did not change the boundary at all.

Note also that there's a distinction between France (covering every territory of the Republic) and France métropolitaine (only the territories in Europe). The official international status (admin_level 2) is for the whole country (even if there are some territories contested elsewhere but not in Guyane). Both Brasil and Suriname recognize France (with only fuzzy borders along rivers, as they are also the main communication "roads" for the region, and on a jointly managed very large natural park in far Amazonia)
Verdy_p (2016-04-14 03:04:56+00:00): Also the change in this Gyanese relation has nothing to do with the fact that the default map displays "France". The map now displays correctly everywhere the country at level 2, including in exclaves. This relation has never been at level 2 and I did not change the level in that changeset. Only the OSM Mapnik renderer was corrected to select the appropriate label to display. This is true everywhere in the world, including outside France (look at US, Japan, Russia, China, Vietnam, the Kingdom of the Nertherlands, and all archipelagos in the Pacific and Indian Oceans...)
Only British overseas territories, and British Crown dependencies display their own name on the map (because they are not formally part of UK), even if they are not fully self-governed and sovereign and this is reflected in their OSM data.
smaprs (2016-04-14 10:33:41+00:00): Ok, not questioning on recognition of sovereign country, but seems weird, every World Map I've seen have highlighted local name of territories, not omitting it. Imagine every Pacific Ocean islands only with country name.
Verdy_p (2016-04-14 12:00:09+00:00): But this is not this changeset that did that. the OSM rendererer just displays now the country at level 2 (if it can be located), not a higher level.
Previously it did not display anything and displayed a label only for the largest area in a boundary, but not in any exclave (this was also true for all other levels).
Verdy_p (2016-04-14 12:03:36+00:00): Note: every island already display their country name (before that change in the renderer, it was almost impossible to see their country name anywhere, and often not even the name of a higher level as it was visible at high zoom levels where they were hidden and replaced by city names). Once again this does not come from this changeset.
Verdy_p (2016-04-14 12:07:20+00:00): In summary this is not a problem of OSM data, but a problem of renderers to select which labels to display when they compete for the same display area: this is tuned in Mapnik rendering rules by hiding showing/hiding labels depending on zoom levels.
MKnight (2016-09-05 13:02:55+00:00): Moin, Du bist bei den Öffnungszeiten hier: https://www.openstreetmap.org/node/3355454793 in diese Falle: https://github.com/opening-hours/opening_hours.js/issues/87 getappt, ich habe es korrigiert.
Nakaner (2016-04-11 12:36:01+00:00): Ich habe die Löschung der zwei Betriebsstellen-Nodes und das Ersetzen durch eine Fläche rückgängig gemacht. Es ist übliche Praxis in Deutschland, dass man railway=station/halt als Nodes mappt.

Ich möchte dich darauf hinweisen, dass Hamburg-Dammtor aus zwei Haltepunkten besteht, einer an der S-Bahn, einer an der Fernbahn. Daher sind das zwei Nodes in OSM.
hans-mueller (2016-04-11 13:43:02+00:00): 1. Tut mir sehr leid, aber da muss ich Dich leider korrigieren. Es wurde offiziell entschieden "The station itself is mapped as an Area". Siehe http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Station. Mir ist die station outline bekannt, daher ist das Mappen als Fläche in diesem Fall korrekt. Bitte die von mir erstellte Fläche wiederherstellen und die Nodes löschen.
2. Hamburg Dammtor hat nur eine UIC, nämlich 8002548. Insofern braucht es auch nur 1x "railway=halt". Wenn Du zwei Elemente erstellst, die beide „Hamburg Dammtor“ heißen und dieselbe UIC aufweisen, dann verstößt das gegen "One feature, one OSM element". Es ist nur ein Bahnhof, hatte bislang aber zwei Elemente. Daher hatte ich das korrigiert. Damit die unterschiedlichen Betriebsstellen kenntlich gemacht sind, hatte ich die unterschiedlichen Betriebsstellenkennungen an die Stop-Positionen und Bahnsteige getagged. Aus welchen Gründen benötigst Du denn für jede Betriebsstelle zwingend ein eigenes Element?
3. Auf der Wiki-Seite http://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dstation hast Du eine Zeichnung erstellt. Finde ich super. Sehr übersichtlich! Einen Hinweis hätte ich allerdings: So, wie Du es darstellst, wird public_transport=station als Fläche gemapped und railway=station als Node (d. h. zwei verschiedene Elemente). Das verstößt leider ebenfalls gegen "One feature, one OSM element". public_transport=station gehört in dasselbe Element wie railway=station/halt. Das ist gängige Praxis (siehe taginfo: Ca. 58% aller public_transport=station Elemente weisen auch „railway=station“ auf). Könntest Du das bitte in der Zeichnung und möglichst auch im Text korrigieren? Dann haben wir einen korrekten und einheitlichen Stand :-)
hans-mueller (2016-04-12 11:45:23+00:00): hallo?
Nakaner (2016-04-12 12:25:24+00:00): Deine Station-Fläche habe ich gleich nach dem Revert schon wiederherfestellt gehabt. (Ich hoffe, fass ich dad auch hochgeladen habe)

Es ist IMHO kein Problem, dass uic_ref=* an mehreren Objekten hängt. Oder löscht du diverse Bushaltestellen, wenn sie in einem Bahnhofsnummernsystem dieselbe ID wie ein brnachbarter Bahnhof haben? railway=halt/station wird nunmal für Betriebsstellen verwendet und dort hat es eben zwei.
hans-mueller (2016-04-12 12:37:59+00:00): Soweit ich das erkennen kann, werden railway=station/halt für Bahnhöfe und Halte verwendet. Wann wurde denn von wem beschlossen, dass es stattdessen für Betriebsstellen verwendet wird?
Nakaner (2016-04-14 15:38:23+00:00): Bahnhöfe und Haltepunkte sind Betriebsstellen, ebenso wie Güterbahnhöfe, Betriebsbahnhöfe, Abzweige, Anschlussstellen, Ausweichanschlussstellen, Überleitstellen und Deckungsstellen.

Dass man bei so Doppel-Stationen (in Berlin gibt es eine Reihe davon) zwei Stationen mappt, hat sich halt in der Vergangenheit durchgesetzt.

Um es noch einmal zu sagen: Dammtor wird aus PTv2-Sicht als eine Station gemappt (public_transport=station-Fläche, https://www.openstreetmap.org/way/409320932) und aus Eisenbahninfrastruktursicht als zwei Stationen (railway-Nodes).
hans-mueller (2016-04-15 18:12:20+00:00): Wenn wir unbedingt zwei railway-Nodes für eine einzige UIC benötigen (der Mehrwert bleibt mir zwar verborgen und verstößt darüberhinaus gegen "One feature, one OSM element" aber das sei mal dahin gestellt. Ich schrieb bereits, dass ca. 58% aller public_transport=station im selben Objekt auch railway=station aufweisen. Es ist also vollkommen gängige Praxis, public_transport=station im selben Objekt wie railway=station zu mappen "One feature, one OSM element". Daher meine Irritierung. 1. Woraus geht hervor, dass public_transport=station unbedingt getrennt von dem railway=station/halt gemapped werden muss? 2. Woraus geht hervor, dass railway=station/halt nicht als Fläche gemapped werden darf?
hans-mueller (2016-04-15 18:17:12+00:00): Aus PTv2-Sicht soll railway=station übrigens als public_transport=station + area=yes interpretiert werden. Siehe http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Compatibility_with_well_known_tags. Das gehört also eindeutig ins selbe Objekt. Tut mir leid, wurde so beschlossen!
hans-mueller (2016-04-15 18:20:52+00:00): Dort steht übrigens "railway=station tagged as area". Warum soll man also railway=station nicht als Fläche mappen dürfen und dann natürlich auch public_transport=station reinschreiben dürfen? Ist doch Unfug, das auf zwei Elemente zu verteilen. Ein klassischer Fall von schlechtem Mapping: One Feature, two OSM elements!
hans-mueller (2016-04-15 18:28:17+00:00): Im Wiki steht übrigens nichts davon, dass railway=station als Fläche gemapped werden darf. Das nervt mich total weil man es eindeutig darf und auch viel gemacht wird, auch in Deutschland! Steht in totalem Widerspruch zum beschlossenen PTv2. wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Was soll das?
hans-mueller (2016-04-15 18:47:19+00:00): Und was heißt hier: PTv2-Sicht und Eisenbahninfrastruktursicht? Beschlossen wurde nun mal PTv2, auch wenn es offenbar einigen Leuten nicht passt, aber so ist es nun mal. Und die Eisenbahninfrastruktursicht kann sich da durchaus anschließen. Schadet doch nicht, die Betriebsstellen usw. halt mit zu taggen. Aber deswegen jetzt alles doppelt zu mappen, das verstößt total gegen http://wiki.openstreetmap.org/wiki/DE:One_feature,_one_OSM_element
hans-mueller (2016-04-15 18:51:21+00:00): Noch eine Sache: Nenne mir eine Gegend, wo es tatsächlich gängig ist, "public_transport=station" als Fläche zu mappen und überall zusätzlich "railway=station" Nodes zu mappen! Das scheint mir nicht gerade gängige Praxis zu sein, würde mich mal interessieren, wo das gängige Praxis sein soll.
Nakaner (2016-04-15 21:00:47+00:00): http://overpass-turbo.eu/s/fGn zeigt dir Flächen mit public_transport=station und ohne railway=* im Umkreis von 100 m um Nodes mit railway=station/halt.

Der Vorteil eines railway=station/halt-Nodes ist, dass er keine Flächenausdehnung angibt. Bei Haltepunkten wäre die Flächenausdehnung nicht so schlimm, bei Bahnhöfen hingegen schon. Bahnhöfe reichen von Einfahrsignal bis Einfahrsignal. Das kann eine weite Strecke sein (u.U. deutlich mehr als 1 km). Würde man diese Fläche als railway=station mappen, würde das die meisten Nutzer stören. Der Centroid solcher Flächen läge nämlich nicht in der Nähe der Bahnsteige, sondern irgendwo. Deshalb ist das Mapping von railway=station/halt als Node ein Kompromiss, damit sowohl die Eisenbahnmapper mit ihrer Bahnhofs-Definition als auch Nicht-Bahnfreaks zufriedengestellt sind.

Es gab zu dem Thema min. eine Diskussion im OSM-Forum. http://forum.openstreetmap.org/viewtopic.php?id=26086

Würdest du One-Feature-One-Object streng auf PTv2 anwenden, müsstest du noch deutlich mehr löschen. Wenn du den Bahnhof als public_transport=station-Fläche mappst, sind die Haltepositionen ein Dopplung bzw. umgekehrt.
hans-mueller (2016-04-18 12:07:44+00:00): 1. "Bahnhöfe reichen von Einfahrsignal bis Einfahrsignal." Wie kommst Du darauf, dass dieses Bahnhofskonzept auch bei OSM gilt? 
2. "Es gab zu dem Thema min. eine Diskussion im OSM-Forum." Was ist Deiner Meinung nach das Ergebnis dieser Diskussion?
3. "Wenn du den Bahnhof als public_transport=station-Fläche mappst, sind die Haltepositionen ein Dopplung bzw. umgekehrt". Wie kommst Du darauf?
SomeoneElse (2016-04-10 20:28:33+00:00): Oops - something at latitude 0, longitude 0 got added here.  I've deleted it.
Jothirnadh (2016-08-23 05:14:40+00:00): Dear Seandebasti,

Can you explain the tourism information you added in this changeset? I think this is a wrong tag given by mistake. If it's a mistake can you fix them please.

Cheers,
Jothirnadh
ulmtuelp (2016-04-16 10:50:17+00:00): Hallo, der Raum 028 http://www.openstreetmap.org/way/401347023#map=19/52.45610/13.29662
ist nur eine sich selbst überschneidende Linie. Bitte korrigieren.
escada (2016-06-15 05:45:44+00:00): Hallo,

Ik zag nu pas dat u de paden voor mountainbikers in De Schorre de naam MTB hebt gegeven in april. Ik betwijfel echter of de naam van die paden echt wel "MTB" is. 

Kan u http://wiki.openstreetmap.org/wiki/Mountain_biking eens raadplegen en eventueel de tagging aanpassen, volgens mij moeten de volgende wijzigingen gebeuren:

- highway=path (cycleway in Belgie enkel als er een rond blauw bord met witte fiets staat)
- verwijderen van name
- toevoegen van mtb:scale
- eventueel creëren van een route relatie

Het is natuurlijk jammer dat deze informatie niet zichtbaar is op de basiskaart van OpenStreetMap, maar op de hierboven vermeldde wiki pagina staan tal van links naar kaarten die interessant zijn voor de mountainbiker.

happy mapping
koenstr (2016-06-15 07:13:31+00:00): Hier spreekt men van een "Technisch mountainbikeparcours".  Is dat een correctere benaming?

http://www.deschorre.be/content/dam/deschorre/recreatie-en-sport/Flyer%20mountainbikeparcours%20De%20Schorre.pdf
escada (2016-06-15 11:08:45+00:00): Persoonlijk zou ik dat als naam van de route gebruiken, niet van het pad.
smaprs (2016-04-10 21:10:05+00:00): Tava certo antes a Represa...  
As etiquetas têm que ser: natural=water + water=reservoir.  
O nome é livre, pode colocar "Represa Agronol" se é este.  
O "waterway=dam" vc. pode colocar na linha de talude da barragem, somente. Veja, como já está em: http://www.openstreetmap.org/way/366169196. O resto é água. Senão até a renderização sai como se a represa fosse concreto puro.
global system (2016-04-11 12:13:36+00:00): ok mestre, muito obrigado, suas dicas me ajudam muito.
Akrimullah IRM-RV (2021-06-28 23:06:19+00:00): Olá Lucas Marques, este corpo de água cruza https://www.openstreetmap.org/way/409329448 com esta estrada https://www.openstreetmap.org/way/409329487#map=17/-15.04737/-42.23865. alguma sugestão para corrigir o problema de cruzamento?
ramyaragupathy (2016-04-11 07:05:13+00:00): Hey @myriam66,
Looks like you have deleted existing data in this changeset and been adding it again in subsequent changesets. I understand that you are trying to improvise data in this area. While it is great that you are doing this, it is better to retain history rather than deleting them completely which obliterates history. There is some good documentation on OSM best practices available here http://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history.

Please stick to the best practices and continue mapping on OSM!
Minei3oat (2016-06-14 21:02:54+00:00): Die Haltestellen befinden sich jeweils auf der anderen Straßenseite
joost schouppe (2016-04-12 11:11:44+00:00): Welcome to the club! But sorry to say you didn't do it right. The "attraction" you created is about the central station. That already exists, so the tag should have been added to the existing station, not on a new node.
MCDA (2016-07-04 18:28:39+00:00): You are tagging ploughed fields as natural=mud which is not correct.  Also the tracing accuracy is very poor.  I am deleting these ways.
yasunari (2016-04-23 15:46:31+00:00): Why did you change highway tag of way 54459905?
It's primary road!
SomeoneElse (2016-04-11 13:06:37+00:00): Hello micha_k,
This looks very much like a mechanical edit (see http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct ).  Can you please explain where you discussed them beforehand, and also what source you used for the change in each case?
In previous edits near me (http://www.openstreetmap.org/changeset/38239352), your changes have clearly not been influenced by the actual situation on the ground.
Can you please explain how this changeset is not subject to the same problem?
Best Regards,
Andy Townsend, on behalf of OpenStreetMap's Data Working Group.
micha_k (2016-04-13 17:11:02+00:00): Hello Andy,
I've found these places automatically by overpass. I searched for contradictory tagging which cannot represent any possible real object.

Afterwards, I've used aerial imagery to check wether these objects are monorails or railways (as they were tagged) or just simple crane rails as part of a mobile crane.

In my understanding, this was not a mechanical edit. If I am wrong, please leave a notice.

regards,
Micha