piebro/osm-data huggingface dataset:
ToniE (2026-01-11 11:44:07+00:00): Hallo maxi_,

bei dem Edit sind am Bahnsteig Way https://www.openstreetmap.org/way/1126917034 leider alle Informationen verloren gegangen, vergleiche bitte die vorangegangene Version https://www.openstreetmap.org/way/1126917034/history/21

Dadurch kommt es zu Problemen mit S-Bahn-Routen-Relationen, z.B. S 1 Leuchtenbergring => Flughafen München https://ptna.openstreetmap.de/results/DE/BY/DE-BY-MVV-Analysis.html#train_S1

Sind die Infos komplette verschwunden, oder was ist dort passiert?

Könntest Du bitte die betroffenen S-Bahn-Routen-Relationen S1, S2, S3, S4, S5, S6, S8reparieren oder die Infos am Bahnsteig wieder herstellen oder sagen, wohin die Informationen "gewandert" sind?

N.B. achte beim Reparieren der S-Bahn-Routen-Relationen bitte auf die korrekte Reihenfolge der Relationsmitglieder: "iD", der Editor im Browser ist da manchmal eigenwillig, für solche Relationen eigentlich nicht geeignet.

Viele Grüße
Toni
maxi_ (2026-01-11 14:17:05+00:00): Hi Toni_,

das ist natürlich ungut. Ich hatte gehofft iD macht das von alleine richtig und bei einem kurzem Check nach der Änderung ist es mir leider auch nicht aufgefallen, dass die Relationen nicht passen.
Die Bahnsteiginformationen sind jetzt hier: https://www.openstreetmap.org/relation/20067580

So wie ich es sehe müssten also die 10 relevanten Relationen von way/1126917034 nach relation/20067580 verschoben werden, also bei letzterer hinzugefügt und bei ersterem entfernt werden.

Ich habe bis jetzt nur iD verwendet und hätte es jetzt damit manuell angepasst. Welcher Editor ist den besser empfohlen für solche Arbeiten?
ToniE (2026-01-11 15:32:59+00:00): > So wie ich es sehe müssten also die 10 relevanten Relationen von way/1126917034 nach relation/20067580 verschoben werden,

Im Prinzip ja. In der OSM-Struktur ist der Way way/1126917034 derzeit Mitglied ('member') der 10 Relationen und müsste aus der Liste er Mitglieder der 10 Relationen herausgenommen werden und (!) an der selben Stelle der Mitgliederliste durch die Relation relation/20067580 ersetzt werden - und hier patzt iD.

Der bessere Editor ist JOSM (josm.openstreetmap.de), gerade für Relationen sehr zu empfehlen. Das ist ein JAVA-basiertes Programm, das auf dem PC läuft. Hat leider eine gewisse Lernkurve, auf Dauer aber das deutlich bessere Werkzeug.

Da ich nun weiß, was geändert wurde, warum und dass es notwendig war, ... kann ich die 10 Änderungen machen - in JOSM

Gruß
Toni
ToniE (2026-01-11 16:11:40+00:00): Fertig.
maxi_ (2026-01-11 17:47:01+00:00): Hallo Toni,

vielen Dank für die Erklärungen und die Korrektur der Relationen. Ich denke ich habe alles verstanden und sehe, wie die Änderung in iD kompliziert ist und schnell Fehler entstehen können.
JOSM muss ich mir bei Gelegenheit mal ansehen.

Viele Grüße
Maxi
eggie (2026-01-11 09:31:40+00:00): Dag juni_vv,

Die volkstuinen zijn oke. Je hoeft in OSM Nederland geen foot=yes te gaan toevoegen aan fietspaden. Dat is default.
Kwaad kan het hier niet, want er is ook nog segregated = no getagd. 

MVG
eggie
juni_vv (2026-01-11 16:43:32+00:00): dank voor de feedback!

groetjes,
juniper
vrix (2026-01-12 05:42:13+00:00): Hi Choculat, I believe there's something wrong with your changeset, as the relation is not available in Nominatim anymore https://nominatim.openstreetmap.org/ui/details.html?osmtype=R&osmid=6948543
NeisBot (2026-01-17 15:18:55+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description, note or slogan contain detailed text that may be interpreted as promotional or SEO-related. To ensure OSM remains neutral and focused on map data, I recommend keeping descriptions concise, factual, and free from marketing or promotional language.

⚠️️ Problematic element (limit 1):
https://osm.org/node/13446826541 v2

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Math tutoring center in Oviedo"

#MapWithoutSpam
NeisReview (2026-01-25 07:25:52+00:00): 🗑️ Element deleted
NeisBot (2026-01-17 15:18:56+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description, note or slogan contain detailed text that may be interpreted as promotional or SEO-related. To ensure OSM remains neutral and focused on map data, I recommend keeping descriptions concise, factual, and free from marketing or promotional language.

⚠️️ Problematic element (limit 1):
https://osm.org/node/13446848753 v1

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Math tutoring center in Pembroke Pines"

#MapWithoutSpam
NeisReview (2026-01-25 07:25:53+00:00): 🚫 Text removed by https://osm.org/changeset/177088624
Hugoren Martinako (2026-01-13 11:49:07+00:00): Kaixo! Gogoan izan kale baten izena aldatzen denean, hari lotutako helbideak ere aldatu behar direla
FeetAndInches (2026-01-10 19:52:41+00:00): The link didn't paste correctly in the description. Resolves note 5051738: https://www.openstreetmap.org/note/5051738.
MxxCon (2026-01-11 03:10:29+00:00): Hello.
Please elaborate your edit. There's nothing in that youtube video shows that this feature extends into the private parking lot.
OSM is a map and database of the world NOW, not how it used to be at some undetermined point in the past. If you want to want map historical railways, you are welcome to do it at openhistoricalmap.org
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177074747
Andrew Byler (2026-01-11 03:23:27+00:00): The lead track continues down the hill to the two sidings against the building at the bottom of the hill which are filled in with gravel. You can see the rails filled in between with gravel on Google Maps. I've personally been to this location for work.
Andrew Byler (2026-01-11 03:25:38+00:00): What I drew is exactly what is there right now.
Andrew Byler (2026-01-11 03:26:57+00:00): If you toggle NYC property maps to the aerial image you can see the rails coming down the hill beneath the vegetation.

https://propertyinformationportal.nyc.gov/parcels/parcel/3038710001
MxxCon (2026-01-11 03:27:16+00:00): Please note that you are not allowed to use Google Maps to map in OSM. It is a copyright violation and a violation of the terms of service you agreed to with Google and OSM.
Andrew Byler (2026-01-11 03:31:29+00:00): I'm not using Google Maps to map. I told you I've been to this site myself. The rails are visible on the video and on the NYC property maps.  You mentioned them not being visible in open source maps and I replied that you can see them in Google Maps too.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177074747
MxxCon (2026-01-11 03:34:56+00:00): I can see the rails extending into the trees, but not into the parking lot down there. Same on the satellite imagery, I don't see rails going through the parking lots of different properties.
MxxCon (2026-01-11 03:12:18+00:00): Hello.
Please elaborate what you are mapping here. None of the available satellite imagery shows the feature you added.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177074814
Andrew Byler (2026-01-11 03:32:19+00:00): There are two sidings against these buildings. The area of the ties is filled in with gravel to the height of the top of the rails.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177074814
NieWnen (2026-01-11 11:24:44+00:00): Dzięki!
coatix (2026-01-12 14:26:10+00:00): Bitte "Aida" so lassen, siehe https://github.com/osmlab/name-suggestion-index/pull/11636
MxxCon (2026-01-11 03:12:40+00:00): Hello.
Please elaborate what you are mapping here. None of the available satellite imagery shows the feature you added.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177074868
Andrew Byler (2026-01-11 03:32:31+00:00): There are two sidings against these buildings. The area of the ties is filled in with gravel to the height of the top of the rails.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177074868
eggie (2026-01-10 20:14:50+00:00): Dag Ben..
Meestal taggen we dan access=private
Mvg
eggie
benjong27 (2026-01-10 20:25:22+00:00): Hallo Eggie,
Ik zie het net ook toevallig langskomen op de kaart.
Dank voor de tip, ik pas het aan.
En ik zal de volgende keer wat beter opletten :)
Ryccardo (2026-03-31 17:43:14+00:00): Mmmh, la maggior parte della città NON è una foresta (escluso qualche isolato, quelli che ostruiscono le foto aeree sono quasi tutti giardini delle case), anzi, i pini della strada principale del centro sono stati notoriamente eliminati qualche anno fa per dubbie ristrutturazioni :(
Tommizanot (2026-04-01 07:09:10+00:00): sì, sostanzialmente è vero, però con tante virgolette penso si possa dire che nella zona si sia voluto mantenere, durante la rapita costruzione di immobili del dopo guerra, una quasi foresta artificiale di pini simile a quella della città giardino di Milano Marittima
TrickyFoxy (2026-01-14 15:50:11+00:00): man_made=water_tap это буквально тег для таких колонок. Не удаляйте его
silversurfer83 (2026-01-20 18:32:16+00:00): Hi again

thanks for picking up on the comments.

Here's another one :)

Please check out the article on building=* and find out about the difference between house and terrace

cheers
Nakaner (2026-03-06 15:48:01+00:00): Hallo,

magst du bitte genauer ausführen, was du unter der Quelle "Web" verstehst? Woraus leitest du beispielsweise ab, dass dieses Haus die Bramstedter Straße 10 ist? https://www.openstreetmap.org/way/235361904/history

Viele Grüße

Michael
Nakaner (2026-03-06 15:53:08+00:00): This changeset has been reverted by https://www.openstreetmap.org/changeset/179453142 where the changeset comment was: "Revert changeset/177060355 due to vandalism (moving boundaries is no valid reason, see source tags at changeset 176983663). Revert changeset 177075766 in order to reduce the number of conflicts and due to partially mechanical nature."
Nakaner (2026-03-06 16:33:08+00:00): Ich habe diesen Änderungssatz ebenfalls revertiert, weil er auf Änderungssatz 177060355 aufbaut und lediglich aus dem Abarbeiten von Validatormeldungen besteht.

Die Validatormeldungen eines Editors sind nicht dazu da, einfach mit der Gießkanne als Arbeitsanweisungen blind angewendet zu werden. Dies gilt sowohl für iD als auch für JOSM.
Yog Sot (2026-01-10 20:45:36+00:00): parametry dla jednego tagu saparuje się przez średniki - ;

a nie przez ,_  
jbc
Scout Jens (2026-02-06 14:54:22+00:00): Sind dort denn Bautätigkeiten zu erkennen oder ist das nur eine auf Plänen vorgesehene Erweiterung? Was sind Deine Quellen? Aufm Luftbild ist nada zu sehen.
NxPFoto (2026-02-06 16:15:33+00:00): Sorry, hab bei diesem Changeset die Quelle "Mapillary" vergessen :)
Da sind die Baumaßnahmen zu erkennen.
Grüße
silversurfer83 (2026-01-11 09:31:33+00:00): Gude :)

eine Sache zu deinen Mauern: Das Wiki spricht unter https://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dcity_wall nicht von Burgen. City wall sollte meiner Meinung nach auch nur für Mauern um Siedlungen genutzt werden, nicht für Burgmauern. Wühl dich doch mal ein wenig durch die Links in dem Artikel um das hier korrekter zu fassen.

Löcher in Mauern sind übrigens barrier=entrance (dann muss die Mauer nicht aufgetrennt werden).

Schönen Sonntag
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177076267
SG86 (2026-01-11 19:29:59+00:00): Hallo,
das stimmt. 
Eigentlich müsste castle_wall passen:
https://wiki.openstreetmap.org/wiki/DE:Tag:wall%3Dcastle_wall
Ich muss mal schauen wie es gerendert wird. Vermutlich aber mit der dünnen Linie.
city_wall hat eine dicke Linie, die viel besser passt.

Beim Artikel zu "castle" https://wiki.openstreetmap.org/wiki/Tag:historic%3Dcastle ist am Ende ein Beispiel genannten: die Burg in Malbork, Polen. Dort sind die Mauern auch mit city_wall gemacht worden. 

Viele Grüße
SG86 (2026-01-11 19:30:24+00:00): https://wiki.openstreetmap.org/wiki/Tag:historic%3Dcastle
SG86 (2026-01-11 19:33:02+00:00): malbrok ist die Marienburg, eine sehr bekannte Ordensburg
SG86 (2026-01-11 19:37:52+00:00):  castle_wall wird nur mit einer dünnen Linie gerendert.
Ich finde dass dies der tatsächlichen Situation nicht entspricht.
Ich habe daher folgender gewählt:
barrier=city_wall
historic=yes
material=stone
wall=castle_wall
silversurfer83 (2026-01-11 19:49:56+00:00): Verstehe.

Die Sache ist die: wir versuchen uns im Wiki auf Richtlinien zu einigen, wie wir die Dinge, die wir vorfinden, erfassen. Daran versuchen wir uns zu halten, damit diejenigen, die diese Daten dann nutzen, auch davon ausgehen können, dass eine Stadtmauer eine Stadtmauer ist und nicht irgendeine andere Mauer.

Diese Daten landen dann in einer Datenbank aus der unzählige Dienste die Daten ziehen und jeder Dienst, der daraus eine Karte erstellt entscheidet für sich, welche Daten in welcher Form dargestellt werden. Wir als Datensammler haben da nur sehr beschränkten Einfluss und sollten uns deshalb auch nur sehr beschränkt Gedanken machen, wie etwas am Ende aussieht.

Was du möglicherweise meinst ist die "Standardkarte" auf osm.org. Dieser Stil nennt sich Carto und diese Karte und primär als Feedback für uns Datensammler gedacht.

Deine Wand ist *entweder* eine barrier=wall + wall=castle_wall *oder* eine barrier=city_wall

Da ich bei diesen kleinen Burgen keine City Wall erkennen kann bin ich für castle_wall.

Das Wiki erklärt auch, dass du dicke Wände als Umriss erfassen kannst. Empfehle ich nur, wenn die Luftbilder gut genug sind.
gscholz (2026-01-18 07:49:30+00:00): Hi lephotographe0769,
this changeset has created errors in the OSM database regarding overlapping ways.

This kind of error irritates routing software and looks ugly on the maps. Can you plese fix this?

You may also like to educate yourself about how to edit hiking routes properly:

https://wiki.openstreetmap.org/wiki/Hiking

Kind regards
Guido
lephotographe0769 (2026-01-20 21:03:29+00:00): Hi Guido,
I delete the way and create it later with relations.
Best regards.
Lephotographe0769
coatix (2026-01-12 14:27:19+00:00): Bitte "Aida" so lassen, siehe https://github.com/osmlab/name-suggestion-index/pull/11636
mobileGEO (2026-01-13 02:41:24+00:00): Yup. Passt. Um es in Shakespeare zu sagen 《What is in a name ...》
TrickyFoxy (2026-02-15 09:46:32+00:00): Reverted

https://www.openstreetmap.org/changeset/178573796
Yunan973 (2026-01-11 17:18:37+00:00): Bonjour,
merci à toi d'avoir ajouté le siret. Mais c'est encore mieux de vérifier si le siret est toujours actif : le cabinet a fermé en 2022.
J'ai corrigé.
Cordialement
jubonhomme (2026-01-11 20:03:50+00:00): Merci pour le suivi.
J'avais vu que le siret indiquait comme fermé mais j'attendais de voir si dans l'outil de Complète tes commerces il y avait une proposition de reprise avec un nouveau siret.
Je le faisais donc souvent en 2 passages, le premier passage pour ajouter les sirets manquants et un deuxième avec l'aide de CtC pour voir si ce n'est pas juste un changement de siret et s'il y a des propositions.
Je pourrais mettre une note si le siret indique que c'est fermé. Mais ça se fait automatiquement pour tous ici 
https://complete-tes-commerces.fr/57/57463-metz/siret_clos.html

Ce qui me fait aussi hésiter à fermer directement avec la seule info du siret c'est que je connais des commerces encore existant après fermeture de leur siret, car justement c'est juste à cause d'un changement du numéro.

Mais je retiens l'idée de faire la modification immédiatement si j'ai assez d'infos qui montre une fermeture définitive.
Yunan973 (2026-01-18 19:13:22+00:00): Bonjour,

je n'utilise jamais complete tes commerces , je préfère utiliser directement le site officiel de l'Insee ( annuaire-entreprises.data.gouv.fr), accessible directement depuis iD si tu déplies à gauche la zone "champs" et si tu cliques sur la flèche à côté du numéro siret.

Quand un siret est indiqué fermé, il faut regarder à quelle adresse il se situe et faire une recherche sur ce site de l'insee pour trouver, éventuellement, un nouveau siret.

Exemple avec https://annuaire-entreprises.data.gouv.fr/rechercher?terme=24+LIVIER+METZ : tu peux voir qu'il y a eu 3 pharmacies successives, 2 fermées et une actuelle.

quand tu mets une adresse fais gaffe à l'orthographe : boulevard est parfois écrit bld, saint est parfois st, une ville peut parfois utiliser 2 codes postaux, etc. donc il ne faut garder que les mots non ambigus lors de la recherche (cf les 3 mots que j'ai mis).
Yunan973 (2026-01-18 19:41:22+00:00): En faisant une recherche au 26 au lieu du 24, tu peux voir qu'il n'y a plus de médecin mais une aide soignante (Manon lemarié), à mettre éventuellement
jhaluska80 (2026-03-05 01:54:54+00:00): Some of the highest quality building work I've seen.  Great job.
thaccio (2026-03-05 04:51:13+00:00): thank you so much!
i2004 (2026-01-10 22:18:22+00:00): queres que te ayude con la 271
TrickyFoxy (2026-02-17 21:20:21+00:00): Reverted

https://www.openstreetmap.org/changeset/178698831
NeisBot (2026-01-10 21:54:22+00:00): Hi rstillwell, welcome to OSM!

Thank you for your contributions to the map. I have reviewed your recent edits and noticed that 98% of the changes in this set involve deletions, including:
- 15 highway(s)
- 1 leisure(s)
- 3 source(s)

Could you please confirm if these deletions were intentional or if they occurred by mistake?

Looking forward to your response.

#DeletionsCheck
---
https://resultmaps.neis-one.org/osm-change-viz?c=177078009
rstillwell (2026-01-10 21:57:57+00:00): Absolutely intentional and accurate.
GeeMaps! (2026-01-10 22:44:17+00:00): Is the Sheriff's Office really in the middle of the jail, & is there really a prison around the Annex? if the Annex is only a Police Station, it should be tagged as amenity=police, not a prison & government office.
rstillwell (2026-01-10 22:48:27+00:00): Yes, the Sheriff's Office and the Jail are synonymous; the jail is run by the county Sheriff per the Georgia constitution and as such both offices are located in the same building.

The Sheriff's Office Annex is only a jail (look at street view to verify) with space up to 70 inmates, and no longer has unrelated offices (houses inmate workers/road crews and the like). The Annex was actually the main Sheriff's Office before 1998 when the one on Henry Parkway was completed.

Source: worked there 7 years
GeeMaps! (2026-01-11 01:58:33+00:00): Thanks! But you mentioned street view? If you meant Google SV, please note that we can't use any Google mapping product, including SV.
rstillwell (2026-01-11 11:55:18+00:00): Thank you, I am new at OSM.

It makes sense as Google has some of the most restrictive ToS anywhere. To be clear, I did not change the HCSO Annex dataset based on GSV, it was merely a natural response encouraging you to verify my claims/edit if you had to do so and I wasn't thinking about potential ToS violations.

Thanks for your direction.
VictorIE (2026-01-12 09:29:03+00:00): Hi,

https://www.openstreetmap.org/node/13447096062

Row of bollards mapped as trees. 

Both can be mapped as lines instead of nodes. :)
ACarlotti (2026-06-07 20:28:25+00:00): Hi, I've discovered that the mapping of the railway between Dagenham and Elm Park has a large number of obvious alignment errors, which you appear to have mistakenly introduced in this changeset (or related changesets).

Unfortunately it is very hard for me (or anyone else) to work out what went wrong, and what went fixing, because your changes are arbitraily split into 13 separate changesets, each of which is enormous, and they combine the addition of new labels to existing objects, with the widespread realignment of most objects in this area.

To get an idea of the incomprehensibility of this changeset, you can try viewing the diff at https://overpass-api.de/achavi/?changeset=177078340 (this will take a while to load).

Do you have any evidence that the updated object alignment is broadly more accurate than the previous data? Or did you just assume that the aerial imagery you were looking at was perfectly aligned without checking?

If you were just assuming, then I think it would be best to revert all the alignment changes if possible (perhaps by reverting the whole series of changesets and then readding the new object labels in new (smaller) changesets. And if the updated alignments are known to be a genuine improvement, then those alignment changes should have been made as part of their own separate changeset (with a clear explanation in the changeset for why the new alignment is better). Care should also be taken to ensure that the mapping looks sensible at the edge of any area you update, and that relative locations of objects are maintained.

Could you please explain the reasoning behind the alignment changes in these changesets, and let us know what plans you have (if any) for fixing the inconsistent alignment issues that you caused?
philipcullen (2026-06-07 20:37:05+00:00): Hi,

I generally try and align with Cadastral Parcels, and UPNRs (as a centre point to buildings).

I tend to combine changesets with UPRNs and other addressing date with geometry, as I find they are so interlocked that working with both together makes things easier.

I will have a look over the area to make sure the geometry changes make sense. I might not be able to do this immediately, but as you've asked, I'll put it at the top of my list.

Phil
ACarlotti (2026-06-07 22:31:45+00:00): Thanks - I've looked up the sources, and according to https://osmuk.org/cadastral-parcels/, it seems that aligning to cadastral parcels is a reasonable approach in certain circumstances. However, if you're using it as a basis to adjust existing mapping, then I think you should adjust the alignment of each object individually. The changes you made here seem to be assuming that all of the mapping in the area had a consistent erroneous offset from ground truth, which doesn't seem to be the case. In particular, I have compared some of the current OSM house and street locations against the cadastral boundaries, and in many cases it looks like your changeset has made the discrepancies worse.

On the other hand, I see no basis for assuming that UPRN coordinates indicate a particular point within in the property (such as the centre), so they don't seem to be a precise enough source to use for realigning mapping in this manner.

If/when you fix this, could you please try to keep your changesets small - perhaps to the scale of a street or a few blocks (which would allow you to describe the affected area in the changeset comments with much more precision than just "London"). You should definitely avoid making changes in one go that are so big that your editor splits them into multiple changesets.

Anyway, thank you for your reponse, and I look forward to seeing quality improvements from you in the future.