piebro/osm-data huggingface dataset:
Marek-M (2023-01-04 07:11:05+00:00): Cześć, trochę pomieszałeś tagi dla AED - to co dodałeś w access przerzuciłem do description a inne tagi uzupełniłem zgodnie z zasadami na Wiki: https://wiki.openstreetmap.org/wiki/Pl:Tag:emergency%3Ddefibrillator

Tutaj możesz porównać tagowanie AED - wersja 2 jest Twoja, wersja 3 jest po moich zmianach: https://osmlab.github.io/osm-deep-history/#/node/9817097217

Pozdrawiam!
eggie (2023-01-03 19:26:27+00:00): Dag Mart Even gekeken.
highway=pedestrian zal niet kloppen bij die parkeergelegenheid.
Dat routeert niet (voetgangersgebied) 
Je krijgt als je die stroken als parkeerterrein tagt een wijk vil met grote P's. Maak je er parking=street_side van dan worden de P minder prominent weergegeven en zijn het parkeermogelijkheden. 

Ik heb er highway=residential van gemaakt. Het was nog een 'verkeerde' import uit de data kaartenmaker AND in 2007.
Gr eggie
eggie (2023-01-03 19:27:22+00:00): https://wiki.openstreetmap.org/wiki/Tag:parking%3Dstreet_side
Mart01 (2023-01-04 10:21:41+00:00): Hoi Eggie,

Wist niet zeker wat er precies met de highway=pedestrian bedoeld werd en wist niet of ik het zomaar kon aanpassen. Zie nu ook het verschil in grote van de P's. Snap dat parking=street_side er beter uitziet.
Mart
pitscheplatsch (2023-03-04 11:59:29+00:00): Partly revert of https://www.openstreetmap.org/changeset/130833799
pitscheplatsch (2023-03-04 11:59:51+00:00): Thanks, BCNorwich!
VLD515 (2023-01-24 02:09:09+00:00): Based on the local street name sign at the location as well as the correct spelling for 14 in Roman number is XIV and not XIIII, the previous name Gang Tiga Sari 14 was already correct. We need to revert this back to the previous name. Thank you.
Corban8 (2023-01-24 13:53:29+00:00): I apologize for the roman numeral mix up and I agree it should have been written XIV. If I modified the number to roman numerals I did it to follow local convention in the area which seems to be roman numerals. There are often signs with numbers but locals have input those numbers as roman numerals. If the local preference is numbers instead of roman numerals then it is a good idea to make that change back. Thank you for reaching out.
luketaylor (2025-10-06 16:55:33+00:00): How did you determine/verify this cycleway to the west of Edgewater Road between Garrison Ave and Lafayette Ave?

I was here a couple times this week and didn’t see anything to indicate that this sidewalk is supposed to serve as a shared-use cycleway, it looked like an ordinary sidewalk (and was also full of parked cars)
luketaylor (2025-10-06 16:59:13+00:00): just kidding, i see the markings now
TheBestIdea (2025-10-06 17:08:03+00:00): no problem at all. always happy to respond. I surveyed it on Jan 2, 2023. There are signs and sidewalk markings at the ends of the blocks, but cars blocking it is a big problem. Here are some pictures I took: https://imgur.com/a/edgewater-shared-use-path-B91n1PY
aTarom (2023-01-05 18:55:30+00:00): Si us plau ves amb cura amb moure nodes, no t'han saltat uns avisos de
"warnings:crossing_ways:building-highway"
al pujar la edició?
Pots afegir informació dels canvis que fas? nomes surt un punt com comentari
Si tens cap dificultat en quelcom pots aclarir dubtes al fòrum de la comunitat
https://community.openstreetmap.org/c/communities/lang-ca/69
Salutacions
Diacritic (2023-01-04 01:41:24+00:00): Hello,

Clayton North is not a gazetted suburb or locality, and should not be tagged as such.

I have adjusted removed the boundary and replaced Clayton North suburb with a "neighbourhood" node, consistent with official sources.

Regards,
Dian
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/130837753
Dawid2849 (2023-01-06 13:40:01+00:00): Cześć! Widzę, że zmieniłeś klasę drogi DW916 z primary na secondary. Proszę pamiętaj jednak, że oznaczenie drogi wojewódzkiej nie zawsze oznacza highway=secondary. Do oznaczania urzędowej klasy drogi służy znancznik highway:category:pl=* https://wiki.openstreetmap.org/wiki/Pl:Key:highway:category:pl?uselang=pl
Bierphysik (2023-01-17 19:40:02+00:00): Hi. Kannst Du bitte Dir mal https://www.openstreetmap.org/way/1126741510 ansehen? Ich glaube da ist Dir ein Artefakt entstanden oder Du hast was vergessen zu löschen. Das kollidiert volle Kanne mit way 224027285.
Geofreund1 (2023-01-18 05:28:20+00:00): sollte korrigiert sein
bxl-forever (2023-01-04 11:10:05+00:00): Hello,

It is always a good idea to read the history of objects before changing them.

In the previous changeset, a user wanted to reflect the fact that the bridge is temporarily closed to all traffic, after a collision with a boat.
https://www.openstreetmap.org/changeset/130825191

I admit this is a debatable point, because a short term closure should probably not be put on OSM, but let’s assume we want to honour the user’s suggestion of entirely removing this bridge from routing until is open again, hopefully in a few days or weeks.

I don’t know what "correction of tagging to the paths" you tried to make here.  It looks like you are using the iD presets, which generate those silly "designated" values for foot and bicycle.  As a consequence, the bridge is said to be closed to motor traffic (the main road) and open to cyclists and pedestrians (the cycleways, because access=no is parsed first, then foot=designated and bicycle=designated act as "yes").  This creates a non-justified inconsistency.
JhowieNitnek (2023-01-22 13:57:11+00:00): Sorry I will be more careful next time
ivanbranco (2023-01-04 21:10:09+00:00): Ciao Danyzemra,

benvenuto su OSM.
building=casa_vacanze non è il modo corretto di taggare una casa vacanze.

Qua puoi trovare alcuni tag per taggare strutture ricettive: https://wiki.openstreetmap.org/wiki/Category:IT:Tourism

Fammi sapere se riscontri delle difficoltà

p.s. in Italia non tagghiamo gli indirizzi sugli edifici ma come nodi separati
eggie (2023-01-03 19:15:38+00:00): Dag thickness

 operator=RET hoort niet op een bushalte.. Dat staat al op de routerelatie.

MVG
eggie
eggie (2023-01-03 19:18:03+00:00): operator=RET heb ik verwijderd.
Dat staat op de relatie.
Volgens mij is bus=yes ook niet nodig.

MVG
eggie
danieldegroot2 (2023-01-03 19:36:54+00:00): bus=yes is op zich optioneel, ligt er ook aan hoe dicht je een van de bestaande tagging schema's wilt volgen. iD kiest ervoor om bus=yes voor te stellen als het een bushalte betreft. Ook deze soort oplossingen van de bewerker kun je dus negeren wanneer je begint met mappen.
(zeg maar gewoon alle oplossingen.)
syntex (2023-01-03 20:31:47+00:00): ale po co kasować? Zapewne nie zniknie na stałe. Powinny być tagi po prostu zmienione na disused
NorthCrab (2023-01-04 01:34:54+00:00): https://wiki.openstreetmap.org/wiki/Key:destroyed:*

+ damage:type=fire pasowałby jak ulał :P
NorthCrab (2023-01-04 01:36:02+00:00): Chociaż "Destroyed by an event other than intentional demolition", podpalenie raczej było celowe, ale nie intencjonalne ze stron właściciela :D
andrewsuzuki (2023-01-04 01:24:31+00:00): Good to see GLCT on OSM! Would it be possible to split way 1126744314 into multiple ways with their own names? It's a little cluttered with the comma-separated list of names. And there's a similar situation over at Westwoods. Thanks.
GLCTStewardship (2023-01-04 15:18:30+00:00): We really appreciate this feedback.  GLCT has realized the increasing importance in oversight to our properties in the virtual world and is attempting to add property boundary and access information to OSM, and continually review trail information added by the community.  But we're new at this and ignorant of conventions and best practice.  Regarding the ridiculously long area Names:  GLCT manages groups of properties under one particular name (Dudley Barrows Woods or Westwoods), which we associate in OSM as a Relation.  We initially labeled the component properties with a variant of the same name (Westwoods1, Westwoods2), but were advised to choose something distinct ... we chose the name(s) or the prior owners.  On large assemblages of properties, this gets out of hand, but we wanted to stay consistent.  What would you suggest?  We could eliminate the Name entirely and just rely on the Relation.  Or just use an abbreviation/number (WW1, WW2).
andrewsuzuki (2023-01-04 19:36:54+00:00): The norm is to just rely on the one relation and omit the smaller details of the constituent parcels, but at the same time, more information isn't necessarily a bad thing.
I would suggest having individual polygons at least for the parcels with actual names, i.e. "___ Open Space".
Then for the parcels where only the prior owner is known, you can certainly leave them as a conglomeration if it's easier, but move the names to some other tag. I would use the "note" tag, and use a plain english sentence like "Parcels donated by _, _, and_".
https://wiki.openstreetmap.org/wiki/Key:note
If there was a case I didn't cover let me know, or you can also just default to removing the names from the polygons and moving them to the note tag. I just confirmed this with Mashin as well.
Thanks,
Andrew
GLCTStewardship (2023-01-04 23:09:38+00:00): Hi Andrew,
Removing the individual parcel name information seems to work well ... GLCT wants to have users identify our properties by their overall relation name.  But retaining information in OSM makes sense to us ... but we agree it needs to be better labeled.  What do you think about using these tags for this information:

notes:  Property acquired from:  xxx, yyy, zzz

ref:  Property assessor’s numbers: xxx, yyy, zzz

start_date: Property acquisition dates:  xxx, yyy, zzz

(we already use the 'note' tag for property use information)

I've changed the Dudley Barrows woods using this convention.  Do you think this passes muster?  Any other changes you think it needs?

thanks for your help
andrewsuzuki (2023-01-05 01:01:42+00:00): - The way you're currently using 'note' seems like it's aimed towards the end user, but the tag is actually only displayed to other mappers. You might put that info in the 'description' tag instead.
- 'notes' isn't really a standard tag (even among mappers) and it won't be shown to any end user either. It's completely fine to add multiple notes to the standard 'note' tag instead.
- 'start_date' must not contain English like "Property acquisition dates". It should be a single machine-readable ISO8601-formatted date, such as "1991-07-27" https://wiki.openstreetmap.org/wiki/Key:start_date
I'd use the earliest date.
- Similarly, 'ref' shouldn't be plain English. I'd recommend removing the ref tag / assessor numbers altogether. Anyone interested in that can probably go to Guilford GIS or the town assessor instead.
- The child ways shouldn't have the tags that are already on the parent relation. You can remove 'leisure=nature_reserve', 'natural=wood', 'operator', 'opening_hours', and the address tags from the child ways.
- And small note, we had previously been using the operator "Guilford Land Conservation Trust" without the trailing ", Inc.". I'd be happy to switch to it with, but it would be good to switch over the other properties for consistency at some point (no rush).
GLCTStewardship (2023-01-05 16:47:15+00:00): Your comments are eye-openers in many ways, and it's obvious we need to retrench a bit.  Our objective is to convey to end users the extent of our properties as well as provide use and contact information.  Focusing on that is important and we'll continue working on the Dudley Barrows property until it's right and conforms to OSM standards.  Then we'll go back and correct all that's been done to date.  A couple of questions:  we've educated ourselves by looking at other entry's and assumed they were 'right'.  That's why the 'Inc.' was added to the GLCT name.  Is there a single page on the OSM wiki that has an overview for adding a property like we're attempting?  Also ... as we look around we often find additions that appear to have been added either automatically or without much thought (for example:  meadow or woods designations, which are sourced from the University of Connecticut MAGIC database).  These often overlay GLCT properties and adjoining private land, and while not incorrect could easily mislead people regarding access.  Should these be removed or modified once the GLCT property has been added?  And finally, when areas are believed to be wrong or very misleading, what it the best course of action?  Thanks so much for your help.
andrewsuzuki (2023-01-14 05:24:43+00:00): Hi, sorry for the late response!
- On "Inc", you're right, it looks like there was a mix before. The properties in North Guilford seem to have it without the "Inc" at least, as well as Eastwoods. There's no OSM standard for this, I'll leave it to you.
- On UConn MAGIC imports (usually natural=wood), yes there a lot of issues there. The accuracy can be very bad. But the main issue is that while they initially represented nature reserves and open spaces, they were imported in ~2009 with only natural=wood, which by itself only says "this is a wooded area" rather than “this is a protected wooded area”, or “this is a property line”, or anything about access. So somewhat understandably, other mappers over the last decade have sometimes modified these to match the woods better, meaning they no longer represent the property lines as they were originally intended (not that they did that very well either).
The ideal way to map things is to have completely separate elements: one just for the boundary (leisure=nature_reserve), and others for the physical land cover (wood/meadow/water/beach/etc). You can see an example of what I've done over at Lake Saltonstall in Branford. The boundary is self-explanatory, but the land cover often creeps past the boundary into private land, because that's just how it is on the ground. I don’t think access should be assumed either way for physical land cover like meadows/woods unless it has a name or other tags.
For the MAGIC imports, feel free to remove them if they’re too far gone, i.e. not representing either the property or the physical land cover particularly well.
By the way, as a proof of concept, a few days ago I redrew all of the Northwoods boundaries (from a better source than uconn magic!) and did some work on the relations. I hadn’t previously mapped anything like this where there’s a named protected area (e.g. Bluff Head) within a larger named area (Northwoods), and I wasn’t completely sure it would work nicely, but it did. I also wasn’t sure which parcels are part of Bluff Head vs. just part of the larger Northwoods, so perhaps you could let me know or fix it yourself. I assume every parcel north of Quonnipaug is considered part of Northwoods? Anyway, you can perhaps use this as a template for other properties that have named subset of a larger named set of properties.
One more thing. Ultimately the vast majority of end users interacting with OpenStreetMap data for hiking and biking will be doing so through AllTrails and Strava. Unfortunately, I don’t think either of these apps display any information in tags aside from the name.
GLCTStewardship (2023-01-15 15:18:12+00:00): -- Yes, there seems to be a mix of both (the state entries seemed to use 'inc'.), but at your suggestion we're removing the 'inc.'  As we add/check properties, we'll revise to this standard.
-- The approach we're taking is: if the MAGIC additions appear to be drawing GLCT owned property, their entry will be edited to better reflect the actual boundary lines, and tags will be added accordingly.  But if they're flagging a larger woodland (or whatever) area (and that information is largely correct) their entry will be left untouched and the GLCT property will be added as an overlay.  The best example of this is in Hoadley Creek. -- We're working alphabetically by our property name (just did Jared Eliiot) so we'll be heading up to Northwoods shortly.  We consider Northwoods all the GLCT owned land north of Great Hill Road/Quonnipaug and on both sides of Rt. 77.  It's a big area ... the west side boundary is over 17miles in length.  Much of what you've done appears to be spot-on.  (where do you get your property data from?) If you're serious about doing the work yourself, would you like me to send you gpx files to use as templates?  If not, we'll certainly use what you've done as a basis of any editing.   
-- Recognizing there's no control in what other apps take from OSM, we figure that 'ya gotta start somewhere'.  Establishing a presence on OSM is a worthwhile start.  
-- And thanks for the work you've put into accurately adding GLCT properties to OSM.
tbilles (2023-01-03 18:46:24+00:00): Note to reviewer: I'm confident about _what_ I edited, I'm less confident that _how_ I did that is correct. This is my first changeset that modifies and adds geometries. I tried my best, but I'd still like a confirmation! :)
bad_mapper (2023-01-06 09:44:14+00:00): Добрый день! Это не дороги на задворках, дороги на задворках — это дороги за жилыми домами, либо между домами и сараями. В садовых товариществах это жилые улицы, которые имеют своё название.
Необходимо исправить. Спасибо!
MxxCon (2023-01-11 03:35:29+00:00): Hello.
There's bitcoin atm inside of costco?🤨
paydepot's website doesn't show this location. As a matter of fact their website doesn't show ANY locations in NYS, so where is this data coming from?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/130838475
Mb_651 (2024-04-16 22:19:33+00:00): Passt perfekt. Gerne mehr davon!
danieldegroot2 (2023-01-03 19:52:17+00:00): Ja, ziet er naar uit dat ze daar beplanting neergezet hebben. Dit is duidelijk slechts een voetpad, zonder enige logische plek of bebording voor fietsers. De fietsstrook zelf is in zijn geheel verplaatst naar de andere kant van de weg.
https://www.mapillary.com/app/?pKey=1288760338360830&focus=photo
(Mapillary is een bron die is toegestaan voor gebruik in OpenStreetMap, private / copyright bronnen zoals Google Maps/Streetview zijn dit niet.)

Ter informatie: Pas alleen dingen aan als je het zeker weet. Iets wat een voetpad lijkt op de luchtfoto kan nog altijd (bebord als) een fietspad zijn. Als je er recent langs bent geweest om dit na te gaan kan je als bron in je wijzigingenset "survey" toevoegen, of als je er (minder recent) wel langsgekomen bent en dit gezien hebt kan je "local knowledge" als bron erbij zetten.

Bedankt voor de aanpassing.

Groeten,

Daniel
Rainero (2023-01-03 19:39:44+00:00): Hallo muc-osm,

bitte für Packstationen nicht die addr:-Tags verwenden. Für Objekte, die nicht selbst eine Adresse haben, sondern sich in der Nähe einer Adresse befinden, gibt es object: anstelle von addr: mit ansonsten demselben Schema city/postcode/street/housenumber.  
Siehe https://wiki.openstreetmap.org/wiki/DE:Key:object
Gonéo (2023-01-03 21:14:55+00:00): Bonjour Francis, tu as coché la case pour demander une revue du changeset. Les bancs sont bien visibles sur l'imagerie aérienne, je ne vois pas de remarque particulière à faire. Merci pour la contribution.
ma-rt-in (2023-01-03 20:23:55+00:00): Hallo,
was genau hat es sich mit dieser Relation auf sich?
Welche Nutzen hat OSM davon?

vg
ToniE (2023-01-03 20:53:47+00:00): und: wir mappen keine historischen Dinge, schon garnicht historische Grenzen.
highflyer74 (2023-01-04 16:00:33+00:00): Nach Durchsicht sind es wohl drei involvierte Changesets. Bitte nichts an den Daten ändern, um einen Revert nicht unnötig zu erschweren. Danke!
highflyer74 (2023-01-04 16:59:50+00:00): Drei beteiligte neue Relationen entfernt, da ein Revert in mehrere Konflikte lief (https://www.openstreetmap.org/changeset/130874878)
------------------------------------------
Three involved new relations removed, as a revert ran into several conflicts (https://www.openstreetmap.org/changeset/130874878)
ChrissW-R1 (2024-09-08 21:54:20+00:00): Ich verstehe den Disput in den Änderungen, jedoch handelt es sich mit Nichten um historische Grenzen. Klar, offiziell ist Deutschland nicht getrennt. Dennoch gibt es noch erkennbare Unterschiede, in Wirtschaft, Politik und Gesellschaft. Entsprechend gibt es "die alten Bundesländer" durchaus als Region noch.

Auch wenn ich sie nicht wieder eintragen werde, halte ich es auch weiterhin für eine real existierende geografische Information, welche demnach auch berechtigt in OSM ist! Gerne kann dies noch in einem passenden Rahmen diskutiert werden.
silversurfer83 (2024-09-09 03:43:38+00:00): Auch hier: Ungeeignete Quelle
ToniE (2024-09-09 07:18:58+00:00): Der Edit war vom Ansatz her nicht zielführend:

Die heutigen Grenzen der "alten" Bundesländer stimmen nicht (unbedingt) mit deren Grenzen im Jahr 1990 überein. Wenn ich mich recht entsinne, wollte/hat eine Gemeinde in Thüringen "die Seiten gewechselt" und ist nach Bayern "gezogen". Gleiches gilt für alle anderen nicht-innerdeutschen Grenzen auch: Gebietstausch seit 1990 und in der Zukunft.
tomhukins (2024-09-12 12:07:41+00:00): Thank you for improving the map - I have deleted the bar you modified as it seems very likely a mistake.  Please let me know if I made a mistake and I'll add it back: https://www.openstreetmap.org/node/4584150566/history
aachso (2023-01-03 22:46:14+00:00): Hi plennert,

die Einspeisung für die Sprinkleranlage (node 10153169997) befindet sich an der Wand (in typischem Kasten) im Eingang der Tiefgarage unter dem Cineplex. Von dort verläuft das Rohr entlang der Wand nach hinten und verschwindet dann irgendwann nach unten im Boden, wo es vermutlich in einem Versorungsraum weiter unten in der Tiefgarage landet.

Ich würde davon ausgehen, dass damit die Sprinkleranlage der Tiefgarage versorgt wird. Ob damit allerdings auch eine Sprinkleranlage im Cineplex versorgt wird, lässt sich so vermutlich nicht sagen.
erickdeoliveiraleal (2023-01-03 22:21:40+00:00): se nao tem um nome proprio deixe o cmapo nome em branco
erickdeoliveiraleal (2023-01-03 22:22:11+00:00): se nao tem um nome proprio deixe o cmapo nome em branco, porque colocou esses numeros nas paradas?
NorthCrab (2023-01-04 01:37:29+00:00): https://www.openstreetmap.org/node/10303060829
Don't connect real features like landuse to abstractional ones like highways. It's fine to connect landuse with area:highway, but not highway line.
NorthCrab (2023-01-04 01:38:47+00:00): This road doesn't look like minor, it's a simple driveway. Marking roads in Poland:

https://wiki.openstreetmap.org/wiki/Pl:Znakowanie_dr%C3%B3g_w_Polsce
NorthCrab (2023-01-04 01:39:15+00:00): Changed to driveway
NorthCrab (2023-01-04 01:39:41+00:00): Changed to driveway. Don't connect roads to areas.
NorthCrab (2023-01-04 01:40:55+00:00): Changed it to service, I can't really imagine it being a minor/unclassified on a private property.
NorthCrab (2023-01-04 01:41:24+00:00): Changed to service
NorthCrab (2023-01-04 01:41:54+00:00): Changed to service
NorthCrab (2023-01-04 01:42:36+00:00): Changed to service, residential roads are almost never on a private/closed property.
CurlingMan13 (2023-03-01 13:49:17+00:00): Please use better changeset comments.  What did you change, and why?
Patr1k_P (2023-01-05 20:23:30+00:00): cesty a chodniky spajajte s ostatnymi komunikaciami, samotne znacene moc vyznam nemaju

https://www.openstreetmap.org/way/1126754211/history
szalona_entropia (2023-01-04 15:26:04+00:00): A co jest błędnego w analogii?
Yunkers (2023-01-05 05:46:49+00:00): Nie ma w Polsce zasady tagowania dróg turystycznych jako primary - mamy tylko dwie takie do Ustki i Zakopanego. Więc to bardziej wyjątek niż zasada.
Ta zmiana została przedyskutowana na discordzie oraz z lokalsem, który potwierdził drugorzędowe znaczenie drogi.
szalona_entropia (2023-01-06 12:21:58+00:00): No to dlaczego drogi do Ustki i Zakopanego są primary? A skoro one są, to dlaczego droga do Władysławowa nie może być primary? Przecież natężenie ruchu jest na podobnym poziomie, ~14 tysięcy na dobę. 4 razy więcej niż droga do Węgorzewa, która jest primary.
Brak tutaj jest jakiejkolwiek logiki. I co to znaczy, że lokals potwierdził drugorzędowe znaczenie drogi? Jak uzasadnił?
Reasumując - zmiana na secondary jest pozbawiona uzasadnienia w przeciwieństwie do zmiany na primary.