piebro/osm-data huggingface dataset:
tms13 (2026-07-06 11:54:29+00:00): No, please don't overlay closed ways onto other features (walls, fences. etc) - it makes it very hard to select the correct way to edit, and tends to end up with users adding nodes to one of the ways and getting them out of sync.  A principle of data normalisation is to not duplicate information in a way that can get out of sync - if a wall performs the function of a boundary, then it should _be_ the boundary.

I do see your point about changing land usage, and that's a cogent argument for maintaining separate relations per field.

I'm hoping we can produce the best of our combined work, as we have both spent multiple hours editing this area, and it would be a shame to lose it.

I do see now that the later-removed ways that missed the first pass (under the walls rather than above them) were differently tagged - I'll fix those up immediately.
gurglypipe (2026-07-06 17:32:59+00:00): While I acknowledge that opinions on multipolygons vs areas differ, and different mappers may choose different approaches when adding new things to the map, I strongly disagree that converting existing areas of the map from areas to multipolygons (or vice-versa) is a good thing to do.

It loses history (https://wiki.openstreetmap.org/wiki/Keep_the_history) and it runs a high risk of introducing errors (as evidenced by the 13+ edits it’s taken you to get to this point). That’s been 13 edits to get us to a point where the visual rendering of the map is basically where it was before, i.e. no additional data/detail added.

I understand data normalisation, but I don’t think those concepts are suitable to be blanket-applied to OSM. They trade duplicate lists of nodes in areas, for long lists of short ways in relations. In particular, they mean that what was previously one wall, with one set of attributes, now has to be split into many smaller lengths (bordering each field/farmyard/wood/etc), each with separate sets of attributes which can go out of sync.

I think there are examples in the extremes of both mapping styles, and a combination of the two styles is needed.

But in any case, I think that converting something mapped in one style, into another style, is a recipe for introducing friction and errors without actually improving the map. That is why I am suggesting reverting the edits. Then we’d be back to a known-good state (modulo the OSM Inspector error, which I think could be fixed relatively simply by just touching the existing relations around Kingsdale Head, unless you think otherwise?).

It sounds to me like the problems you’re having in selecting the correct way to edit are a usability problem with your editor — it’s fairly straightforward to select the right way/area in ID due to the shading on the inner edge of each way.

For areas which are snapped together along a series of nodes, ID also ensures that a newly added node is also part of both areas, which typically avoids the other problem you mentioned. It’s not something I’ve seen in practice on areas which were snapped together correctly already.

Conversely I think it’s easier for users to accidentally introduce problems into the database when multipolygons are in use, as they are more complex and less well understood. For example, extending a way which is already part of a multipolygon, or trying to delete a way which is part of a multipolygon. ID has some protections against this, but these often frustrate users who don’t understand the reasoning, and then they end up doing interesting/incorrect workarounds which break things even more.

Sorry for the long message, but I hope it explains my position and reasoning a bit better.
tms13 (2026-07-07 12:43:58+00:00): Renders are only a small part of OSM of course (though widely used).  There's a lot that renders well that you or I would not consider high quality!

As I said, if you want an individual relation for each field, go ahead and split the areas - I do see the value in making it simple to change landuse on a field-by-field basis.

You wouldn't be undoing the other improvements I hope?  Such as the additional inner ways where woodland and water bodies interrupt the heath.

In terms of usability with multiple ways, I can deal with that (usually with a temporary node to pull part of the overlying way aside to reveal what's hidden), but the evidence is that many contributors don't seem able to do that and they end up introducing inconsistencies unnecessarily.  Of course, you do have a point that those same people have a tendency to remove ways from relations then add a replacement to only a subset of the affected parents, so it does seem to be a case of "swings and roundabouts"....
StreetSurveyor (2026-07-07 22:39:48+00:00): I noticed the pedestrian portion of River Rd that I recently mapped was deleted. Based on both the town and state GIS, it is identified as part of River Rd, and my on-the-ground survey supports that as well. There is also a River Rd street sign at the Washington St intersection indicating the roadway continues through the pedestrian section.
Gonéo (2026-07-06 13:11:48+00:00): Il me semble que le lieu s'appelle Educa'dog et non pas Frédéric Thivat.
eggie (2026-07-05 18:08:33+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
eggie (2026-07-05 18:18:40+00:00): Feedback  .. Gebouwen zijn directe import vanuit het Kadaster. Die zijn precies ingemeten geïmporteerd.
Overstekende delen zolas balkons en andere constructies op een hoger niveau geven niet de basis van het gebouw aan. 

Op grond van schuin genomen luchtfoto's kun je niet goed een gebouw uitlijnen. 
Het lijkt dan verkeerd op de foto, maar het is juist correct. 
MVG
eggie
eggie (2026-07-05 18:22:31+00:00): Maar goed... Dit is wel een heel gecompliceerd bouwwerk.
HellMap (2026-07-08 12:04:00+00:00): Dalot ceļus, lūdzu ņemt vērā, ka tur var būt relācijas. Ap apli bija salauzti visi maršruti.
eggie (2026-07-05 18:10:32+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
Feedback  .. Wanneer het de naam van het gebouw is dan is het oke. Wanneer het de naam van het bedrijf is dam svp de adresnode gebruiken om op bij te taggen.
MVG,
Eggie
Namens de OSM Community
eggie (2026-07-05 20:54:03+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
literan (2026-07-06 19:48:39+00:00): а почему адрес точкой, а не на контуре здания?
Ozon OSM4 (2026-07-07 06:58:42+00:00): Добрый день. Несколько зданий отрисованы как один полигон. Адрес присвоен одному зданию
literan (2026-07-07 13:04:39+00:00): ясно. перерисовал тут.
eggie (2026-07-05 18:23:24+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
MappingMore (2026-07-07 05:36:40+00:00): Reverted in  https://www.openstreetmap.org/changeset/185244235
eggie (2026-07-05 20:53:21+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
user_5359 (2026-07-07 08:59:15+00:00): Hello! Please have a look on https://www.openstreetmap.org/way/225777984 (one of four objects). What is the mean of the tag Bandi = Gyurodája ?
vasony (2026-07-07 16:46:26+00:00): Hi, thanks, I fixed the copy paste error.
adamos (2026-07-07 15:40:16+00:00): Segmenty v relaci musí navazovat. Tram 7 jsem opravil, na další se snad dostanu v příštích dnech. Příště prosím editujte opatrněji, díky
jmarchon (2026-07-06 04:04:05+00:00): Welcome to OSM!
ICT_maps (2026-07-20 17:51:34+00:00): see https://www.openstreetmap.org/note/5401777
Dvorný (2026-07-05 18:20:58+00:00): One of three changesets: https://www.openstreetmap.org/changeset/184692873
Fraxi (2026-07-05 18:34:39+00:00): Май са 5 метални колчета, с черно-бели райета. Няма някакъв знак, но просто оттам не може физически да мине кола. И частта на улицата югозападно е заприличала на пътека тук-таме. Обрасло е... Малко прилича на историята с парка Овча купел.
Dimitar155 (2026-07-05 19:10:26+00:00): Не съм минавал, просто го отбелязах така за да го взима предвид и навигацията.
Fraxi (2026-07-05 18:13:49+00:00): Also used Mapillary
JezCrow (2026-07-07 18:49:43+00:00): There may not be any infrastructure on the ground, but according to bustimes.org, services 1 and 48 stop here in both directions.
https://bustimes.org/stops/270000007811
https://bustimes.org/stops/270000007812
Therefore it would be better to tag physically_present=no

The same applies to the stops deleted in changeset/185155584
Car Tographer (2026-07-08 08:59:31+00:00): Thanks for letting me know about this - I didn't know about this. I've added them back with physically_present=no. (changeset/185326464).
Negreheb (2026-07-16 09:59:13+00:00): Why did you cahnge the house to a landuse and then drew a new house? :D 
Anyway, if you use building=construction https://wiki.openstreetmap.org/wiki/Tag:building%3Dconstruction instead of the descrptions tools like stretcomplete can pick it up and ask specific questions about it. 
For the next time maybe. :)
jcnl44 (2026-07-05 23:54:40+00:00): Bonjour,
La rue est-elle vraiment inaccessible ?
Ou voulez-vous indiquer son caractère privée (vu qu'il y a des barrières de chaque côté), auquel cas est-ce que access=private ne serait pas plus pertinent ?
balint36 (2026-07-11 23:43:14+00:00): Mátrixon pedig még szó is volt, hogy az útátjáró az eredetihez képest északabbra került. Az átjáró szelvényszáma is ezt igazolja, illetve az is, hogy a 9-es kitérőhöz közel van, amit felrajzoltál, az távol van. (És egyébként ezt alátámasztja az itt fel nem használható vasúti térinfó rendszer is és a google is.) Itt megint a közút a hibás, de ezt többször is mondtam.
itineris (2026-07-12 16:55:15+00:00): Külön rákérdeztem Ivánnál. Azt mondja, újra a régi a jó nyomvonal.
Nem tudom, szkanderezze le egymással a két állami cég.
balint36 (2026-07-12 21:00:15+00:00): Az államis dologgal teljesen egyetértek. Várjuk meg, amíg az MK frissíti a nyomvonalát, én ne akarjuk azt gondolkodás nélkül átvenni.
gruhler (2026-07-05 19:07:34+00:00): Ich bin nicht glücklich mit dem was ich hier gemacht habe. Abstellschieber für Wasserleitung so ähnlich gekennzeichnet https://commons.wikimedia.org/wiki/File:Schieberschild_S_400_2009-01-29.svg aber nur ca 15 cm große Metalldeckel. Habe kein beispiel gefunden.
gruhler (2026-07-05 19:08:14+00:00): Ich bin nicht glücklich mit dem was ich hier gemacht habe. Abstellschieber für Wasserleitung so ähnlich gekennzeichnet https://commons.wikimedia.org/wiki/File:Schieberschild_S_400_2009-01-29.svg aber nur ca 15 cm große Metalldeckel. Habe kein beispiel gefunden.
MappingMore (2026-07-06 10:16:07+00:00): Reverted in  https://www.openstreetmap.org/changeset/185187982
Giraffe123 (2026-07-06 22:27:32+00:00): This is incorrect their is a flock camera mounted on the side of a building there.
eggie (2026-07-05 19:13:47+00:00): Welkom bij OSM,
Bedankt voor uw bijdrage.
Probeer als het kan bij te taggen op de al bestaande adresnode. Alleen een naam of description doet niets in OSM. Geef ook de aard van het bedrijf aan.

..event_venue???  shop??

Mvg,
eggie
eggie (2026-07-05 19:16:05+00:00): Typo amenity= events_venue

Zie..
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Devents_venue
Valérie Tardif (2026-07-05 19:17:39+00:00): Erratum: description: ajouté partie souterraine de la station Place-Saint-Henri
hlfan (2026-07-06 06:39:40+00:00): Könntest du beim nächsten Mal bitte versuchen, die Historie der Wege zu erhalten, wenn du sowieso alle Knoten austauschst? Siehe dazu https://osm.wiki/DE:Keep_the_history
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185158538
rempshaener (2026-07-05 20:14:27+00:00): Jetzt hast du wieder die Gipfel gelöscht.
Mir bleibt gar nichts anderes übrig, als deine Löschung wieder zurückzunehmen.
Es gibt doch so viele andere Möglichkeiten: mit access arbeiten, nur das "climbing" löschen...
BirSchu (2026-07-05 20:22:08+00:00): Sorry, ist hab versucht nur das climbing zu löschen. no acess ist keine Lösung, weil das climbing ja dann trotzdem angezeigt ist.
heldz (2026-07-07 09:56:15+00:00): Am Hermannsberg existiert meiner Kenntnis nach keine Rechtssituation (wie etwa ein Naturschutzgebiet o.ä.), die das klettern untersagen würde.

Unabhängig davon existieren die Gipfel, egal ob man jetzt daran klettern darf oder nicht. Warum sollten sie also gelöscht werden?
rempshaener (2026-07-07 19:36:58+00:00): Entsprechend erneut zurückgesetzt.
eggie (2026-07-05 21:26:30+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
Gotlib68 (2026-07-05 21:07:47+00:00): Add gravel surface tags to existing roads near Rapla/Kehtna based on GPX trace and Esri imagery
houtari (2026-07-05 20:40:31+00:00): Terve! Sanoisin että tämä kohde on pikemminkin leisure = bleachers, kuin building = grandstand
StC (2026-07-05 22:20:14+00:00): Bonjour,

ce changeset a brisé façon puzzle la continuité d'un itinéraire pédestre qui passe par là. Je vais m'occuper de la réparation.

Note : cela doit être la quatrième ou cinquième réparation de ce genre que je fais ces derniers jours, je n'avais juste pas pris le temps de faire de la sensibilisation les fois précédentes.
mueschel (2026-07-07 19:44:10+00:00): Please check the tags - they all contain underscores instead of colons.
DavidDeluxe (2026-07-08 16:12:31+00:00): Apologies for the mishap. Completely forgot about the convention to use the ":" instead of "_". Somebody has already fixed it however. ~

For the future, is it okay to use the "planned" tag or should I use "proposed" as I've seen that before too.
mueschel (2026-07-08 16:56:46+00:00): "proposed" is the step before "planned". If something is still being discussed but not officially planned,  then "proposed" is the better prefix.
flohoff (2026-07-05 21:30:42+00:00): Das Wehr hab ich wieder runterklassifiziert - Da kommt man mit zweispurigen Fahrzeugen eben nicht drüber. 

Siehe mapillary Bilder.

Und da sind IMHO auch keine Tracks entlang der Ems. Das ist alles nicht Befahrbar. Ich habe das Probiert an vielen stellen. 

Das war schon absicht das ich da keine Eingetragen habe. Im Sommer steht da das Unkraut Mannshoch. 

An der Verlängerung Pixeler Straße stehen öfter Angler im Gebüsch.

Flo
5m4u9 (2026-07-06 01:53:03+00:00): hola, voy a revertir el cambio que hiciste porque no es primaria (no une poblaciones importantes y la infraestructura es regular para abajo) y porque ya existe la ruta 60.

Vuelvo a recordarte, las rutas nacionales no son automático trunk o primary. Quizá sea la disponible 62 o quien sabe...
opendcc (2026-07-06 02:39:57+00:00): Hallo, darf ich Dich nochmal bitten, einen Änderungskommentar mit anzugeben. Warum: siehe https://wiki.openstreetmap.org/wiki/DE:Good_changeset_comments
Ebenso bitte ich Dich, Nametagging zu unterlassen. Name ist nur der Eigenname, keine Beschreibung.
Mateusz Konieczny (2026-07-07 10:41:20+00:00): 1) to nie jest nazwa zaprzestań dodawania fikcyjnych nazw

2) skąd przekonanie że https://www.openstreetmap.org/way/1535668661 to boundary=forest_compartment ?
Yog Sot (2026-07-07 20:13:31+00:00): granice wydzieleń oraz wartość atrybutu `adr_les` możesz zweryfikować w bdl, możesz równiez pobrac ich shapefile. Informacje o nazwach są od przeszło roku. Wystarczy być w temacie, że ludzi interesuje co gdzie jest i lubią szczegóły
kubahahaha (2026-07-08 10:19:27+00:00): > Informacje o nazwach są od przeszło roku.

To są już złe? Czy kiedy się podbija rok w nazwie?
Yog Sot (2026-07-08 18:16:27+00:00): roku w nazwach się nie podbija, nazwa to nazwa. Inny przykład, stuletnie ścięte drzewo nie będzie za rok stu-jeden-letnie, bo jego nazwa jest inna. 
Ale i tak cię to nie interesuje.
cronoser (2026-07-07 23:40:36+00:00): Hola, 
por favor NO borres topónimos, ¡si están mal ubicados corrige la ubicación!
Si lo borras se pierde todo el historial de esos puntos y la mayoría de estos topónimos vienen de una importación de datos del IGN.
Un saludo
Óscar
Alshowaiey (2026-07-23 21:47:46+00:00): ممكن لاهنت معلومات اضافية عن هذا المكان وحقيقة كونة نزل
gscscnd (2026-07-07 07:18:40+00:00): Przydałby się tag określający rodzaj działalności, np. https://wiki.openstreetmap.org/wiki/Key:craft,  <https://wiki.openstreetmap.org/wiki/Key:office> lub <https://wiki.openstreetmap.org/wiki/Key:shop>.
eggie (2026-07-06 06:43:50+00:00): Dag Stofm,
De tag voor werkzaamheden is dan landuse=construction en niet construction=yes

Maar hoelang gaat dit duren?
MVG
eggie

MVG,
eggie
stofm33l (2026-07-10 19:50:08+00:00): Volgens de website tot november.
eggie (2026-07-10 20:03:25+00:00): Oke... Denk beter even zo houden, want het is geen bouwterrein. Dus landuse=construction lijkt me niet de bedoeling. Een brownfield is het ook niet. Het is wel in ontwikkeling. Het ziet er nu zo uit.
https://viewer.satellietdataportaal.nl/@52.36163,4.819055,18/?datastrip=20260625_SVNEO-02&sensorname=SuperView-NEO

MVG
eggie
limes11 (2026-07-06 08:55:54+00:00): Hallo, 

was meinst du mit agricultural=yes ? Wie ist dieser Weg denn vor Ort beschildert ?

An der Fahrradstraße hängt bereits vehicle=no. Es braucht dann kein weiteres motor_vehicle=no.

Viele Grüße
Brabakbengel (2026-07-06 14:58:09+00:00): Salli,
der Weg vor Ort ist Fahrradstraße mit zusatz: Landwirtschaftlicher Verkehr frei deklariert.
Daher kommt das.
Eventuell macht access=agricultural mehr sinn? Aber das würde in meinen Augen Radfahrer auf der Fahrradstraße explizit ausschließen!
Bei agricultural=yes gilt eine gezielte Ausnahme. 

Beim 2. Punkt bin ich bei dir. Ich habe die Key:access einfach kopiert und entsprechend für alle Straßen angepasst. Da kann ein Voriges noch mit durchgerutscht sein. Ich hatte nur noch die Strßennamen und die zusätzlichen Brerechtigungen separat gecheckt.
limes11 (2026-07-06 15:40:38+00:00): Hallo, 

korrekt wäre dann motor_vehicle=agricultural. (Es gibt eine sehr subtile Unterscheidung: agriculatural=yes beschränkt die Freigabe auf entsprechende Fahrzeuge wie Traktoren, schließt aber den Zugang mit einem normalen PKW auch für landwirtschaftliche Zwecke aus. Was fast nie so gemeint ist.)

Vor dem Biohof hattest du motor_vehicle=destination gesetzt, was Sinn ergibt. Dehnt sich dies auch auf die Zufahrt zu Hausnummern 14 und 18 aus, oder gilt dort bereits landw. Fahrzeuge frei ?

Grüße
Brabakbengel (2026-07-06 19:21:04+00:00): Hi,
ok das war mir nicht klar das man das so "motor_vehicle=agricultural" deklarieren kann. Danke!
Passe ich eben noch an

Zu deiner Frage Hausnummern 14 und 18: Ja da habe ich nicht reingeschaut und auch keine Fotos von gemacht, weil Grundstückszufahrten. Die würde ich einfach so lassen.
Razzle4 (2026-07-06 01:54:53+00:00): https://www.openstreetmap.org/way/984561679 
mtb:scale = no
eerib (2026-07-06 03:05:00+00:00): Good catch, fixed in

https://www.openstreetmap.org/changeset/185171962
nevw (2026-07-06 02:08:44+00:00): Hi, there is a short piece of duplicated road on part of Quinalow Edgefield Road.
https://www.openstreetmap.org/way/1535691897
rajdhani (2026-07-07 10:06:41+00:00): Partially Reverted in https://www.openstreetmap.org/changeset/185255777
HellMap (2026-07-07 20:37:29+00:00): Could you please clarify why these paths are now private https://www.openstreetmap.org/way/1535693085 ? Are there new signs, construction, fences, barriers?
Xentraxx (2026-07-08 06:28:11+00:00): Yes, I drove by there few days ago (I use this path often by motorbike) and the path is now fenced off with tape and a "private property" sign. I assume that someone will start building on that property soon.
HellMap (2026-07-08 08:04:35+00:00): Ah, I see, thanks for clarifying. It used to be empty property indeed.
Wxanon (2026-07-05 23:34:43+00:00): Wrong location. Was not aware of map orientation. There is one already in place where it is supposed to be. Not sure how to remove marker but this location is incorrect.
ElliottPlack (2026-07-07 15:42:21+00:00): Thanks for addressing my note!

—Elliott  
OSMF DWG
MappingMore (2026-07-06 08:55:33+00:00): Partially reverted in https://www.openstreetmap.org/changeset/185183988
rajdhani (2026-07-08 04:31:56+00:00): Partially Reverted in https://www.openstreetmap.org/changeset/185314231
aleph_null (2026-07-08 13:38:18+00:00): Ich finde auch,dass relation=site hier das falsche Mittel ist (oder wenn dann nur als sekundäre Gruppierung von Eingang und Haupt-POI). Es sieht aber aktuell noch so aus, als ob hier etwas schief gegangen ist, ich sehe zumindest nicht den eigentlichen POI als Multipolygon (und Nominatim findet auch nichts). Die Site Relation gibt es aber noch.

Muss man zum Kiga erst durch einen anderen Gebäudeteil laufen, oder geht der durch das ganze EG? Man so eine Situation auch grob mit einem indoor=corridor erfassen.

Die Geometrie sieht so oder so noch nicht ganz richtig aus, mit einem role=inner Element was außerhalb des role=outer liegt. Ich würde vorschlagen das als einfaches Polygon einzutragen, mit der Außenfläche und dem relevanten Gebäudeteil (ggf. mit zusätzlich noch mit weiteren Tags wie `level=0`).

Könntest du dir das nochmal anschauen?
Pemu (2026-07-08 20:42:38+00:00): Mir ist aufgefallen, dass da die Roles Inner und Outer automatisch vergeben wurden, obwohl natürlich beides Outer sein muss.
Ansonsten sieht für mich alles wie gewollt aus.
Wobei, was mir jetzt missfällt, was ich aber nicht so richtig vor Augen habe (ich bin gerade nicht vor Ort): Warum dieses Gebäude in zwei Teile aufgeteilt wurde (Ways #1493026812 und #1185356347). Der Kindergarten hat einen Innenbereich, der umfasst diese beiden Flächen, aber nur im Erdgeschoss. Daher habe ich Way #1535701580 eingerichtet. Und er umfasst einen Außenbereich (Way #1493026816). Beides sollte eine Relation ergeben (#21068779) -- die nun auch den richtigen Type und Roles haben sollte. Da ist mir irgendwas durch die Lappen gegangen -- vermutlich zu oft Undo gemacht.
Nichtdestotrotz sollte ich mir das nochmal vor Ort unter diesem Gesichtspunkt angucken -- vermutlich müssen die eingangs erwähnten Ways ihre Rollen tauschen (Gebäude und Gebäudeteil).
ajmat (2026-07-07 08:33:00+00:00): Reverted in https://www.openstreetmap.org/changeset/185251154
Joseph R P (2026-07-06 01:38:38+00:00): Beale Street should remain trunk until the interchange is open. Tagging it as primary effectively creates a gap in the trunk route. It should probably also remain a trunk road until all movements between the Route 93 alignment and I 40 are open.
Flap Slimy Outward (2026-07-08 21:21:58+00:00): Okay, I'll keep that in mind. Thanks!
VLD0251 (2026-07-06 12:40:21+00:00): Please verify that name:ar (رايشنبخ) is a correct Arabic transliteration supported by a reliable source.
Baloo Uriza (2026-07-06 16:22:50+00:00): phone=* tags use ITU format so they're consistent globally.  So (405)285-2233 becomes +1 405 285 2233 as an example.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185169103
MappingMore (2026-07-07 09:49:38+00:00): Partially reverted in https://www.openstreetmap.org/changeset/185254890
felipeeugenio (2026-07-06 13:26:54+00:00): Hola. Ese no es el numero de la casa? CUal es el motivo de borarlo?

saludos y gracias
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/185169185
Vi2727 (2026-07-06 19:38:26+00:00): Hello, please use fixme=* instead of FIXME=*.

I have corrected it to fixme=*.

Wiki: "https://wiki.openstreetmap.org/wiki/Key:fixme"
Fizzie-DWG (2026-07-15 05:20:05+00:00): DWG revert - unauthorised source

https://www.openstreetmap.org/changeset/185761159
Legras_TT (2026-07-06 02:40:51+00:00): Thanks for updating this! I'll mark my note as closed. Cheers