piebro/osm-data huggingface dataset:
jumbanho (2023-09-12 17:12:38+00:00): Thanks for improving the mapping of the trails along the river.  I think some of the parts of the main trail where you have two separate ways (one cycleway and one footway) may actually be better represented as one way using cycleway=yes, foot=designated, segregated=yes as noted on the wiki: https://wiki.openstreetmap.org/wiki/Key:segregated
gvwaal (2023-09-13 01:44:16+00:00): Hi jumbanho, it's cool to find someone interested in the same things I am! Just so we're on the same page, you're talking about how I split footpaths out from the cycleway, like how way#911885632 diverges from way#911885631 near the intersection of 38th Ave S and West River Parkway?

If you are, I began splitting out footpaths approximately where the paths diverge in reality. Where the footpath is directly attached to the cycleway, separated only by paint, I tried to preserve a single way with highway=cycleway+bicycle=designated+foot=designated+segregated=yes; and where the footpath diverges, separated from the cycleway by soil, I tagged the footpath as highway=footway+bicycle=no and the cycleway as highway=cycleway+foot=no. Not only are the paths literally separated, that's also what the path markings specify.

In this specific example, the segregated=yes tag is unnecessary on the cycleway north of this intersection, and I see how that may be confusing. I'll need to remove it from the paths I edited.
Enock4seth (2023-09-03 20:01:58+00:00): Hi, when you map buildings please remember to press Q to make them squared
gscholz (2023-09-04 06:26:11+00:00): Hi Tuler,
this changeset has created errors the OSM database regarding self intersecting and overlapping ways:

https://tools.geofabrik.de/osmi/?view=geometry&lon=-60.06193&lat=-3.11150&zoom=13&baselayer=Geofabrik%20Standard&overlays=self_intersection_ways%2Cself_intersection_points%2Csingle_node_in_way%2Cduplicate_node_in_way

This kind of error irritates routing software and looks ugly on toe maps.

Can you please fix this? You may also like to educate yourself about how to edit bus routes properly:

https://wiki.openstreetmap.org/wiki/Buses

Kind regards
Guido

https://overpass-api.de/achavi/?changeset=140738908
gscholz (2023-09-07 06:10:16+00:00): Hi Tuler,
due to your missing response I have reverted this changeset to fix those issues.
Guido
corfede (2023-09-04 15:06:45+00:00): Ciao Fedurli, con riferimento a questo landuse residenziale https://www.openstreetmap.org/way/1204554960 non è opportuno che lo stesso sia collegato alla viabilità, alla ferrovia e quant'altro, ma dovrebbe essere separato dal resto. Inoltre invece che essere collegato a sé stesso attraverso una fascia di larghezza zero, può tranquillamente essere spezzato in due o più poligoni.
citrula (2023-09-10 13:04:03+00:00): You can press "q" with an object selected to square its corners :)
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140739357
cserpell (2023-09-03 13:59:46+00:00): Yo sé que la categoría de un camino no tiene que ver con el ancho o calidad de éste, pero es raro ver un trunk en la zona central para un camino que a ratos es como cualquier camino rural ancho.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140739494
jptolosa (2023-09-04 15:21:40+00:00): Pero desde hace tiempo se está trabajando para mejorar considerablemente su estándar físico. Independiente de eso, ninguno de los otros caminos rurales de la zona similares en aspecto físico cumple con la función de ingresar a la Zona Central.
solenoid jam (2023-09-11 19:01:34+00:00): Hola.
Noté una designación muy extraña para los árboles en esta edición, que no sigue las reglas aceptadas.
Ahora estoy corrigiendo errores en la designación de árboles y no entiendo el significado de las etiquetas que usaste. Dado que es posible que los datos que proporcionó sean valiosos si se corrigen, le sugiero que lo haga. Si no se hace esto, no serán comprensibles para otros cartógrafos y consumidores de datos, y tendrán que eliminarse por ser inútiles.

A continuación señalaré los errores:
- circumference = *m
No es necesario especificar la unidad de medida (m), ya que OCM utiliza metros de forma predeterminada.
También es un error si especifica valores demasiado grandes, por ejemplo circumference=51. La razón es la misma: 51 metros es demasiado.

- "name = *"
Este es el PROPIO nombre del objeto. Ni su especie o taxón, ni su número de serie. Es como el nombre de una persona.
Para especificar el número de secuencia utilice "ref = *"

- denotation = *
Esta es una descripción opcional de la relación del árbol con el paisaje o de cómo lo utilizan los humanos.
En este caso, la denotación correcta = park, o algo similar.

Puede que los siguientes símbolos le resulten útiles:
height=* - altura del árbol en metros
    circumference=* - circunferencia del tronco en metros a una altura de 1,3 m sobre el suelo
diameter_crown==* - diámetro de la copa del árbol
crown_type=* - forma de la copa del árbol (véase la tabla)
height_trunk=* - altura del tronco en metros

========================

Здравствуйте. 
Я заметил очень странное обозначение деревьев в этой правке, которое не соответствует принятым правилам. 
Сейчас я занимаюсь исправлении ошибок в обозначении деревьев, и мне не понятны значения тэгов использованных вами. Поскольку, возможно, данные указанные вами могут быть ценными, если их исправить, то я предлагаю вам это сделать. Если это не сделать, то они будут не понятны другим картографам, и потребителям данных, и их придётся удалить как бесполезные.  

Ниже я укажу на ошибки:
- circumference = *м 
Не нужно указываьть единицу измерения (м), поскольку по умолчанию в ОСМ используются метры.
Так же является ошибкой, если вы указываете слишком большие значения, например circumference=51. Причина та же - 51 метр это слишком много.

- "name = *"
Это имя СОБСТВЕННОЕ объекта. Не его вид или таксон, и не порядковый номер. Это как имя человека.
Для указания порядкового номера используйте "ref = *"

- denotation = * 
Это опциональное описание особенностей связи дерева с ландшафтом, или того как оно используется человеком.
В данном случае, верным будет  denotation = park, или что то подобное. 

Возможно вам будут полезны следующие обозначения:

height=* — высота дерева в метрах
    circumference=* — окружность ствола в метрах на высоте 1,3 м над землей
    diameter_crown=* — диаметр кроны листвы дерева
    crown_type=* — форма кроны дерева (см. таблицу)
    height_trunk=* — высота штамба дерева в метрах
solenoid jam (2023-09-11 19:08:56+00:00): También merece la pena leer estos dos artículos para mejorar la calidad de los datos:

https://wiki.openstreetmap.org/wiki/ES:Tag:natural%3Dtree

https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Tree_table
Road doesn't exist (2023-09-03 01:26:21+00:00): Decided to add back in small area of driveway. Doing so now.
Kevin Wallace (2023-09-03 10:41:01+00:00): I don't have a dog in this fight (I just noticed it in recent changes), but I would like to point out:

https://wiki.openstreetmap.org/wiki/Why_we_won%27t_delete_roads_on_private_property

I don't plan on unilaterally reverting without further community input, but I believe this edit violates OSM policy.  The correct approach is to keep the driveway fully mapped, but with access=private.  I'm sorry people are trespassing on your property, but OSM maps what exists on the ground, not what property owners want us to map.
Glassman (2023-09-03 14:54:02+00:00): Please note that RCW 46.04.420 states "Private road or driveway" includes every way or place in private ownership and used for travel of vehicles by the owner or those having express or implied permission from the owner, but not by other persons." Not as you stated in the changeset comment. Since this road exists, I'd recommend adding it back with the tag access=permissive
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140740217
VictorIE (2024-08-03 12:14:51+00:00): Hi,

How come you have removed ref=N5 ?

https://wiki.openstreetmap.org/wiki/Tag:junction=roundabout?uselang=en-GB

Reference tags: For roundabouts that have ways either continuing through, or ending at the roundabout, ref=* and int_ref=* tags from those ways should be added to that roundabout if roundabout is also part of that routes.
mackerski (2024-08-03 12:47:13+00:00): It’s a while since I read the wiki entry for roundabouts and those entries are fallible like the mappers who write them. It has always been my view that a roundabout is a junction and a neutral space. Where they have names, it is a name specific to the roundabout itself. Occasionally they have actual references (can’t spot any just now). In such cases, I would tag these on the roundabout. But in the typical case, if you follow what is on the wiki, you would end up tagging potentially many refs separated by semicolons. To me, this produces a negative outcome. Roads in Ireland don’t multiplex numbers, so you often see interruptions to an N or R route as they join another whose number is used for that section. So to add several refs to a tiny road section is futile. The rendering experience happens to be poor, but of course that can be solved by fixing the rendering. I find it fine to have the roundabouts as members of all relevant route relations (not that we tend to use those). Anyway, that’s why I tag roundabouts as I do, noting that I too am just a fallible mapper. I’m happy to see the topic discussed so we can work out norms that best serve the outcomes we want.
VictorIE (2024-08-03 13:05:19+00:00): Sorry, I meant to include the ref: https://www.openstreetmap.org/way/1136499987

1. It isn't tagged as a roundabout.
2. There is no risk of a multiplex number here, as the R309 ends here.
3. It's obvious to a human that the N5 runs straight through the roundabout. For a SatNav, as there is no ref, it is going to try to pronounce a name it can't pronounce.
mackerski (2024-08-03 13:30:27+00:00): 1. It is now. The history shows that it has never had that tag, so clearly the original mapper of the new roundabout missed it and so did I.

2. A rare case, indeed. In this instance, there really is no path around the roundabout where N5 would be potentially wrong at any point of the roundabout. The principle of whether roundabouts should be tagged with the ref of one or more of their participating roads should probably still apply here, so it remains interesting to consider what that principle should be.

3. It's good to look at SatNav as a use case, but I don't buy this specific argument. You most definitely wouldn't want a SatNav in the general case of joining a roundabout to give an instruction like "turn left onto the N5 [context: you hadn't been on it already], drive 15m and then turn left onto the R678. What you would want is "enter the roundabout and take the third exit to the R678". The traveller's awareness of the roundabout in such a context should always be of "the" roundabout, because they have encountered exactly one roundabout and there is no need to distinguish it from others. Further, that instruction that the third exit leads to the R678 should ideally favour not the ref tag of the road that is being joined there, but probably (again, I'm open to discussion on this) any "destination" tagging that is in place, since that ought to reflect the route number and place name(s) provided on the sign the traveller will see when approaching that exit, providing greater reassurance.

On (3), have I overlooked some condition where having a ref tagged on the roundabout itself provides for better routing instructions? It may be better to consider a more general use case where at least 2 routes transit the roundabout on either side of it.
mackerski (2024-08-03 13:41:32+00:00): I've remembered where I saw roundabouts with actual refs of their own - it's in Kilkenny on the original ring road: https://www.openstreetmap.org/way/934089599 

I'm not an enormous fan of how the council has applied refs like that to the roundabouts, but it's a clear case of something that should be tagged onto the roundabout itself. Further, such tagging is in conflict with the idea that a transiting road ref could be recorded using the same tag, as now you could be tagging two different kinds of fact with the same tag. This is kind of the dilemma we already have for named bridges that occur along a named road or, to some extent, for named terraces along named roads.
johnny_1982 (2025-04-15 20:37:28+00:00): Es gibt in OSM ein Schema für Briefkästen. Diese haben ein "ref", keine Adresse. 
Info siehe hier: https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dpost_box

Ich habe die "ref" von node 4209690673 wieder repariert.
RSydes (2023-10-02 06:42:25+00:00): Correction: the "nature preserves" (Russel M. Duffin; Doris Westfall Prairie Restoration, Forest Glen Seep, and Howard's Hollow Seep) are owned by Vermilion County Conservation District, but are also part of the Illinois Nature Preserves System (https://dnr.illinois.gov/inpc.html).
CurlingMan13 (2023-09-18 01:51:08+00:00): Please use better changeset comments.  What did you change and why?  Good changeset comments are important.  You can read more here:

https://wiki.openstreetmap.org/wiki/Good_changeset_comments#:~:text=A%20good%20changeset%20comment%20should,have%20edited%20on%20the%20map.
JesseFTW (2023-09-03 13:45:22+00:00): Why did you change the ref= to Fairmount Line rather than leaving it matching the gtfs:ref=CR-Fairmount ? I'm open to using that naming, but I'm not sure what the value is in having that inconsistency (and I changed it to match per a suggestion from someone who works at the MBTA, on their GTFS data).
KevinMapsThings (2023-09-03 13:52:41+00:00): I'm actually about to revert it after noticing that PTNA didn't pick it up.
KevinMapsThings (2023-09-03 14:25:22+00:00): For future context, I had originally made this change because the sample trips associated with the commuter rail uses the `route_long_name` as the reference instead of the `route_id` that we would normally expect. That appears to be definitely wrong so I've reverted it in another changeset.
JesseFTW (2023-09-03 14:35:30+00:00): Ah, interesting! I'm not sure I know where the "route_long_name" value you are referring to is. And PTNA can pick up whatever ref= value is desired, we just need to update https://wiki.openstreetmap.org/wiki/MBTA/Analysis/MBTA-Routes to match.
felipeeugenio (2023-09-03 13:53:32+00:00): Hola Edgardo. gracias por corrar el dumplicado. Sin embargo el que dejaste tiene un horario distinto del qué borraste.
Cual es el correcto?
saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140740688
StefanHRT (2023-09-03 02:30:35+00:00): Autowerkstatt zusätzlich auf das Gebäude gesetzt, damit man sieht wo die Werkstatt ist.
Unbeatable101 (2023-09-29 21:32:09+00:00): Hi jtracey, why did you remove the junction names without replacing them with the destination tag? Especially since people often refer to these junctions by the name of the street they go to, this seems like removing good info to me
jtracey (2023-09-29 22:45:30+00:00): The destination goes on the way, not the node (since the node contains both/every way, i.e., is on the highway, so it isn't clear which "destination" it would be referring to). See the wiki for more info:

https://wiki.openstreetmap.org/wiki/Tag:highway=motorway%20junction?uselang=en#Destination_of_the_exit
jtracey (2023-09-29 22:46:20+00:00): Oh, if it wasn't clear, the ways do already contain the destination, that's why I didn't add it. I tried to be careful and make sure that was always the case, feel free to let me know if I missed any.
Unbeatable101 (2023-09-29 22:49:48+00:00): Alright, sorry for the misunderstanding
jtracey (2023-09-29 22:50:35+00:00): Sorry for so many replies, but I should probably also mention that this was discussed a few times on the Canadian mailing list, and there was consensus every time that these tags should be removed from junctions, as is done everywhere else.
bradnak (2023-09-03 03:26:01+00:00): I have left some sections I'm not sure about, things may have changed since I graduated
felipeeugenio (2023-09-03 13:47:35+00:00): Hola Carlos
el tag building es para los edificios y construicciones en un recinto, no para el recinto completo.
saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140741671
Carlo5V (2023-09-03 20:13:08+00:00): Ok, me equivoqué, gracias por la corrección :)
felipeeugenio (2023-09-03 13:38:21+00:00): Hola. Por favor no pegar las plazas a los caminos.

Le pedimos por favor no usar nombres genéricos (https://wiki.openstreetmap.org/wiki/Names).
Si hay locales, agregar los puntos uno por uno con sus respectivos nombres. gracias
felipeeugenio (2023-09-03 13:42:05+00:00): una duda: cuál es el objeto de agrandar las plazas unos metros mas? Es claro en las fotos satelitales que no llegan hasta ahí.
saludos
joel56dt (2023-09-03 16:18:43+00:00): Hi ocwl, I am wondering what you intended by crossing=pedestrian_signals. I don't see this tag value documented anywhere.

This crossing does not have any signals, just flashing lights. Vehicles must stop regardless of the flashing lights if pedestrians (or bicycles) are present. I believe crossing=uncontrolled is most accurate.

Thoughts?

Thanks,
Joel
ngry_pazuzu (2023-09-03 22:39:39+00:00): "pedestrian_signals" is one of the options in the drop-down menu that the editor at https://openstreetmap.org. It seemed like a better representation of the signals there than "traffic_signal". I now see that the value is not documented, which is surprising since the editor offers it.

Using "uncontrolled" is a misrepresentation, because the documentation states that it means "only road markings" which is not the case here. There are flashing lights, which serve an equivalent function to a pedestrian controlled traffic signal.
Andreas Binder (2023-09-03 19:06:29+00:00): Hi Stephan, vor Ort war/ist die Hausnummer 72 ausgeschildert und die würde für die Oberaustraße nicht passen. Grüße Andreas
Andreas Binder (2023-09-03 19:13:59+00:00): Es müsste die "Äußere Münchener Straße" sein
Stephan-Hartl (2023-09-04 08:09:25+00:00): Dann war die Straße vor meiner Änderung schon in zweierlei Hinsicht falsch. Eingegeben war die äußere Oberaustraße, und die ist es jedenfalls nicht ;-)
Andreas Binder (2023-09-04 10:33:16+00:00): Ja, die "Äußere Oberaustraße" war definitiv vorher schon falsch und war vermutlich ein Schreibfehler von mir selbst :-( sorry. Ich ändere die Adresse bei Gelegenheit auf die "Äußere Münchener Straße"
felipeeugenio (2023-09-03 13:43:00+00:00): Hola. Building es para las estructuras dentro de un recinto, no para el recinto completo.
gracias
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140742453
aTarom (2023-09-03 06:20:07+00:00): Hola Xevi, em pots confirmar que està bé el tag
"guard_rail"="30"

https://www.openstreetmap.org/node/8808694930/history

gràcies per editar salutacions
Xevi (2023-09-03 06:44:45+00:00): No, de fet m'he equivocat, el volia posar al barrier. Ara ho canvio, gracies per avisar
literan (2023-09-03 10:41:39+00:00): addr:housename это тег, когда адресация по названию дома (например если адрес "Деревня Ивановка, Дом Гореловых"). В Москве такого нет. Так что перенесу в name, наверное. Это же название ЖК?
solenoid jam (2023-09-05 09:35:12+00:00): да, ок
Mateusz Konieczny (2025-05-14 13:31:21+00:00): Hello! https://www.openstreetmap.org/node/11164358728/history has amenity = fixme that was added in this edit
What kind of object is here? Is it a shop? What kind of a shop? (see https://wiki.openstreetmap.org/wiki/Key:shop )
i2004 (2023-09-03 10:42:10+00:00): te complete toda la linea 283
AgusQui (2023-09-03 15:13:59+00:00): Ok. ¿Vas a seguir mapeando la 98?
i2004 (2023-09-03 16:46:51+00:00): ya te mape el recorrido hacia once dle ramal 116
Lostmonkey (2024-03-30 16:04:20+00:00): Sletter bro igen. Den var ikke en fejl, at den var fjernet. Erstattet af ny bro (som allerede er tilføjet lige nord for).
Hufkratzer (2023-09-03 22:09:56+00:00): Hi,
hier gleiches Problem wie bei https://www.openstreetmap.org/changeset/134601817 diskutiert.
Das leisure=horse_riding könntest du an https://www.openstreetmap.org/way/93603157 verlegen, so wie es z.B. bei https://www.openstreetmap.org/way/689504266 verwendet ist.
changchun_1 (2023-09-04 05:45:07+00:00): korrigiert
ottwiz (2023-09-03 06:30:23+00:00): + Bing aerial imagery at a point (as a source, i forgot to add)
Oscarjw (2023-09-10 20:16:07+00:00): Not sure how useful, accurate the benches are ?
NorthCrab_upload (2023-09-03 07:00:20+00:00): Zauważyłem, że Twoja zmiana zawiera adresy wymagające dodatkowej uwagi. Przygotowałem listę obiektów oraz dodatkowe informacje:

Nazwa ulicy nie istnieje w okolicy.
https://www.openstreetmap.org/node/11164427743
https://www.openstreetmap.org/node/11164427744
https://www.openstreetmap.org/node/11164427745

Pozdrawiam! 🦀
eggie (2023-09-03 07:47:46+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht. 
MVG, 
Eggie 
namens de OSM Community
kubahahaha (2025-06-10 12:24:18+00:00): A co zrobić z adresami w takim układzie?
ivanbranco (2024-08-23 13:16:00+00:00): Hi Hana, 

what's the meaning of natural=kankaniyar kulam here: https://www.openstreetmap.org/way/1204589492 ?
literan (2023-09-03 10:50:26+00:00): только ref, а не name. Поправлю.
Piagno (2023-09-06 15:51:01+00:00): Hi, please move the stop position to the new place.
See https://www.openstreetmap.org/note/3866471
Piagno (2023-09-07 09:31:25+00:00): Thank you :D
eggie (2023-09-03 08:14:58+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht. 
MVG, 
Eggie 
namens de OSM Community
eggie (2023-09-03 08:19:06+00:00): Dag lc,

Is dit sinds kort?
Om welk type fietspad gaat dat hier. G11, G13, G12a?
De straatnaam heb ik weer toegevoegd.
MVG
eggie
eggie (2023-09-03 08:16:32+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privébericht. 
MVG, 
Eggie 
namens de OSM Community
Luzandro (2023-09-03 12:16:39+00:00): Hi,

I've reverted this changeset because neither is the river Schwechat (rel 9600737) fully inside the forest area (rel 1271459), nor is it a closed way but a mulitpolygon as well

https://wiki.openstreetmap.org/w/index.php?title=Relation:multipolygon
Bienengasse (2023-09-03 20:14:15+00:00): Hi Luzandro, thx for checking, may I ask you to correct this that the river does not have the forest symbols as overlay? br Gebhard
Luzandro (2023-09-04 06:45:25+00:00): for the parts where the river is only mapped as a small way it's not possible to prevent OSM Carto from rendering it that way, but you can argue in that case the river is covered by trees most of the time, so while unusual, the rendering isn't actually that off

https://github.com/gravitystorm/openstreetmap-carto/issues/4485

to some degree this also applies to the parts, where the river is a little bit wider and mapped as area, but since the forest doesn't have a name or must necessarily be kept a single object for some other reason, I can look into splitting it into smaller, more manageable parts, separated by the river
spughetti (2023-09-03 10:33:46+00:00): Hi retypepassword, welcome to OpenStreetMap!

A node already exists for Babes Ice Cream, if you want to update the business info please modify the already existing node. You can find the node here.
https://www.openstreetmap.org/node/11151910451

I've reverted this changeset, you can find my revert here.
https://www.openstreetmap.org/changeset/140751803

Don’t hesitate to reach out to me if you have any questions!
empty_child (2023-09-03 10:12:58+00:00): Max Lozovsky, добрый день
Точка уже существует и вы ее добавили не на то здание
ڕاستی (2023-09-04 20:32:47+00:00): Hello little_mapper
Why you taked out the node: 11160038403 and 11160038363 from WAY: 1204060095 and 1204060094.
And shorten crossing footway (WAY: 1204060083) to just between the w1204060070 and w555794510.
Regards
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/140746885