piebro/osm-data huggingface dataset:
felipeeugenio (2026-07-20 21:15:30+00:00): Hola. Esta edición deberá ser parcialmente reversada. El dibujado de edificios es muy deficiente. Además alteró dibujos hechos sobre acantilados para transformarlos en flujos de agua que evidentemente no pasan por ahí. Le rogamos por favor incorporarse al chat de la comunidad para recibir instrucción de como mapear correctamente.

Saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/186075675
MassCartog (2026-07-20 23:19:24+00:00): Hello, welcome to OSM. The feature you removed in this changeset is valid. Please don’t remove valid OSM data.

You have a new account and might not be aware, on OSM, we do not remove features if they exist on the ground. If it exists on the ground, it is valid data regardless of a feature being public or private, designated or informal/illegal/unauthorized. Even decommissioned trails should not be removed until they no longer exist. Removing features that exist is actually considered vandalism.

It's clear that these features still exist on the ground. Not being public access areas is an invalid reason to remove data from OSM. So this edit is incorrect and damaging to valid OSM data.

The correct way to handle this is to use OSM's tagging system. access=private, or access=no would be appropriate if they are closed to the public. Once this is done, services that do use OSM data will reflect that and specify their access.

Please read this for more info:
https://wiki.openstreetmap.org/wiki/Why_we_won't_delete_roads_on_private_property

https://wiki.openstreetmap.org/wiki/Why_can%27t_I_delete_this_trail%3F
silversurfer83 (2026-07-20 21:41:41+00:00): Hi there :)
could you please add the reason for the access=no to the ways you edited using the note=* tag. Also, Wildruhezonen are temporary I think. Am I right?

cheers
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/186076059
user_5359 (2026-07-21 19:35:48+00:00): Hello! What is the mean of the tags
SITUSFULLA = 9859 NW 48th CT
SITUSNUMBE = 9859
STREETDIRE = NW
STREETNAME = 48th
STREETTYPE = CT
?
I assume this is the spelling used in the source. However, in OSM, these do not need to be entered as duplicates of the standard values.
carciofo (2026-07-21 20:13:18+00:00): Hi, thanks again for the heads-up. I've fixed the tagging in changeset #186138596.
felipeeugenio (2026-07-20 19:56:56+00:00): Hola. Por favor cuidar la ortografía. Agregar todos los tildes. Saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/186078290
Jose Luis Infante (2026-07-23 21:56:48+00:00): Hola Victor, gracias por tu aportación, aunque voy a volver a poner el paso peatonal como estaba anteriormente.
Estamos añadiendo las vías peatonales de Badalona, y esta red viaria puede ser tan compleja o más que la circulación de vehículos, por lo que no se puede simplificar.
Te comento que hay diferencia entre highway=traffic_signals, que indica el punto donde hay un semáforo para vehículos (se localiza normalmente donde está la línea de parada del semáforo) y el punto del cruce entre el paso de peatones y la calzada, que en este caso se etiqueta con highway=crossing + crossing=traffic_signals, lo que indica que es el punto de cruce y que el paso de peatones está regulado por un semáforo.
Por último, mi consejo es que antes de editar vías (aceras, calzadas, etc), veas lo que ya hay en OSM, investigues y si hay algo que no tienes muy claro, preguntes, al usuario que lo editó, o a la comunidad local (tenemos grupo de usuarios catalán y español).
Un saludo!
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/186078527
Wildsharky (2026-07-22 12:13:03+00:00): Partially reverted in https://www.openstreetmap.org/changeset/186103221
FroschForscher (2026-07-21 14:58:05+00:00): Jetzt sind es dutzende Kaputte Abbiegebeschränkungen. Das Löchen des via Knoten aus der Relation genügt nicht, es müssen alle Mitglieder (und optional alle Eigenschaften) entfernt werden um eine Relation zu "löschen". Ist in iD etwas umständlich.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/186079247
willkmis (2026-07-21 18:33:07+00:00): Hi there, and welcome to OpenStreetMap! In this edit it looks like you changed Glendon Ave to a private driveway, which I think is a mistake. Is there something else you were trying to do? In the meantime I'm reverting this change.
bookjenny (2026-07-21 20:07:17+00:00): Hi @willkmis,
Thanks for reaching out! I'm local to the property and new to OSM editing.
The issue we're facing is that navigation and rideshare apps are routing heavy through-traffic down this segment, but in ground-truth reality, it functions strictly as a private residential driveway/ingress point rather than a public thoroughfare.
I'm currently discussing the best tagging approach with @OldManCelli via OSM messages to make sure ground reality is mapped accurately without breaking OSM conventions.
If setting access=private on a named avenue isn't ideal here, would changing the tag from highway=residential to highway=service + service=driveway (or adding access=destination) be the preferred way to show navigation engines that this isn't a through-road?
Thanks for helping me get the tagging right!
Best,
Jenny
spatialia (2026-07-21 21:20:13+00:00): Another OSM user here (but can vouch that willkmis knows these things better than I do).

I wouldn't think highway=service is appropriate here, but there may be other ways to indicate to through traffic that it's not advisable to use the road. One way would be to explicitly set speed limits on the road an any nearby roads that a routing engine might be using your street to avoid. If there are turn restrictions at intersections nearby, etc, adding them to reflect the reality in your neighborhood may help re-weight the delivery truck algorithms.

If your street has a "no through traffic" sign, then `access=destination` would keep it as a residential street, but convey that you only use the road if you're headed to a property along it - that also avoids the issues *receiving* deliveries, or having other tools route visitors correctly. But it might cause side effects on Francis Place and McCune Avenue.

Are the trucks coming from one direction? Or bidirectional. I'm wondering if some algorithm thinks this is better than making a left turn at Venice and Overland? But if the truck traffic is both ways, then it may be something else.
willkmis (2026-07-22 02:27:06+00:00): Hello Jenny,
Thanks for explaining the issue in more detail. Coincidentally, I actually used to live right around the corner on Mentone Ave, so I can definitely sympathize with how annoying all the cut-through traffic must be and how jammed up Overland and Venice can get!

I'll echo spatialia and say that Glendon Ave's current OpenStreetMap tagging of highway=residential already communicates that it's a local access road that routers shouldn't favor for through traffic, but is nonetheless a part of the city road network and legally open to the public. So highway=service isn't appropriate, that's for alleyways and driveways and the like, not roads that provide the main access to the buildings along it.

While it's tempting to add access=destination, in OSM we adhere to an "on the ground" principle. So to tag that there has to be a sign, like "No Through Traffic", or a well-known law that prohibits it. I don't think either are the case here.

Really, whichever routers are suggesting Glendon as a cut through to avoid Overland need to penalize leaving a major street more strongly. Helpfully, another OpenStreetMap mapper has just added the existing speed bumps to Glendon: https://www.openstreetmap.org/changeset/186150201. That will hopefully deter any truck routers that use OSM at least, although each system considers slightly different aspects of the roads. And we're no help with Google or other proprietary maps unfortunately.

Hope this helps! And sorry if it's more info than you might have bargained for haha.
Best,
Will
spatialia (2026-07-22 05:16:10+00:00): Just noting I 100% agree on when access=destination is appropriate, but wanted to mention it since it's the closest I can imagine to how OSM would model the real situation - but realistically that requires something to indicate it or enforce it.

I did some research and speed limit tagging nearby in this changeset - https://www.openstreetmap.org/changeset/186156003 - I tagged the default speed limits explicitly so that routers wouldn't make other assumptions and then researched a bit about the speed limits on Overland Ave. I can't find anything remotely about the speed limit on the closest segment, but it looks like north and south of here, it gets to be 35 mph. Hopefully all of this additional information will help a router make better decisions after updating the data.
spatialia (2026-07-28 15:49:47+00:00): Hi @bookjenny,

I was looking at this again, because it felt like we missed something - Glendon still shouldn't be marked as private, but someone else had found your post on Google Maps about drivers cutting through driveways 3746 Glendon Ave, 3744 Glendon Ave, and 3740 Glendon Ave. I don't see driveways for those locations mapped here or in Google Maps, or in a few other private map providers who may sell data to delivery companies. But it got me wondering if there's another way data from these maps can signal drivers should not cut through.

Looking at imagery, I'm wondering if there's a connection through your property in the driveways that drivers are using to get around the one-way segment of McCune Avenue (i.e. going northbound on Glendon, they want to turn right on McCune, but can't, so something routes them through your driveways). Is that what's happening? If so, we can try to help figure out a way to signal they can't do that, though the map *currently* does not allow that either
spatialia (2026-07-28 15:56:51+00:00): Last thought - or is it that they're regularly using your driveway to perform a U-turn to go back out to Venice Blvd?
maro21 (2026-07-20 23:13:16+00:00): Nazwa na stronie www i w mediach społecznościowych nie ma znaczenia. Firma dodaje do nazwy nazwę miasta, żeby rozróżnić hotele. W OSM podajemy tę nazwę, która jest widoczna na szyldzie, czyli w tym przypadku "Park Hotel Diament": https://polska-org.pl/8831270,foto.html
Car162 (2026-07-20 20:03:27+00:00): according to this link: https://www.haifa.muni.il/article/%D7%91%D7%A2%D7%A7%D7%91%D7%95%D7%AA-%D7%A2%D7%91%D7%95%D7%93%D7%95%D7%AA-%D7%9C%D7%A9%D7%99%D7%A4%D7%95%D7%A8-%D7%AA%D7%A9%D7%AA%D7%99%D7%95%D7%AA-%D7%A0%D7%AA%D7%99%D7%91-%D7%94%D7%A2%D7%9C%D7%99/
Hidoo00 (2026-07-22 15:09:54+00:00): If you tried to add a crosswalk, this is completely the wrong way to do it...
StC (2026-07-23 06:42:06+00:00): Bonjour,

ce changeset a brisé la continuité d'un itinéraire pédestre qui passe par là. Je vais essayer de réparer (idem pour d'autres changesets, l'itinéraire étant actuellement brisé en 8 segments)
Max-Kritic (2026-07-23 20:17:01+00:00): Désolé, je n'ai pas vu. Je regarde. Je suis en train de faire des réseaux de bus. C'est quoi. L'itinéraire pédestre en question. J'ai réparé un itinéraire vélo déjà.
eerib (2026-07-20 20:40:34+00:00): Reverted. As previously discussed, creating multiple accounts in an effort to vandalize OpenStreetMap data is unacceptable.

If you would like to explain yourself, you can do so by emailing the Data Working Group, the designated moderation group of OpenStreetMap.

data@openstreetmap.org
kadiwa (2026-07-21 12:25:20+00:00): Gemeint war note/5407374
ajmat (2026-07-22 09:44:42+00:00): Partially Reverted in https://www.openstreetmap.org/changeset/186167535
ajmat (2026-07-22 07:08:35+00:00): Reverted in https://www.openstreetmap.org/changeset/186160134
dopfen (2026-07-22 20:39:26+00:00): Hi,
ich habe den in diesem Changeset entfernten Briefkasten (node/12190265391) wiederhergestellt, da der Briefkasten lediglich auf dem Peter-Plümpe-Platz verschoben wurde:
changeset/186199716
karitotp (2026-07-20 21:43:07+00:00): Hola!
Veo que dos intersecciones de calles fueron arrastrados haciendo que las calles pierdan sentido. Entiendo que puede ser un error involuntario que se dió al seleccionar nodos de calles mientras se hacía otro tipo de ediciones. 
Tratemos de revisar los cambios realizados antes de guardar nuestras ediciones. 
Saludos.
Dodko (2026-07-21 09:40:43+00:00): Aký dôvod bol na vymazanie adresy Dostojevského 13435/1A?
simonc11 (2026-07-20 23:03:16+00:00): are there any sources for the bridge name, I'm not finding any, and my own limited research comes up with a caravan park nearby https://cheddarbridge.co.uk/
simonc11 (2026-07-20 23:32:03+00:00): ok, I've found a source
dknelson9876 (2026-07-22 03:20:40+00:00): Hi cbmiller2610, thanks for your contribution and welcome to OSM! There's certainly a lot of buildings left to fill in around here. 

Please note for future edits that OSM prefers expanding all abbreviations to avoid ambiguity (e.g. "Ln" -> "Lane"). For more info read up about at https://wiki.openstreetmap.org/wiki/Abbreviations
Juneau Trail Runner (2026-07-21 18:35:38+00:00): This is my first Open Street Map edit so any tips are welcome.  I did follow up with an edit to the bridge to more accurately show it's length and location.
LordGarySugar (2026-07-21 18:13:19+00:00): amazing refining ❤️ #REVIEWED_GOOD #POSMCha
A67-A67 (2026-07-25 10:32:15+00:00): Het is beter om dit juist wel te herhalen voor fietsers en dit is ook hoe we het standaard taggen in Nederland.

We hebben veel eenrichtingswegen die niet eenrichting zijn voor fietsers en soms ook voor bromfietsers. Door dit expliciteit te taggen, maken we onderscheid tussen straten waarbij dit niet is uitgezocht (alleen oneway=no) en waar dit wel is uitgezocht (oneway:bicycle/mofa/moped ingevuld).
AJCHurkens (2026-07-25 19:15:46+00:00): Prima om dit expliciet te taggen voor wegen met het bord "eenrichtingsweg" zodat duidelijk is of er een onderbord is met uitzondering voor (brom)fietsers. Uit testen met onderstaande overpass-turbo query maak ik op dat meestal niet expliciet getagd wordt bij "eenrichtingswegen" als gevolg van rotondes of verkeerszuilen:

[bbox:{{bbox}}];
way[oneway=yes][!"oneway:bicycle"][highway!=motorway][highway!=motorway_link][highway!=cycleway][bicycle!=no];
(._;>;);
out;
eerib (2026-07-21 06:25:38+00:00): Hello salalsalad,

The best practice for unsanctioned trails is to not delete them but instead to mark them as informal=yes and to add any legal access restrictions such as bicycle=no, foot=discouraged, etc. etc. The rationale for this best practice is available in the following wiki page.

https://wiki.openstreetmap.org/wiki/Why_can%27t_I_delete_this_trail%3F

Thank you, eerib
alpacaMaps (2026-07-21 03:30:04+00:00): This edit appears to be incorrect, like many of your past edits.
Loopslol7 (2026-07-20 23:19:21+00:00): Proper description of this changeset:

Specifying count of hoops.
eggie (2026-07-21 06:57:00+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
dknelson9876 (2026-07-23 23:19:11+00:00): Unfortunately, as part of previous mapping, I've discovered that UTA removes a stop from their published datasets when it is not in service, but if a stop in a similar location gains service in the future, the stop code may be reused. Like you, when I didn't yet know this, I left a fixme=* on all the out-of-service stops. To make it easier to keep stops up to date going forward, I am now inclined to just delete out-of-service stops from the map (regardless of what the wiki says about keeping out-of-service stops as long as there's still physical evidence). What do you think?
tjasz (2026-07-24 15:22:13+00:00): That's tricky. For these on 39th, I was intending to go check for physical evidence, but I can't do that for the whole system. Maybe a "disused" lifecycle tag is appropriate for the ones where they are not in service but the most recent available imagery still shows physical infrastructure?
dknelson9876 (2026-07-24 22:36:38+00:00): Yes, I suppose disused:*=* is a good place to start for stops that are no longer serviced
Rngrk (2026-07-21 02:28:00+00:00): Please keep changesets local.
Rngrk (2026-07-21 02:29:45+00:00): https://wiki.openstreetmap.org/wiki/Changeset#:~:text=References-,Geographical%20size%20of%20changesets,-General%20recommendation%3A%20changesets
SamuelRichter (2026-07-21 15:30:59+00:00): I'm sorry, won't happen again
Mustlane (2026-07-20 23:47:23+00:00): Deeply sorry, but I *just* realized that [these](https://i.imgur.com/zeNYQKf.png) ways should have been marked as `area=yes`.
VictorIE (2026-07-27 11:56:28+00:00): Thanks again for the help on this.
alpacaMaps (2026-07-21 03:30:03+00:00): This edit appears to be incorrect, like many of your past edits.
simonc11 (2026-07-21 00:52:02+00:00): I don't think you should remove them unless you will replace them with better. In my opinion no building is worse.
LordGarySugar (2026-07-21 02:19:07+00:00): It has been discussed on the linked forum thread that these buildings were effectively imported from microsoft/BuildingFootprints with zero quality control - there are numerous examples of buildings of shambolic quality that were imported. This counts as an undiscussed import and therefore there's no obligation for me or any other mappers to clean up on behalf of the person that added them in the first place. As many of these buildings are terraced or semidetached houses anyway, the ai footprints don't represent individual houses anyway so the data is pretty worthless. It just gives the impression of a completed map, which removes the incentive for people to map actual high-quality buildings. Please raise any further thoughts you have in the thread. I will be happy to engage in any conversation there and has the benefit of being visible to all those who have shared their views already.
Wereldkaart123 (2026-07-21 00:20:19+00:00): Woonerf + eenrichtingsverkeer: zie https://zoek.officielebekendmakingen.nl/gmb-2025-67851.html

Situatieschets: https://zoek.officielebekendmakingen.nl/gmb-2025-67851-1.jpg
pwbriggs (2026-07-22 06:04:22+00:00): Yes, highway=path is kind of a strange tag. I think it's supposed to be always paired with access tags that describe what modes of transport are allowed to use it (and thus, in a sense, what kind of "path" it really is). I think highway=track is probably good here as well, though I'm not familiar with this place.
rajdhani (2026-07-22 09:51:42+00:00): Reverted in https://www.openstreetmap.org/changeset/186167839
Wereldkaart123 (2026-07-21 00:27:44+00:00): https://amersfoort.notubiz.nl/document/17060844/1/540859+Het+wijzigen+van+de+straatnaam+van+een+klein+gedeelte+van+de+Utrechtseweg?
synthfi (2026-07-21 00:29:03+00:00): oh the bounding box is huge. See where Main Street meets Auburn Road
keithonearth (2026-07-26 03:19:04+00:00): I wasn't sold on the idea of mapping the Cambie Street bus lanes as a busway, but visited to intersection today, and think it makes the most sense.
in2itivity (2026-07-26 23:20:02+00:00): Yeah, when I visited during the preparatory works I originally mapped this segment as a single 6-lane road, but after seeing it in its finished condition I decided to map the central busway separately. It feels like the kind of thing where if it *were* permanent, it would have some sort of physical barrier.
TheSwavu (2026-07-21 03:19:38+00:00): Hi,

Welcome to OSM. Just to let you know:

1. Address components beyond street are optional. See https://wiki.openstreetmap.org/wiki/Australian_Tagging_Guidelines/Australian_features#Addresses Not putting them in cuts down on the number of errors that you might make. For example these had the suburb name in all caps.

2. You don't need to repeat the address as a name tag. In fact names should not de descriptions. See https://wiki.openstreetmap.org/wiki/Names#Names_are_not_for_descriptions

I have fixed these ones.

Happy mapping.
Topiours (2026-07-21 15:09:46+00:00): 杭州2503已於近日停止服務，然而iD最近疑似無法刪除巴士路線，請您協助進行刪除（還有蕭山的2006M），多謝！
Herman Lee (2026-07-27 09:15:35+00:00): 最近没时间确认，只进行维护，等下有时间再删除。
felipeeugenio (2026-07-21 13:12:58+00:00): Estimado. Estamos todavía intentando arreglar todo lo que hizo. Provocó un problema bastante grande con la integridad de las costas y casi la totalidad de lo que hizo tuvo que o ser reparado o borrado por su bajísima calidad. Le pedimos por favor un poco de respeto hacia la comunidad de maperos e integrarse y aprender como hacer bien las cosas.

Le agradecemos.

saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/186090345
rajdhani (2026-07-23 04:57:24+00:00): Partially Reverted in https://www.openstreetmap.org/changeset/186212578
synthfi (2026-07-21 01:19:42+00:00): agh, apparently connecting the service road to another point on the turner boundary caused the changeset to be big
rajdhani (2026-07-22 09:24:57+00:00): Partially Reverted in https://www.openstreetmap.org/changeset/186166515
CAM-Gerlach_Repair (2026-07-21 16:29:11+00:00): Hi T Nguyen,

The tag diet:local=* is considered a tagging mistake https://osm.wiki/Key:diet:*#Possible_tagging_mistakes as a restaurant food being "local" does not directly relate to dietary restrictions and is instead an aspect of cuisine=*, and "local" is very non-specific--better to be specific about _what_ local cuisine is actually served. While your cuisine=* tagging is already very detailed, if you feel something isn't yet captured there you can add it.

I fixed this (along with the much more critical issue from changeset 186091398) in changeset 186126046

https://osm.org/changeset/186126046
CAM-Gerlach_Repair (2026-07-21 16:28:58+00:00): Hi T Nguyen,

Thanks for adding more detailed tagging to this road. However, there's a very critical issue here--you changed it to be a pedestrian path (highway=path) rather than an actual road, so the tags you added don't actually make sense and it breaks vehicular connectivity.

I restored it to highway=residential (along with the less critical issue from changeset 186091372) in changeset 186126046

https://osm.org/changeset/186126046
Ruthless78 (2026-07-24 19:59:46+00:00): Thanks for adding this!
TheSwavu (2026-07-21 05:33:02+00:00): Hi,

I noticed you put an addr:floor in the address for w147396425. I have checked their website and it doesn't match what they say. Also if building:levels=1 then they really can't be on the second floor.

addr:floor is only for cases where the address contains a floor description.

I have fixed this one.

Happy mapping.
RJ Lerng (2026-07-23 11:55:00+00:00): Thank you very much for keeping an eye on the tags and fixed the one for me! 

I totally agree with you that the addr:floor tag should not be there since the building has only one level and the clinic occupies the entire building.  Therefore, even the "level" tag is redundant and can be removed as well.

I only remember I had manually added three tags for that clinic: toilets=yes, toilets:wheelchair=yes, changing_table=yes because "Every Door" does not provide those in its preset. 

The only thing I could think about is that I must has touched some buttons provided by the user interface of "Every Door" whilst typing on other fields.  RJ
RJ Lerng (2026-07-28 11:08:15+00:00): Observations:

I added a few car park entries to our map the other day and noticed that not only the "level" tag but also the "addr:floor" tag was added by the "Every Door" app since the City of Perth designated the level of the entry as "Level 1" at it entrance. I had to manually remove that floor tag myself. RJ
MappingMore (2026-07-23 07:05:38+00:00): Reverted in  https://www.openstreetmap.org/changeset/186216669