piebro/osm-data huggingface dataset:
NeisBot (2026-01-09 06:48:12+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/13439551975 v1

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Disaster restoration services"

#MapWithoutSpam
NeisRevert (2026-01-18 08:45:31+00:00): 🔄🤖 Partly reverted due to either a lack of response from the contributor or remaining promotional text by https://osm.org/changeset/177363822
(Deleted leftovers after several edits)
NeisBot (2026-01-09 06:48:15+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/13439567384 v1

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Arkoba Facilities en Ourense"
---
Por ejemplo, una versión más neutral y objetiva de tu texto podría ser: "Instalaciones Arkoba en Ourense"
---
(Auto-translation)

#MapWithoutSpam
NeisRevert (2026-01-18 08:47:53+00:00): 🔄🤖 Partly reverted due to either a lack of response from the contributor or remaining promotional text by https://osm.org/changeset/177363894
(Deleted leftovers after several edits)
NeisBot (2026-01-09 06:48:17+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/13439559922 v1

Could you please revise your text accordingly?

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

#MapWithoutSpam
NeisReview (2026-01-18 08:47:54+00:00): 🚫 Text removed by https://osm.org/changeset/177058444
ggs290 (2026-01-08 11:26:13+00:00): Este cambio ha sido para corregir un nombre mal puesto por un despiste. Véase el changeset original aquí: https://www.openstreetmap.org/changeset/176977332
NeisBot (2026-01-09 06:46:13+00:00): Welcome, and thanks for your edits!

I noticed a few unintended crossings between roads and/or between roads and buildings in this changeset. This usually happens when geometry snaps incorrectly. Additionally, changes to tagging (e.g. modifying highway types or adding tags) can lead to unexpected crossings being detected afterwards.

In total, I detected 16 potential crossings.

⚠️️ Problematic elements (top 3):
https://osm.org/way/1208829552 v4 | 11 crossings
https://osm.org/way/1465284300 v2 | 5 crossings

Would you mind revisiting those areas?

#CrossingCheck
---
https://resultmaps.neis-one.org/osm-change-viz?c=176980482
NeisReview (2026-01-17 16:43:43+00:00): ✅ Should be fixed by 
https://osm.org/changeset/177016392
osmviborg (2026-01-08 11:47:04+00:00): Tilføj gerne 'tracktype', hvis du har tid.
NeisBot (2026-01-09 06:48:21+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/13437987082 v3

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Appliance repair service at 618 S Broad ST Lansdale PA 19446"
---
Например, более нейтральная и фактическая версия вашего текста могла бы быть: "Сервис ремонта бытовой техники по адресу 618 S Broad ST Lansdale PA 19446"
---
(Auto-translation)

#MapWithoutSpam
NeisReview (2026-01-18 08:47:54+00:00): 🚫 Text removed by https://osm.org/changeset/177363647
NeisBot (2026-01-09 06:48:24+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/13439601214 v1

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Window tint and car wrap service in Justice Illinois"

#MapWithoutSpam
NeisReview (2026-01-18 08:47:55+00:00): 👍 Thank you for updating the element by https://osm.org/changeset/177012003
rskedgell (2026-01-08 17:30:00+00:00): Thanks!

In the next few weeks I'll walk both loops, update what I can with StreetComplete and add the metal information=route_marker discs set into the footway.
SomeoneElse (2026-01-10 12:01:03+00:00): See also https://community.openstreetmap.org/t/heavy-handed-rework-of-barbican-london/140254/7 , which suggests that a revert of some of the problem changes needs to happen.
rskedgell (2026-01-10 12:38:20+00:00): I saw that thread. It's unlikely that I'll have time next week, so hopefully it will all resolved before I do anything.
trigpoint (2026-01-11 17:26:12+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 18:25:31+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
SomeoneElse (2026-01-11 21:47:34+00:00): Thanks.  I'll let the dust settle before trying to join this up again - I suspect that there is more discussion at https://community.openstreetmap.org/t/heavy-handed-rework-of-barbican-london/140254 to come!
SomeoneElse (2026-05-16 13:51:18+00:00): Uber are editing here again so it makes sense to fix the 3 routes to make it easier to spot breakage.
City: https://www.openstreetmap.org/relation/12890344 in 2023: https://overpass-turbo.eu/s/2pUV relation check: http://ra.osmsurround.org/analyzeRelation?relationId=12890344&noCache=true&_noCache=on
Eastern: https://www.openstreetmap.org/relation/12812325 in 2023: https://overpass-turbo.eu/s/2pUW relation check: http://ra.osmsurround.org/analyzeRelation?relationId=12812325&noCache=true&_noCache=on
Western: https://www.openstreetmap.org/relation/12789722 in 2023: https://overpass-turbo.eu/s/2pUX relation check: http://ra.osmsurround.org/analyzeRelation?relationId=12789722&noCache=true&_noCache=on .
GinaroZ (2026-07-13 13:09:49+00:00): Hi, I've removed the campsite you added here: https://www.openstreetmap.org/way/1465302628/history#map=18/57.274835/-6.082011&layers=N because of the note - just take care when adding things (I assume) without a survey :)
trigpoint (2026-01-11 17:26:07+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 18:25:26+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 17:26:05+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 18:25:24+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 17:26:02+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 18:25:21+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
SomeoneElse (2026-01-10 11:48:16+00:00): Hello,
A gap seems to have appeared in https://www.openstreetmap.org/relation/1216650#map=19/51.050944/0.597351 - presumably https://www.openstreetmap.org/way/1464873396 needs to be split in two with the western half added to the relation?
Palgrave Peter (2026-01-10 15:44:38+00:00): Your right, I missed that. I've fixed it now.
NeisBot (2026-01-09 06:48:26+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/13433677011 v2

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Clínica de odontologia"
---
Por exemplo, uma versão mais neutra e factual do seu texto poderia ser: "Clínica de odontologia"
---
(Auto-translation)

#MapWithoutSpam
NeisRevert (2026-01-18 08:47:56+00:00): 🔄🤖 Partly reverted due to either a lack of response from the contributor or remaining promotional text by https://osm.org/changeset/177363895
Mateusz Konieczny (2026-02-04 04:45:43+00:00): Hello!

You used
bicycle=noc
on https://www.openstreetmap.org/way/25322664/history

Have you maybe meant
bicycle=no
?

I am pretty sure that it is a typo, but not sure enough to just replace it (I edited some objects where situation seemed more clear to me).

Or have you used this value deliberately? In such case, what was the intended meaning?

If it is a mistake - can you fix it?
Mateusz Konieczny (2026-02-04 04:47:14+00:00): o, pozdrawiam :)

A jest tam rzeczywiście zakaz jazdy rowerem?
gszkr (2026-02-04 14:41:18+00:00): Wzajemnie pozdrawiam :) 
Co do rowerów jest tam lekki bałagan, ale zasadniczo tak. W kierunku Huty zarówno przed wiaduktem jak i na łącznicy jest zakaz wyrażony znakiem. Od strony Powstańców Wielkopolskich nie widziałem, ale już na łacznicy z Kamieńskiego jest zakaz. Przymierzam się ciągle do wysłania zo ZDMK zgłoszenia z prośbą o weryfikację i ujednolicenie.
Mateusz Konieczny (2026-06-09 07:55:15+00:00): coś odpisali?
marinapatsevich (2026-01-08 12:12:38+00:00): Added roads according to Bing. #mapbox_feedback
VLD0251 (2026-01-08 22:08:39+00:00): Hello,
You have added 2 of the Xikluna Zaïkha Girls' School and Boys' School establishments with English names.
https://www.openstreetmap.org/node/13439646175
https://www.openstreetmap.org/node/13439646176
Could you tell us where this information comes from? For example, is there a sign on the building that shows these names in both Arabic and English? 
Finally, could you please remember to fill in the "changeset comment" field for your future uploads? This helps the community understand the context of your modifications.
soliMM (2026-01-13 21:01:17+00:00): This changeset has been partially reverted in changeset: 177196085
trigpoint (2026-01-11 17:25:57+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-11 18:25:16+00:00): This changeset has been fully reverted by the DWG in changeset https://openstreetmap.org/changeset/177102231
trigpoint (2026-01-12 17:49:30+00:00): This changeset has been reverted fully or in part by changeset 177148724 where the changeset comment is: DWG Revert Barbican Edits
NeisBot (2026-01-09 06:46:19+00:00): Welcome, and thanks for your edits!

I noticed a few unintended crossings between roads and/or between roads and buildings in this changeset. This usually happens when geometry snaps incorrectly. Additionally, changes to tagging (e.g. modifying highway types or adding tags) can lead to unexpected crossings being detected afterwards.

In total, I detected 8 potential crossings.

⚠️️ Problematic elements (top 3):
https://osm.org/way/1465131758 v2 | 8 crossings

Would you mind revisiting those areas?

#CrossingCheck
---
https://resultmaps.neis-one.org/osm-change-viz?c=176982917
NeisReview (2026-01-17 16:43:43+00:00): ✅ Should be fixed by 
https://osm.org/changeset/177021182
rempshaener (2026-01-08 19:05:24+00:00): Hallo und herzlich willkommen bei OpenStreetMap.
Zu diesem Änderungssatz habe ich folgende Anmerkungen:
- couplings bei Unterflurhydranten: Das Feld "couplings" bleibt bei Unterflurhydranten leer, da es sich um die „Angabe der vorhandenen Anzahl an Schlauchanschlüssen“ handelt, siehe osm.wiki/DE:Key:couplings?uselang=de. Unterflurhydranten haben in der Regel nur mit Standrohr eine Schlauchkupplung. 
- colour: Die Angabe erfolgt in englischer Schreibweise
- www.openstreetmap.org/node/13439701113: Bitte den Namen entfernen, Wasserentnahmestellen haben keinen Namen. emergency=water_tank wäre ein offener Wassertank zur Löschwasserentnahme, was in urbanen Gebieten äußerst selten ist. Worum genau handelt es sich hier?
Vielen Dank für deinen Beitrag und weiterhin viel Spaß beim Mappen.
Viele Grüße
rempshaener (2026-01-08 18:11:47+00:00): Hallo,

du hast um eine Prüfung deiner Bearbeitungen gebeten.

Ich habe folgende Anmerkungen:
- Poller haben werden auf den Weg gesetzt, d. h. der Node wird Bestandteil des Weges. Wenn sie separat stehen, haben sie keinerlei technische Auswirkung auf das Routing. Entsprechend reicht es in der Regel auch, einen einzelnen Node zu setzen.
- check_date: Die Angabe müsste als 2026-01-08 erfolgen.
- colour: bitte in englischer Schreibweise, d. h. red
- foot=yes ist unnötig, dies gilt implizit
- note ist hier überflüssig


Bei Fragen bitte melden.
Viele Grüße
Clostar (2026-01-08 19:38:00+00:00): Mis cambios no aparecen en el render final. Los guardo bien y aparecen dentro de la página "Editar", pero cuando salgo de ese menú no están en el mapa final.
¿Qué está fallando o hago mal?
rempshaener (2026-01-08 19:20:26+00:00): Hallo,
auch bei dieser Saugstelle sollte der Name raus, die tatsächliche Objekteigenschaft geklärt und die Verbindung zum Zaun aufgehoben werden.
Viele Grüße
galen8183 (2026-01-08 19:17:52+00:00): Hi apgosm, thanks for your contributions! Please resolve warnings iD gives you before uploading. Footways leading to building entrances should be connected to the building outline with a node tagged with entrance=*

Please also consider removing the preamble in every changeset comment, instead you can use a changeset tag or a shorter indication that you're mapping for Uber.

Thanks!
GerdP (2026-02-11 14:47:57+00:00): Moin!
Was ist denn bei diesem Haus https://www.osm.org/way/762639702 passiert?
Ich hatte die Nummer nach Vor-Ort-Besichtigung von 1 auf 3 gesetzt, Du wieder auf 1, und jetzt sagt auch ALKIS, das da die 3 ist? Da war ich dann wohl aktueller als ALKIS, und Du hast mir nicht geglaubt?
chris66 (2026-02-12 13:59:54+00:00): Hi, ist laut ALKIS die 3. 

Warum ich das auf 1 gesetzt habe weiss ich nicht mehr, vermutlich war es ein Versehen. :-)

LG aus NRW
GerdP (2026-02-12 14:09:33+00:00): Wie schon geschrieben: In ALKIS war es vermutlich früher auch 1. Schau Dir die Historie an. Warum sich die Nummer geändert hat erschliesst sich mir noch nicht. Wahrscheinlich wegen der Baustelle nebenan.
CanopyFalls (2026-01-10 11:14:04+00:00): Reviewed this as good on OSMCha because technically there are no issues with the data you've added. However it's usually not a good idea to make two different changes that far apart in the same changeset. Consider splitting edits that are far apart into different changesets in future.

Thank you for improving the map and welcome to OSM! Hope you enjoy mapping!
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/176983976
lbj20 (2026-01-10 16:24:58+00:00): Thanks CanopyFalls!  This was an unexpected side effect of using a mobile app, i thought i had submitted the bike parking weeks ago and then just did the cafe thinking it was a standalone item. Oops :)
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/176983976
CanopyFalls (2026-01-11 12:30:30+00:00): Ahh, that makes a lot of sense! BTW if you're on android a really good editor for filling in data on OSM is Street Complete. 
https://streetcomplete.app
JeroenvanderGun (2026-01-09 00:09:12+00:00): This relation for Metropolitan France should only contain ISO codes that identify Metropolitan France specifically. Data consumers trying to find France in OpenStreetMap by querying country code FR should not find this relation for Metropolitan France (or any other subdivision of France), but only the following relation for the entirety of France: https://www.openstreetmap.org/relation/2202162 - that relation already has the FR/FRA/250 codes so these codes are in the correct place in OpenStreetMap already.

FX and FR are currently both valid codes here (with FX having a more specific meaning than FR). While the territory of FX has indeed been merged into the territory of FR, the FX code has not been fully deleted, but replaced by an exceptional reservation. This is why the iso.org website says "exceptionally reserved" as status for FX. If it was truly properly deleted, it would instead say "formerly used" there, like BQ for British Antarctica: https://www.iso.org/obp/ui/#iso:code:3166:BQAQ

Likewise, if you are in e.g. Martinique, both MQ and FR are valid codes (with MQ having a more specific meaning than FR).

There are also other codes like EU for European Union that have always been just an exceptional reservation: https://www.iso.org/obp/ui/#iso:code:3166:EU

In other words, "officially assigned FX" has been deleted and "exceptionally reserved FX" has been added at the same time.

All ISO 3166-3 codes are alpha-4 codes (i.e. codes consisting of four letters) and all alpha-4 codes are ISO 3166-3 codes.

ISO 3166-3 codes are normally created when ISO 3166-1 codes are retired (usually because the territory disappears in the real world). The FXFR code was created because the FX code was 'downgraded' from "officially assigned" to "exceptionally reserved", to offer an alternative for people who were already using FX but don't want to rely on the exceptional reservation (which could theoretically get deleted at some point in the future).

TL;DR: I've reverted this changeset because it incorrectly equates France and Metropolitan France and specifies a four-letter ISO 3166-3 code which is impossible. Also there is a misunderstanding about the nature of the "deletion" of the old codes for Metropolitan France.

Earlier comments: https://www.openstreetmap.org/changeset/172975242
pavelt (2026-01-09 10:59:43+00:00): I see your point, and agree there is currenly no official ISO 3166-1 code specifically for the Metropolitan France and that FXFR code has "reserved" status can be added as ISO 3166-3. 

However, FX is not a valid ISO 3166-1 code, and it never was. 

My point is  - adding "ISO3166-1=FX" & co. to this relation is not correct (as this is not a valid ISO 3166-1 code), and has a negative practical implications - it causes problems with scripts/apps/tools that depend on this ISO 3166-1 tags.

For example, Valhalla routing engine now considers routes on continental France to have country code FX.

osm2pgsql now also imports this relation tagged as "country"=>"FX" - likely to some degree impacting results of map renders, Nominatim Search, Photon Geocoder, etc.

I cannot judge the full scale of the problem, but can confirm that at least some broadly used apps parse "ISO3166-1=FX" as "country=FX", and thus I belive it will be better to either set ISO3166-1 tags to a correct official values or remove them alltogether and allow tools to derive values from the higher-up relation or use existing heuristics like they did before the change, e.g https://github.com/valhalla/valhalla/blob/111091c003313b8b92ad4d3ae5ea39837eb85036/lua/admin.lua#L182
JeroenvanderGun (2026-01-09 16:09:56+00:00): I'm not sure what you mean by saying FX was never valid. Before becoming an exceptional reservation, it was officially assigned, which is the highest possible degree of validity. As an exceptional reservation, it's only partially invalid.

The Valhalla code you mentioned only reads the value of ISO3166-1:alpha2=* in case of admin_level=2 (on line 194). This relation is admin_level=3, so it will never set the country code to FX, even if you remove the lines of code you referenced that manually set the code to FR.

I believe there are two sorts of practical applications for these country code tags:

1) Find the territory corresponding to a country code.
2) Find the country code(s) corresponding to a location.

Deleting all not-officially-assigned codes may benefit the second category of applications but harms the first. Besides reserved codes this would also affect user-assigned codes like XK.

Would you be okay with adding a reserved: prefix to the ISO3166-1 keys here? That should solve any problems of applications mistaking reserved codes for officially assigned codes, while still making it possible to opt-in to using the reserved codes.
pavelt (2026-01-12 14:02:58+00:00): Yes, I think "reserved:" prefix could mitigate the downstream problems, yet maybe there is a more correct way to tag this information. 

Look, to my knowlege 3166-1 defines countries and territories (high-level), and FX was never a part of 3166-1. 
I'll truly appreciate if you prove me wrong and point to an ISO3166-1 reference that contains it. 

From another perspective, FX was, and still is (due to reservation), a part of broader ISO 3166 (3166-2, 3166-3, ...) and indeed improves the level of detail.

Regarding the Valhalla code reference - unfortunatelly you've misinterpreted it - it does exactly as I explained before, and this is confirmed by recent data builds.
Problem here is that it first heuristically deducts country code FR and then, later down the code, overwrites it with the ISO3166-1 value (FX). 
I agree that this code is just a "quick and dirty" heuristic - but I only wanted to demonstrate that your change does impact some existing things. 
Same for Posrgersql importers. 

"XK" is very different - it is not an official ISO 3166-1 element, but still a valid code, because it falls within the "user-assigned" range XA–XZ of the standard.  

So, my proposal is
- don't tag FX* codes as ISO 3166-1
- instead tag them as 3166-2 and/or 3166-3 where applicable

This will help both use cases you mentioned, resolve the problems that I pointed out, and improve the level of detail and correctness of the data.
JeroenvanderGun (2026-01-13 16:51:46+00:00): Okay, I've updated the tagging. The relation now uses the key prefixes reserved:, was:, and is_in: where appropriate.

Regardless, it may be worth debugging what happens in Valhalla because the code really looks like the override you describe should be technically impossible unless admin_level=2.

W.r.t. the former validity of FX: from https://en.wikipedia.org/wiki/ISO_3166-2:FR

> Metropolitan France (the part of France located in Europe) was previously officially assigned its own set of country codes in ISO 3166-1, with alpha-2 code FX, before it was deleted from ISO 3166-1. The code is now exceptionally reserved on the request of France.

This is how it ended up in ISO 3166-3 (mere exceptional reservations in ISO 3166-2 do not lead to codes in ISO 3166-3). The FX code was officially assigned from 1993 to 1997 according to https://en.wikipedia.org/wiki/ISO_3166-3
JeroenvanderGun (2026-01-13 17:13:29+00:00): Ah, I now see Valhalla treats every admin_level=3 as admin_level=2 by overwriting the admin_level. That explains the observed behaviour.