piebro/osm-data huggingface dataset:
NeisBot (2026-01-22 06:20:36+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 11 potential crossings.

⚠️️ Problematic elements (top 3):
https://osm.org/way/560222129 v3 | 11 crossings

Would you mind revisiting those areas?

#CrossingCheck
---
https://resultmaps.neis-one.org/osm-change-viz?c=177528249
NeisBot (2026-01-22 06:23:16+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/way/923205347 v3

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Flower shop"

#MapWithoutSpam
NeisRevert (2026-01-29 15:15:44+00:00): 🔄🤖 Partly reverted due to either a lack of response from the contributor or remaining promotional text by https://osm.org/changeset/177853083
(No visible changes after review)
Vik QA Gett (2026-01-21 15:54:53+00:00): @NeatNit before deleting you can goes to GMaps and take a look a real location by sputnik vision for example) 

If you want to delete my changes - ok, but then please fix on your side

I'm doing it cause customers have real issue, so I just try to help people :)
NeatNit (2026-01-21 16:02:01+00:00): Can you explain the issues people were having so we can fix them correctly?

The reason I hurried to revert your changesets is that the longer we wait, the harder it would be to fix, because other mappers might make more changes to the data. Right now, no one had made any other changes so it was easy to revert.

So, now it will be easier to fix the issues you or your clients were having - what are the issues?
Vik QA Gett (2026-01-21 16:15:49+00:00): Well, I'm from Gett and my job not related to the maps changes) so maybe you right that tech changes here could be incorrect by some rules) thank you 


Problems starts when users had several stop points on their trip, and use bus stations to meet. In this case, not in all cases but with specific roads locations starts / ends, road track builds incorrect, on the ground level for example, where the Platform based, but the bus station on the 2 or 3 level (higher) 

That's what I trying to fix here, cause by the feedback + Google maps check I see that bus station located  on. the road, meanwhile as I said, I moved the pin, if I do it incorrect, I'll be happy to follow your recommendations
NeatNit (2026-01-21 16:32:54+00:00): I see. So you want the routing to select correctly which road is next to the bus stop.

Note that it's forbidden by copyright to use Google StreetView to create or edit other maps: https://wiki.openstreetmap.org/wiki/Google

I will try to fix the issue for the bus stops you tried to move, by moving them closer to the road but NOT to become part of the road.
Vik QA Gett (2026-01-21 16:37:22+00:00): OK, sounds great! 

Thank you for your help and support!! 

My LN
https://www.linkedin.com/in/vikkostousov

It would be great if you made a correct changes and share changes here, I will check them for myself to understand how to do it correct) 

Have a great evening)
NeatNit (2026-01-21 16:49:18+00:00): Okay, I did my best to fix it here: https://www.openstreetmap.org/changeset/177531764

You can see the changes visually here: https://overpass-api.de/achavi/?changeset=177531764

I didn't understand what the problem could be for Em Hamoshavot, it seems to be mapped correctly. Can you explain what the problem is?

I am not on LinkedIn, but we can talk on the OpenStreetMap forum: https://community.openstreetmap.org/c/communities/il/50 (you can sign in with your OpenStreetMap account).
Vik QA Gett (2026-01-21 17:26:52+00:00): With Em Hamoshavot everything must be ok, thanks a lot 

On our side it will be updated little bit later, pls apply your changes, I'll check on my side too 

Thanks a lot for your feedback
Taya_S (2026-01-21 16:43:49+00:00): Reverted sockpuppet vandalism https://www.openstreetmap.org/user_blocks/19627

https://www.openstreetmap.org/changeset/177531762
Frans S (2026-04-17 13:38:06+00:00): Hello. Thank you for contributing to this project.
You are drawing houses with gabled roofs incorrectly. Due to the angle at which the imagery was captured, it appears as though a house with a gabled roof has an odd shape. In reality, it is a rectangle if you were to view the object directly from above. 
Please square also your mapped buildings with the Q key,
Solve also the issues shown by the issue triangle.
Best regards
Dawid2849 (2026-01-21 22:27:09+00:00): Cześć, 

dzięki za poprawę znaczników, ale mam drobną uwagę: ZUS w Biłgoraju ma dwa oddziały. Jeden znajduje się tutaj, a drugi na ul. Krzeszowskiej: https://www.openstreetmap.org/way/280726845

Ze strony ZUS:
Sprawy dotyczące emerytur, rent i zasiłków obsługujemy przy ul. Kościuszki 103
Sprawy dotyczące płatników składek, osób ubezpieczonych i lekarzy obsługujemy przy ul. Krzeszowskiej 62a.

Da się jakoś sensownie to oznaczyć czy zostaje do description skopiować informacje ze strony ZUS?
Dawid2849 (2026-01-22 13:16:44+00:00): O, jeszcze jedna uwaga. Może warto przy okazji dodawać
brand=Zakład Ubezpieczeń Społecznych
brand:wikidata=Q144881

aby iD nie krzyczało?
kubahahaha (2026-01-23 10:17:05+00:00): Cześć, dzięki za uwagi. Prawdę mówiąc to i tak wypadało by napisać na forum zanim zacząłem tą edycję :-/

Obrabiałem ostatnio dane urzędowe z lokalizacjami ZUSów i ułożyłem z tego zadania w MapRoulette - chciałem trochę poklikać żeby zobaczyć czy dobrze to wyszło.

1. Nie wpadłem na to żeby zobaczyć jak to wygląda w ID, dzięki. Na pewno trzeba dodać (strasznie dużo tych tagów się robi).

2. Oddziału na Krzeszowskiej nie ma w wykazie .xlsx dostępnym tu na dole strony:
https://www.zus.pl/o-zus/kontakt/oddzialy-inspektoraty-biura-terenowe

więc w ogóle bym go nie dotknął. Ale trochę głupia sprawa że go nie ma :D

Tak dokładnych danych nie jestem w stanie zaimportować, nie mam też pomysłu jak można je wpisać inaczej niż w description=*
Dawid2849 (2026-01-23 10:31:13+00:00): Wiem, że mogłem wcześniej, ale w tym roku nie mogę się zabrać do aktywnego uczestnictwa na forum i nie zwróciłem uwagi na ten projekt. Dopiero gdy ruszyłeś moje rejony to zwróciłem na to uwagę.

Dobra, w takim razie sprawdzę na miejscu ten oddział na Krzeszowskiej, czy aby na pewno ma te same godziny otwarcia i uzupelnię znaczniki.

Dzięki za odpowiedź :)
Taya_S (2026-01-21 16:43:50+00:00): Reverted sockpuppet vandalism https://www.openstreetmap.org/user_blocks/19627

https://www.openstreetmap.org/changeset/177531762
juni_vv (2026-01-21 16:46:20+00:00): Please keep your edits inside one continent :)
eggie (2026-01-21 19:19:29+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
Joseph R P (2026-01-25 17:38:34+00:00): Please do not reclassify objects for the sake of rendering, especially for third party services. Tagging this small section of road as a primary road breaks the connectivity of the trunk route. See here: https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
I-76 (2026-01-25 21:04:45+00:00): Understood, my apologies. Thank you for reverting.
CjMalone (2026-02-11 16:43:13+00:00): What does commercial=office mean? Is it a child of building=commercial or office=company? It has no wiki page and minimal usage.
kywrd (2026-01-21 17:34:18+00:00): 根据一级水源保护界线确定青草排和陌上花公园
baotao (2026-02-06 17:28:22+00:00): 建议小路用“服务道路”画，青岛市区卫星影像用Esri。
Rainero (2026-03-18 19:15:14+00:00): Revert mit changeset/180074219
(unzulässige Quelle)
Natfoot (2026-02-22 03:58:42+00:00): why did you add red? ff000?
j0hn33y (2026-02-22 04:29:25+00:00): Consistency with other segments, Help distinguish form other hiking routes that share route in this case (Buckeye Trail and North Country Trail)
Natfoot (2026-02-22 18:36:25+00:00): thanks,
gurglypipe (2026-01-21 22:11:03+00:00): Could you please pause and respond to the comments on your previous changesets before continuing to make the same huge sets of changes across the North West?

Adding UPRNs is undoubtedly good, but people need to be able to verify your work to trust it. Mixing 8000 changes of different types all together in a single changeset, with no information about the method you used to generate the changes (it has to be at least partially automated, right?), makes this very hard.
philipcullen (2026-01-22 12:32:27+00:00): My overly aggressive ant-spam filter meant that I didn't see the comments or your message until later on.

I'll have a look at structuring the changes into smaller sets, and look at the feedback.
lakedistrict (2026-01-30 18:26:36+00:00): Hi, I've started reviewing this and other local changesets and unfortunately there's a number of errors:
* Addresses on non-addressable objects
* UPRNs added to a random small building in the centre of a site rather than the site/grounds area
* Multiple UPRNs added to buildings which should have only one
* Incorrect/inconsistent address data added
* UPRNs added to likely incorrect buildings

As this may take time to fully review and fix, a revert may be easier? The UPRNs added to houses in residential areas are generally likely correct, but unfortunately not the edits to other objects.
philipcullen (2026-01-30 19:48:44+00:00): Hi,

There are some building=yes objects with addresses that ideally shouldn't have. I try and pick these out and make the building more specific, but I will invariably have missed some.

Buildings on a site are tricky - I do put the UPRN on the site where it is clear. Ideally the parent/child relationships would be open data to make this much easier, but at the moment it is not.

Where there are multiple UPRNs for a building (for example a shop with a flat above) I add the UPRNs to the building. I do make efforts to avoid adding retired UPRNs though (based on the sequence they are in and alignment).

I try and align and split buildings at the time of adding UPRNs if they fall on the wrong UPRN, but some slip through, and I do review these on further passes.

I do intend to do a few more passes over the area to pick up errors that may have crept in earlier - so I think it would be much easier not to revert. After some discussion with other local mappers, they'll be in much smaller changesets (divided geographically).

Phil
gurglypipe (2026-01-30 20:14:29+00:00): I don’t think you’re fully understanding the impact of reviewing these changes.

There are currently about 25500 individual changes in my area of interest from you, which have not been reviewed yet.

Reviewing your previous edits has so far resulted in tens of follow-up changes, from you, me and other local mappers.

The only way to review those remaining 25500 changes is either to review them one by one (in which case splitting edits up geographically helps with tracking progress, but doesn’t actually reduce the number of things to review; but more on that below); or to revert them en-mass (to remove the need for review; more too on that below).

Having now spent hours going through some of your changes, I am convinced that the automated edits policy (https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct#Scope) applies to them:
 - You are importing from the UPRN database.
 - You have at least a partially scripted workflow; or
 - you are manually changing tags without adequate review.

The fact that rskedgell has spent considerable time planning similar imports (https://wiki.openstreetmap.org/wiki/Import_of_UK_postcodes_and_UPRNs_(England_%26_Wales)) suggests the same.

You may say that your workflow can be (and has been) improved as a result of feedback, but that doesn’t deal with the huge pile of currently unreviewed changes, and it still means that any future edits you do will need to be reviewed.

As I’m sure you know, formalising your editing process by following the automated edits policy and publicly planning and documenting the import process ahead of time is designed to remove the need for that one-by-one review of changes, by checking that the process itself is not going to introduce errors into OSM.

That might mean fewer UPRNs get imported as quickly, because the underlying geometry isn’t yet in a state to match well with them, but I think that’s fine. It’s not a race!

So: subject to me being able to work out how to do it without introducing further errors into OSM, I plan to revert the larger of your unreviewed changes in the area. Please don’t make any further edits. Once you’ve documented your import process and got it reviewed (or joined in with rskedgell on their already-in-progress import), it should be straightforward to re-import the UPRNs here.

Sorry about this, I realise you’ve put some time into these edits. But I think this train was set in motion as soon as you started submitting multi-thousand-object changesets without following the imports process.
philipcullen (2026-01-31 21:30:27+00:00): I don't believe a revert is the best course of action here.

A significant number of the UPRNs are added completely manually (I have tooling to make this quicker, but it still requires selecting the object and UPRN), so they are not as easily replaceable as you suggest.

I combined improving geometry and adding UPRNs as I find the processes  benefit each other. I do believe that adding UPRNs is a benefit in, and of, itself, but I think the combined workflow benefits are much greater.

I would like to suggest an alternative approach, and I hope you will reasonably consider it:

I'll look through all the objects with UPRNs that are either not a building, or building=yes and check that they make sense. For building=yes, I'll upgrade to a more specific tag where appropriate.

I'll continue doing this in smaller batches (geographically), as we've previously discussed.

Whilst I'm doing this I'll improve geometries - I find this benefits from having the UPRN details added.

A suspect this will make you less comfortable - but I believe this will alleviate the need you feel to manually revier every change. As a general approach, I believe that asking people to fix their own errors (where they are able) usually yields the best results for everyone. I would hope that this might also reduce the frustration that you feel - I  never undertake anything wanting to negatively impact on other people.

After, say a month, then we could look at the total combined impact. If you still feel that parts should be reverted, then I'll work with you to do that (I have some tooling that would help in this).

I know this would be a leap of faith for you, but in the meantime, I'd ask you to avoid feeling the need to review all changes I make, or if you do, let me know what you'd like to be improved.

Phil
gurglypipe (2026-02-02 10:55:50+00:00): You’ve avoided responding to any suggestions that these edits should be done under the automated edits/imports policy, and now you’re asking the local editors to not review your edits and effectively allow you to mark your own homework.

In the meantime, while this discussion has been doing on, you’ve logged another ~17 similar edits in this area. Are you trying to make your set of changes too big to fail?

Your most recent edit (177988990) still has all the same problems:
 - Mass-adding address and UPRN details while also changing unrelated things (pipeline URL) which makes it harder to review or revert a changeset without collateral.
 - Adding UPRNs to things which I’m not confident the UPRN definitely represents (https://www.openstreetmap.org/way/1465345074).
 - Mixing geometry and tagging changes.

I’ve reported this to the DWG, because despite the weight of local mappers telling you to stop, I think we need a third opinion. It’s also gone beyond my abilities to revert things.
philipcullen (2026-02-02 15:25:21+00:00): I'm sure we're all working towards the same aims and in good faith - the recent edits were much smaller and I'd thought would be more inline with how you preferred them - there was no ulterior motive behind them.

I do occasionally fix things I come across unrelated to what I've intended to do, perhaps they should be in a new changeset, but I've always seen them as inconsequential. I do see you point on that though.

A third perspective will, I'm sure, be helpful. My offer to help you with targeted reverts, if needed, still stands.

Phil
trigpoint (2026-03-03 15:44:02+00:00): Hello Phil
Phil from the Data Working Group here.

I am going to echo what gurglypipe has asked you to do, but it appears to have fallen on deaf ears.

Please follow https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct and https://wiki.openstreetmap.org/wiki/Import/Guidelines

It would be a good idea to discuss these edits with the UK community.

Above all please slow down. It is natural for mappers to want to check edits in their area but when automated edits produce vast amounts of dats this can prove overwhelming.

We are all volunteers but some of us have more or less time than others.

Cheers Phil
Taya_S (2026-01-21 17:55:37+00:00): Reverted sockpuppet vandalism

https://www.openstreetmap.org/changeset/177534209
Taya_S (2026-01-22 09:38:17+00:00): Lekker bezig met het omtaggen en opdelen van die grote landuses. Dat moet ik binnenkort ook eens in Zuid gaan doen.
Wanderer2000 (2026-01-23 08:25:27+00:00): Thanks! Eens in de zoveel tijd probeer ik een wijk aan te pakken. Zuid laat ik dan aan jou over :)
czebureks (2026-01-22 01:08:55+00:00): Cześć, dzięki za aktualizację.
Czy przychodnia weterynaryjna przeniosła się ze starego budynku do nowego? Czy też zajmuje teraz oba budynki?
gurglypipe (2026-01-21 22:04:28+00:00): Are you sure it’s the petrol station roof which has the UPRN, and not something else? It seems a bit weird for a roof to have a UPRN.
philipcullen (2026-01-22 13:00:10+00:00): It seemed to be in roughly the centre, so I assumed it was for the forecourt building, but it is possible it is for something else (the road through or the tanks being the most likely candidates).
gurglypipe (2026-01-24 15:56:26+00:00): I’ve reverted this as https://www.openstreetmap.org/changeset/177651865, as we don’t know exactly what the UPRN represents.
Supaplex (2026-01-22 02:12:47+00:00): 不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177534380
Supaplex (2026-01-22 02:12:31+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534383
Supaplex (2026-01-22 02:11:43+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534385
Supaplex (2026-01-22 02:11:32+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534391
Supaplex (2026-01-22 02:11:17+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534392
Supaplex (2026-01-22 02:11:05+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534396
Supaplex (2026-01-22 02:10:55+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534400
Supaplex (2026-01-22 02:10:41+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534402
Supaplex (2026-01-22 02:10:28+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534404
Supaplex (2026-01-22 02:10:17+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534405
Supaplex (2026-01-22 02:10:06+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534409
Supaplex (2026-01-22 02:09:55+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534410
Supaplex (2026-01-22 02:09:44+00:00): 移動的火車上物件並不收錄
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534414
Supaplex (2026-01-22 02:09:14+00:00): layer=1
不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/177534416
Supaplex (2026-01-22 02:08:58+00:00): 不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177534417
Supaplex (2026-01-22 02:08:46+00:00): 不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177534419
Supaplex (2026-01-22 02:08:17+00:00): 不要一個物件上傳一次請不要用非正規編輯器，會跳過不少QA工具的檢核
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177534420
Supaplex (2026-01-22 02:06:31+00:00): Block given: https://www.openstreetmap.org/user_blocks/19629
未回應社群問題與持續上傳問題圖資
1. 上傳到移動的車廂
2. 上傳的AED點位偏差過大，也未在社群回報修正
如果有任何問題，請寄信到 data@openstreetmpa.org
主旨中含 Ticket#2025120310000282 

Dennis Raylin Chen
Data Working Group
[Ticket#2025120310000282 ]
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/177534421
Jordi MF (2026-01-21 18:56:17+00:00): Hola,

Considero que es un error haber añadido algunos nombres locales del camino de Santiago en las vías. La relación con la denominación "Camino de Santiago de Levante" ya está en esta relación: https://www.openstreetmap.org/relation/3624753#map=9/39.150/-1.686&layers=N.

Por otra parte, se han copiado directamente del IGN denominaciones alternativas del camino de Santiago de Levante en las "highway" que forman parte de la relación. Ahora tenemos denominaciones duplicadas y erróneas. Por ejemplo, la siguiente vía (https://www.openstreetmap.org/way/681633385/) ahora tiene la denomianción "Camino del Alba - Camino de Levante". Una búsqueda rápida por internet nos aclara que no existe esa doble denominación conjunta. Nadie denomina a este camino "Camino del Alba - Camino de Levante".

La denominación "Camino de Levante" es una abreviación "Camino de Santiago de Levante".

La denominación "Camino del Alba" hace referencia al siguiente tramo del Camino de Santiago, que ya está añadido: https://www.openstreetmap.org/relation/9554370

En resumen, habría que eliminar todas las denomianciones que ahora aparecen duplicadas en las vías highway.
jamesks (2026-01-21 23:20:07+00:00): Hola Jordi, al contrario, es muy importante mantener los nombres en las vías, y no solo utilizar los relations. Yo he hecho mucho trabajo haciendo relatiines de las vías pecuarias hace 10 años, pero por los usuarios de rendered tiles es imprescindible poner los nombre directamente
Un salud
James