piebro/osm-data huggingface dataset:
woodpeck (2026-05-16 21:15:07+00:00): After this edit, there are now two objects representing the same beach - one area and one point. It would have been better to add the "dog=yes" tag to the existing beach. Using the "name" tag to describe the properties of the beach is not a good idea.
Harvesterify (2026-05-18 20:28:32+00:00): Cette portion est pourtant bien notée comme D24 sur Route 500, quelle est la source du changement ?
erwanlevieux (2026-05-18 21:43:52+00:00): Bonjour, j'ai commis une erreur mais sur route 500 cela ne semble pas bon non plus. Il y a plusieurs sources discordantes et 3 itinéraires suivant les différentes sources. En tout cas la RD24 ne passe plus par la place du général de gaule depuis 1972 environ. Ce soir, j'ai été éclairé en conseil municipal et ce qui prévaut c'est bien l'affichage indiqué sur géoportail : La D24 rejoint la D152 par la rue des canaux.
erwanlevieux (2026-05-18 21:55:07+00:00): Je viens de modifier. Est-ce qu'il faut d'autres éléments de preuve ? 
En tout cas , on m'a confirmé que le tracé sur geoportail est le bon et non pas celui de maps, ou d'openstreetmap.
felipeeugenio (2026-05-17 13:18:40+00:00): Buena edición. gracias.

eso si por favor no realinear todo. Las fotos satelitales son muy circunstanciales. En realidad no sabe si la que está viendo está mejor alineada que lo que está.
saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182758424
eggie (2026-05-16 20:39:39+00:00): Dag Sirolv, Maar geldt dat ook voor tweewielers? Duie zijn meestal uitgezonderd en die categorie routeert nu niet meer.
oneway:bicycle=no ???? en ook voor moped en mofa.
MVG
eggie
eggie (2026-05-16 21:04:05+00:00): Is er nog wel sluipverkeer nu het knooppunt grotendeels gereed is?
Sirolv (2026-05-16 21:20:37+00:00): Inmiddels verbetering gesubmit, zie https://cuatro.sim-cdn.nl/waalwijk/uploads/korte_termijnmaatregelen_waspik_8_feb_2023_0.pdf?cb=rQffTsTT onderste slide voor de exacte bebording
eggie (2026-05-16 21:23:46+00:00): 👍
Glassman (2026-05-18 19:42:33+00:00): You might want to change the wooded area to landuse. See https://wiki.openstreetmap.org/wiki/Land_use for more info.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182758456
b-jazz (2026-05-17 02:42:22+00:00): RE: https://www.openstreetmap.org/way/1514850558, et al

As I mentioned in http://osm.org/changeset/181789189, fairways and greens shouldn't be overlapping like this. Please make sure you read the wiki in my previous comments. If you have any questions, I'd be happy to help. Thx
yelisey90 (2026-05-19 21:07:46+00:00): partly rv - it's 4 level from the side street

https://www.openstreetmap.org/changeset/182899520
Mister Kanister (2026-05-18 17:19:58+00:00): Sorry, I think your tagging with old_name:* is actually wrong here. You are designating a boundary=region named Appenzellerland, which in my opinion is a different thing than the historic Kanton Appenzell, even though the two entities overlap completely. If you want to have this relation to reflect the region 'Appenzellerland' as it is known today, I think you should remove the old_name tags, and if you want the relation to represent the historic canton, you should change the boundary value to something like 'historic'. But having both concepts in one relation, as it is now, seems wrong to me.
Mister Kanister (2026-05-18 17:21:57+00:00): The same goes for your tags for Wikidata, Wikimedia Commons and Wikipedia, which refer to an entity that is different from the HLS/DHS article you are linking to.
9_tab (2026-05-19 12:05:03+00:00): Thanks for the heads-up! 

I got the impression we generally wouldn't have multiple relations with identical borders (admin_level=3 lacks TI and ZH) or I haven't encountered them in this area. It's possible that other websites (like the ones you mention) handle this differently or have a historic focus. I doubt there is another feature that could have this old_name.

From https://wiki.openstreetmap.org/wiki/Key:boundary#Boundary_types it looks like "place" is the better value for this key. I should change it to that.
Mister Kanister (2026-06-23 14:16:10+00:00): > I doubt there is another feature that could have this old_name.

That's not the issue here, in my opinion.

> It's possible that other websites (like the ones you mention) handle this differently or have a historic focus

Well, of course websites have different angles. But as soon as you added different websites to this OSM element, you merged those perspectives together, making a statement that they describe the same thing, namely https://www.openstreetmap.org/relation/20694323, the region "Appenzellerland". Which is not the canton that existed from 1513 to 1597, but you still refer to the HLS/DHS article about that entity.

Which is why it does not always make sense to blindly link to websites that describe an entity with the same name (and, in this case, similar geographical extent) as an entity in OSM, like here. The (German) wikipedia article for "Appenzellerland" (https://de.wikipedia.org/wiki/Appenzellerland) makes the same point: Appenzellerland, as in this relation, is a geographical term, describing a region, but for referring to the (historic!) political/administrative entity that overlaps geographically, "Kanton Appenzell" is used instead.

Sure, nitpicking, but which better place for nitpicking than OSM.
9_tab (2026-07-25 10:00:09+00:00): > you merged those perspectives together.

Isn't that natural? Maybe I misunderstand the point of having https://wiki.openstreetmap.org/wiki/Key:alt_name and https://wiki.openstreetmap.org/wiki/Key:old_name . Depending on the context, time period and focus, different names are used for a region with a given spatial extent. Also the name can change over time. We should try to generalize the region type.

If the article https://de.wikipedia.org/wiki/Appenzellerland had a section about the history of the region, it would include most of what is now in "Kanton Appenzell" or what HLS/DHS writes about. HLS/DHS/DSS usually writes about administrative areas, thus the cut-off. I don't see a problem with using its key on this feature. Nobody can guarantee any possible interpretation. HLS/DHS/DSS will always be about the history of a place with a cut-off somewhere in the past.

If you need a separate relation for your purposes, please feel free to create it. Splitting it just to match Wikipedia isn't desirable and potentially an endless quest, in my view. Even having three distinct relations is conceivable. Please share your view on how to map these.
OSM_RogerWilco (2026-05-17 08:25:09+00:00): I have reverted this changeset. Please follow the guidelines for mechanical/automatic edits.

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

https://www.openstreetmap.org/changeset/182771356
Fabian Hevessy (2026-05-17 08:42:10+00:00): Hello. This was not an automated edit. I just updated some info for the six (6) GLS Bank branches located in Germany. I would kindly ask you to reinstate my changeset.
Fabian Hevessy (2026-05-17 08:46:16+00:00): Correction: 7 GLS Bank branches in Germany (Bochum, Berlin, Frankfurt, Freiburg, Hamburg, München, and Stuttgart).
OSM_RogerWilco (2026-05-17 10:23:17+00:00): Kannst Du bitte begründen, warum dies keine automatische Bearbeitung ist? Hast Du jede Bank selbst vor Ort geprüft? Welche Quellen hast Du verwendet?
Fabian Hevessy (2026-05-17 10:56:45+00:00): Hi, it's not an automated edit because I manually updated some of these bank branches' info manually with (as you can see) the iD editor.

I took the info from the GLS Bank website. If you take a look at my changeset the info I added/updated are things like:
• The "website" tag: A few branches didn't have one listed, others had a link to a now broken webpage. For all bank branches I added the webpage on the bank's website with info about that particular branch.
• The "operator" tag: A few branches didn't have that info, so I added it taking it from the bank's website.
• The "opening_hours" tag: these too are available on the GLS Bank website.
• The "branch" tag: Many didn't have one, so I added it.
• The "addr:" tags: some branches didn't have that info, which was (again) available on the GLS bank websites.

I could've added my sources when I uploaded the changeset, I'll leave them below instead:

https://www.gls.de/gls-bank/ueber-uns/standorte/bochum/

https://www.gls.de/gls-bank/ueber-uns/standorte/berlin/

https://www.gls.de/gls-bank/ueber-uns/standorte/frankfurt/

https://www.gls.de/gls-bank/ueber-uns/standorte/freiburg/

https://www.gls.de/gls-bank/ueber-uns/standorte/hamburg/

https://www.gls.de/gls-bank/ueber-uns/standorte/muenchen/

https://www.gls.de/gls-bank/ueber-uns/standorte/stuttgart/
OSM_RogerWilco (2026-05-19 07:10:18+00:00): Thank you for your detailed reply. If you are simply copying data from other sources, we refer to this as an ‘automated edit’. This should be discussed with the community beforehand. We also need to clarify whether we are permitted to copy the data from the website.
NorthCrab_upload (2026-05-16 23:11:06+00:00): 🗺️ Witaj na OpenStreetMap!

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. Jeśli adres ma nazwę ulicy, upewnij się, że jest ona poprawna. Jeśli nie, usuń addr:street, a nazwę miejscowości przekaż w addr:place.
https://www.openstreetmap.org/node/13837736589

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
Kovoschiz (2026-05-17 08:16:49+00:00): Don't draw every desire line. This is walking on the roadway. The `highway=secondary` already covers it.
bigmanbusman (2026-05-31 02:22:08+00:00): what does that mean
kingkingHK (2026-05-31 04:46:36+00:00): Which word do you not understand?
TheSwavu (2026-05-18 10:42:18+00:00): Hi,

Does the new cycleway really stop at n13539754816?
aharvey (2026-05-18 12:54:10+00:00): As of 2026-04-23 it did, I'm not sure if it's changed since then. They built https://www.openstreetmap.org/way/1515000255 as a ramp to join the road.
nevw (2026-05-17 02:00:57+00:00): Hi, you have misunderstood the opening hours format. e.g. Mo-We 09:00-17:00, 19:00-21:00; Th-Fr  09:30-21:00; Sa 10:00-18:00; Su off
nevw (2026-05-17 02:03:49+00:00): i.e. days hours; days hours; days hours
jmapb (2026-05-17 18:47:34+00:00): (see comments at https://www.openstreetmap.org/changeset/138391273 and https://www.openstreetmap.org/changeset/182755922)
rajdhani (2026-05-19 04:15:16+00:00): Partially reverted in changeset id: 182859617
Cloud 2185 (2026-05-17 00:44:11+00:00): Not certain on ambiguity of devices
Glassman (2026-05-18 19:20:51+00:00): #TIP: the changeset comment should match the edit.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182763719
Glassman (2026-05-18 19:30:39+00:00): I reverted this back to just a park which fits the definition of county records. If there is a dog park within, just add the polygon area. Let me know if you need help. I'll send more info on OSM in a message.
.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182763783
SomeoneElse_Revert (2026-05-17 01:08:22+00:00): This changeset reverts some or all edits made in changesets 182732597, 182733334, 182733683, 182735586, 182736518, 182736893.
felipeeugenio (2026-05-17 13:03:00+00:00): Hola. Forest es cuando son bosques de cultivo. Estos a lo mas son natural=wood.
Y aún así, tres arboles no son un bosque. Ahí había que dibujar los árboles por separado nomás (natural=tree). Yo lo corrijo
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182764294
NE2 (2026-05-17 22:58:31+00:00): This part of 146 has driveways and should not be highway=motorway.
felipeeugenio (2026-05-17 13:00:13+00:00): Hola. Hiciste pasar el cerco por encima del camino y de las plantaciones de palta. Ahí lo arreglé. Pero porfa más atención al detalle.
gracias
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182764532
b-jazz (2026-05-23 16:23:51+00:00): Hey there Hogmite,
I've removed these pins as that isn't the right way to map golf courses. Arbitrary markers like this to help you measure distances isn't an appropriate use of OSM.
Hogmite (2026-06-12 21:30:31+00:00): There is no policy that I have found in OSM that prohibits it. Stop deleting my work.
Hogmite (2026-06-12 21:32:49+00:00): In fact, the Wiki even discusses using the "pin" to indicate the location of the hole. All I am doing is indicating the front, middle and back pin positions.
Hogmite (2026-06-13 02:54:15+00:00): The correct action you should have taken is to say “there is a particular format you should use. Here it is.
Please revise your inputs to align with the standard.” Rather than just deleting someone’s efforts without giving them an opportunity to edit their work. The only nay standard I saw was Golf=pin which I used and then tagged additional information to that pin. What I was doing was far more useful to users than putting a boundary around a green, fairway, or hazard. People have pinned  trees that not a soul cares about but you just deleted my efforts because golf courses make you “noxious“.
b-jazz (2026-06-13 03:39:23+00:00): There is a basic adage about "mapping truth" or "map what is on the ground".

You are putting pins where they don't exist. Never have and never will. The virtual pins marking the front and back of the green shouldn't be mapped and will be removed. It's as absurd as marking every pin placement that has ever existed in a given green.

If you want to know the distance to the front of the green, figure it out mathematically and write your own golf mapping app that downloads a course, analyzes the features and can display that. But creating something out of nothing is not the correct thing to do.

If you want to challenge this, I'd suggest you bring it up in the various OSM communities (Slack, IRC, mailing lists, Discord, etc.). If you have a problem with me deleting what is arguably wrong, you can approach the data working group and see if you can convince them.

So, please follow the particular format that has been established and revise your inputs to align with the standard. Thanks.
Hogmite (2026-06-15 21:58:59+00:00): What is absurd is someone who knows nothing about golf and obviously holds an animus towards the game thinking they have a clue what they are talking about. Marking the front middle and back of greens is a STANDARD practice for any golf app. To compare it to marking EVERY pin location is asinine. Your statement of creating something out of nothing makes no sense. You say it is arguably wrong but I say it is arguably right and sense I am the golfer here I think I know better than you. I have looked at all the various things people pin and saw "rug-beating" and you are going to argue with me that pinning the front middle and back of a green is absurd?! I have contacted someone and await their response but everything you say flies in the face of what the OSM Wiki says. Just because something doesn't make sense to YOU doesn't mean it is wrong. Get over yourself.
b-jazz (2026-06-16 00:27:46+00:00): Let's dial it back a bit Hogmite. You start off with 3 false statements in your first sentence. This doesn't strengthen your argument. Let's see if we can achieve some compromise instead of throwing insults around.

Your rug beating POI argument doesn't really help your case. I'm assuming there is some community place where you can bring your rug, hang it up and maybe use some shared rug beating implements to get rid of built in dust from your rugs. That is something that should be mapped. I was unable to find anything on the map with that tag. Could you please share it with me? I'd love to check it out.

Back to the pins though. I'm not a fan of marking the center of the green as a pin either, but at least that has some history in actual golf course maps from golf courses/clubs/resorts. I don't know the actual numbers, but a quick sampling of maps just now had about 40% of the "hole" lines ending in a pin, while the rest just had a line ending in the middle of the green. To mark the front and backs of a green though with a pin is incorrect as there just isn't a pin there.

The logical place to put this data wouldn't be nodes on the map, but instead tags on the golf=hole way. There is already a dist(ance) tag (https://wiki.openstreetmap.org/wiki/Key:dist) that can be extended to show other information like distance from certain tee colors. You could do something like "dist:front_of_green=123" or "dist:red:front_of_green=123" or something like that. You'll get much less pushback than putting in arbitrary nodes on the map. Is that something you'd be willing to explore?
Hogmite (2026-06-16 01:42:30+00:00): Now that you dialed it back I will as well, nobody likes their efforts being called absurd I think we can agree on this.

Let me explain how I am trying to use this information. As a golfer who has used many golf apps, I am continually frustrated by modifications that take away features I like and add features I don't care about. I ran across a web based app that used OSM. I was intrigued so I investigated and discovered what I thought was perfect for what I wanted to do, make my own app. Not for profit, just for me and my buddies to use.

I used Claude AI to help me build the app and suggest how to pin OSM. Which I did. I received feedback from another mapper who stated the way I used Slope and Rating of the golf course in a way already used and suggested an alternate way to input that information and I immediately changed it as suggested. I also looked at the Wiki for golf tags and found it lacking in usefulness in that the only way to get what I needed was to use the "golf=pin" feature and then I added additional tags underneath that tag to further identify what hole the pinned feature was on and what kind of feature it was i.e. Front Middle Back of the green, hazards, target landing areas, etc. The reason I needed to pin these features is because that is the only way I can have my app use gps to know where I am and therefore the distance to the feature of interest. I know of no other way to do that.

If there is a concern about having structure and consistency in the pinning process I am more than willing to develop, monitor, or just use whatever is decided. I have a passion for golf and think providing this kind of data for golf courses would be extremely useful to the golfing community. 

And let me assure you, there absolutely is a way to pin rug beating locations (man_made carpet_hanger A construction to hang carpets for cleaning with the help of carpet beaters.)

I am signing up to the Tasking Manager to see if I can find a group to get involved with and if I can't find a group I will investigate starting one. Any advice you can give would be appreciated, even though we have initially not seen eye to eye I see that you have been doing this for some time.

David
b-jazz (2026-06-16 02:29:35+00:00): You're saying a few things that make the hair on the back of my neck stand up. 

First is that you are developing an app just for you and your buddies to use, but in the process you're making changes that are visible to the entire map using community. You need to be aware that making changes can have a rather large impact on the rest of the community and these changes should be thought of carefully and discussed with the community.

Second, you're using A.I. to help with these decisions. I'm not afraid of AI, but I'm fully aware that it is no panacea and doesn't fully understand how the world works and will often steer you in the wrong direction. This is a big red flag.

You're talking about recruiting a bunch of others to help apply your design decisions across a large swath of golf courses. You might want to slow things down a bit and get buy off before you go that route. You just started mapping a month ago and now your talking about making some major changes on a large scale. Another red flag.

What you might consider is using OSM as a base layer and then adding whatever your heart desires as a layer on top of that. Your changes would exist in your own database layer that you control and manage and you would have the final say in. This would leave the OSM layer unchanged as the vast community needs to rely on something stable and well defined.

Another thing to consider for your app is that you could do the front/back of green calculations dynamically. You/AI would write an algorithm that would figure out where the golf=green way intersects with the golf=hole line and generates you a front of green measurement. It could also programmatically extend the golf=hole line through the far side of the golf=green way to determine the back of green distance. You would instantly get the information for every golf course in the world without having to recruit an army of mappers to make questionable edits to the base map in OSM.
GA_Kevin (2026-06-16 03:22:18+00:00): Hey y'all! Happy to see that golf courses continue to get attention in OSM! I have fond memories of sneaking out after course closing and before dusk to get a few holes in as a kid, so much so I live on a golf course now! I also have tried tackling disc golf (not as fun to me -- don't tell the local teams!) and disc golf mapping.

Anyway... mapping! b-jazz is right that we don't have the concept of forward and backward green positions as tags on OSM. You can of course create ATYL, but position is likely not the best tag for that. A separate discussion perhaps if you're passionate about it.

The good news is it is easier than getting everyone everywhere to start adding these, you can today for any hole calculate with the centerlines and golf=green how far away the closest node on the green is and the furthest (pin is already wherever it is - also queryable). I think the only logic you'd really need to take is to follow the centerline until the last node before the green so it is as the hole is designed not as the crow flies distance.

If you're keen on joining a group, I would welcome you to join the OSM US Slack, https://slack.openstreetmap.us/ there's even a #golf and #tagging channel to join to discuss all things golf maps. I think you'd enjoy it!

Ive also used Claude/OpenAI to do mapping things, it's quite powerful (we have an #ai channel too) and helpful when making custom maps with existing data!

-- Kevin (GA_Kevin)
rajdhani (2026-05-18 07:47:38+00:00): Partially reverted in changeset id: 182816388
diamondarmorsteve (2026-05-17 02:38:42+00:00): Road names from National Address Database, refs from WV DOT (https://wvdot.maps.arcgis.com/apps/dashboards/2fcc9ecbaa5f486384e906365725c5cf)
eggie (2026-05-17 05:36:43+00:00): Welkom bij OSM,

Bedankt voor uw bijdrage. Het is eigenlijk gebruikelijk om bij te taggen op de bestaande adresnode en ook een shop tag toe te voegen. Bv shop=yes.
Mvg
eggie
eggie (2026-05-17 07:07:53+00:00): Als bovenstaand aangepast
Relax-Time (2026-05-17 23:32:39+00:00): Dank jullie wel !
BubbaJuice (2026-07-29 04:09:32+00:00): Hello Roads_AZ44(2),

I am reverting this changeset. This ramp was moved in construction and how I mapped it before your changeset reflects reality.

Thank you,
BubbaJuice
felipeeugenio (2026-05-17 12:51:59+00:00): Hola. Hicieron un puente por sobre el canal? Por ese puente pueden pasar autos?
Solo para verificar. Gracias
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/182765644
sebadark (2026-05-17 23:54:48+00:00): Hola buenas si efectivamente hicieron un puente y se puede pasar con vehículos
ajmat (2026-05-19 06:32:05+00:00): Reverted in changeset id: 182862671
Baloo Uriza (2026-05-20 23:12:21+00:00): So this is a private path that's open to the public if they're on foot?
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/182766067
truemarmalade (2026-05-21 00:23:08+00:00): Nope fully private. I set all access to private, did that not update?