piebro/osm-data huggingface dataset:
b-jazz (2025-03-22 06:39:28+00:00): Re: https://www.openstreetmap.org/way/1370057429

Hello golf course mapper. The lines that define Fairways and Greens should never intersect or partially overlap each other and we noticed that they are overlapping in one or more of the fairway/green pairs in this changeset. If there is no obvious fringe around the green, the fairway should butt up against the green and every node between them should be *shared*. If there is a fringe around the green that is similar to the fairway, the fairway should extend around the green and the two objects should be merged together into a multipolygon (See http://wiki.openstreetmap.org/wiki/Relation:multipolygon for how to create them with your map editor).  Please read the wiki for instructions and examples of how to better map golf courses: http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgolf_course#Common_mapping_pitfalls. If you have any questions, please reply here and I'll gladly help clarify things. Thanks!
jeholtman (2025-03-22 17:11:08+00:00): I appreciate the info.  I can make my changes to the fairway and green not overlapping.  The problem I run into is when you do the inner and outer multipolygon, my mapping software will not bring in the green, and because of this, the green will not roll like a green when simulated.  I guess in the future, I will just make another fairway attached to the green, and tie green and fairway points together.
b-jazz (2025-03-22 20:25:18+00:00): I understand that might be a problem, but we need to conform to the standards and norms of OpenStreeMap and do things the proper way there and not try to work around it due to a bug or shortcoming of 3rd party software.

Can you let me know what software is causing this problem for you? I've heard of some software not handling multipolygons correctly, but they eventually updated their software to fix that problem. Have you tried updating to the latest version?
I'm not sure what you mean exactly when you say you will make "another fairway" attached to the green. Most of the cases there will just be the single fairway that connects to the green and shares the border nodes. Hopefully that is what you meant.
jeholtman (2025-03-22 22:31:10+00:00): I am mapping golf courses for the software package of TGC2019 for simulation purposes.  Just trying to map the courses in the area.

When I use lidar files to underlay the openstreetmap data, it creates the layout of the course with the proper elevations, along with green and fairway.  I am using opensource software that was created to marry the lidar and map data called chad's tool.  I have updated to the latest version of the tool.  I have watched many videos of other people that use the same software, and overlap fairway and greens all the time.

I am pretty new to GIS systems, and don't know exactly how mapping a golf course messes with any other data in the maps.  I guess once i map a course, I no longer need the data, so I could delete out the course data if it causes problems.  Just nice if someone else wants to use it for the same thing.

I noticed that someone else is editing another course in the area, and is doing it the way that you are talking about with mulipolygons.  I want to create the course in my software, but don't want to delete their data to input my own.

What software are people using to import the multipolygon fairways/greens that you are talking about?  Just curious if other software pulls the data in differently.
b-jazz (2025-03-23 18:15:33+00:00): >people use the same software and overlap fairway and greens all the time.

Yes. And that's really bad. OpenStreetMap is a community sourced repository of all sorts of map data and there are tens of thousands of contributors and millions of users of the data. We need to all be careful to behave as a community and not stomp on other contributor's hard work. Using OSM as a scratch pad by doing some work and then deleting the data is hugely problematic and could lead to you getting banned. It's better to all work together, follow OSM best practices, and come up with a solution and stop bad videos and other instructions from recommending these bad habits. Your instinct to not delete someone else's work to do your own way is right. I'm putting in hundreds of hours to work cleaning up this mess and to have someone come behind me and wreck it again is incredibly frustrating.

I did take a look at Chad's Tool and saw that there is work to get multipolygons/relations working correctly. There is a pull request (https://github.com/chadrockey/TGC-Designer-Tools/pull/143) that is just a week old that might solve your problems. If you could help by giving voice to the issue and applying pressure to getting this code implemented, that would be appreciated.
aceman444 (2025-10-26 22:01:06+00:00): Zdravim, aky ma zmysel pridavat sposoby platby na cele obchodne centrum? Snad kazdy obchod moze prijimat ine sposoby platby.
aceman444 (2025-10-26 22:11:23+00:00): A preco ste znicili jednotlive budovy, z ktorych sa OC sklada?
A preco ste zrusili kvalitnejsie udaje a nahradili bodmi bez udajov, ako napr. Tesco? Trochu pozerajte co robite.
Vinber-Pro (2025-03-21 18:01:31+00:00): Bonjour,
et merci pour ces contributions !

Au niveau de l'écriture la "bonne" pratique est plutôt d'écrire Gendarmerie de Fanjakana et pas tout en majuscule.

Dans le cas d'un doute sur un positionnement, on peut aussi ajouter un attribut fixme=Check position

merci pour toutes ces nouvelles gendarmeries !
Vinber-Pro (2025-03-21 18:03:37+00:00): et vous avez beaucoup de géolocalisation approximative, cela signifie quoi ? Vous avez quelles sources pour ces ajouts ?
T Ral (2025-03-24 09:35:30+00:00): Bonjour,

Merci pour votre message et vos précisions.

Nous sommes deux doctorants malgaches en économie du développement, basés à Paris. Dans le cadre de notre thèse, nous travaillons sur l’effet de la présence des forces de l’ordre sur la criminalité à Madagascar en 2015.

Pour le géocodage des postes de gendarmerie, nous nous appuyons sur une liste officielle datant de 2015. Nous avons également croisé ces informations avec des décrets officiels et des faits divers dans la presse locale afin de confirmer l’existence effective des postes.

À ce stade, nous n’avons pas encore géocodé tous les postes à l’échelle nationale. Nous avons priorisé ceux situés dans les districts inclus dans notre base de données.

Pour les "localisations approximatives", nous sommes quasi sûrs (au vu de nos sources) qu’il existe un poste de gendarmerie dans le quartier, mais nous ne connaissons pas son emplacement exact. Dans ce cas, nous avons généralement placé le poste à côté du bureau communal (ce qui est souvent le cas). Sinon, nous avons coché la case "vérifier l’emplacement" dès que nous n’étions pas sûrs.

Nous avons vu que vous avez également un projet sur Madagascar — ce serait un plaisir d’échanger davantage.

T. Ral & A. Rab
Vinber-Pro (2025-03-24 11:32:14+00:00): Bonjour,
avec plaisir pour échanger oui !

c'est un super projet que vous avez là.

Sans vouloir vous freiner dessus, quelques questions cependant :
- avez vous ouvert une page wiki pour expliquer cela ?
- quel partage avez vous fait avec la communauté sur ces ajouts ?
- vous seriez dispo pour une visio ?

bonne cartographie
NorthCrab_upload (2025-03-21 17:51:01+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Duplikat adresu w okolicy. Adres można oznaczyć na dwa sposoby: na obszarze (dokładniejsze) albo na punkcie. Aktualizując adres, należy się upewnić, czy w okolicy nie pozostały żadne duplikaty.
https://www.openstreetmap.org/node/9407071816
https://www.openstreetmap.org/way/1353904571

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! 🦀
frydzio (2025-03-21 20:04:01+00:00): Cześć,
Ten numer na geoportalu odnosi się do starych zabudowań na działce. Nowe numery nie zostały jeszcze nadane - miałyby je wszystkie budowane budynki.
MCC_ZET (2025-03-21 20:32:50+00:00): dzięki
Tom van Dijk (2026-07-14 09:49:26+00:00): Beste A67-A67,

Er staat op de deur dat je voor de openingstijden naar de website toe moet. Moeten we dan opening_hours wel mappen? Of hoopt u gewoon dat de openingstijden toch min of meer gelijk blijven.

Mvg,

Tom
map per (2025-03-22 20:03:03+00:00): Danke, hab den Bus-Halteplatz (stop_position) auch noch verschoben
BubbaJuice (2025-03-21 22:22:50+00:00): See more: https://en.wikipedia.org/wiki/O%CA%BCodham_language
aTarom (2025-03-26 14:36:06+00:00): Please,
https://wiki.openstreetmap.org/wiki/Good_changeset_comments
SomeoneElse (2025-03-23 11:51:45+00:00): Probably not an obelisk lol...
As ever with these, the answer seems to be "actually a bit more complicated than that".  Wikipedia describes it as a "navigation beacon": https://en.wikipedia.org/wiki/Chaldon_Hill , elsewhere https://trigpointing.uk/trig/8861 it's an "Admiralty Navigation Beacon".  It's certainly a beacon in the "you can see it from afar" sense, but whether it ever had a basket of burning wood attached I've no idea.
There are lots of OSMers in that general area and/or with a historic interest in these sorts of things - perhaps ask in the UK forum?
NeisReview (2025-03-21 18:28:31+00:00): #NameCheck

Hello and welcome to OSM.

Thank you for your contributions to the map. I have reviewed your recent edits, particularly those concerning the names you've added or modified.

Some of these names caught my attention as they are quite unique or a bit unusual. Could you please confirm if these additions were intentional or if they might have been added mistakenly?

Looking forward to your response.

Thank you!
NeisRevert (2025-03-28 20:44:36+00:00): This changeset has been reverted by https://osm.org/changeset/164226284 where the changeset comment is: 
Remove vandalism
Kees 59 (2025-03-22 11:12:53+00:00): Are you sure about the historic=monument? monument is described as "A memorial object, which is especially large (one can go inside, walk on or through it) or very tall". And node 1840038725 definitely does not comply with that.

I believe historic=memorial is better suited for this one. With memorial described as "Small memorials, usually remembering special persons, people who lost their lives in the wars, past events or missing places"

See also https://wiki.openstreetmap.org/wiki/Tag:historic%3Dmonument#Warnings
SomeoneElse (2025-03-22 13:00:23+00:00): https://www.openstreetmap.org/way/817805457/history looks like it should have been sanity-checked out of this change too.
quincylvania (2025-03-22 13:53:57+00:00): Thank you both for the review. I've fixed those features per your comments.
Kees 59 (2025-03-22 14:59:04+00:00): Hi again. It might be a good idea to go over this changeset. I picked out 2 changes. One because it rang a bell. I taught I came by the word in the wiki and one because of a weird, at least to me, name.

The first one is https://www.openstreetmap.org/node/2168561999 With the name Cenotaph. If it is what the name says then it should probably be tagged "    historic=memorial + memorial=cenotaph". See https://wiki.openstreetmap.org/wiki/Tag:memorial%3Dcenotaph

And the other one is https://www.openstreetmap.org/edit?node=6030845583 (name=The phone booth The Phone Booth". To me it looks to small to be a monument in the OSM meaning. it is on an islet next to a tree. And it also has the tag "tourism=artwork". It might still be some kind of memorial but I can not identify that with the information available.

P.S. The description of monument at the landmark key https://wiki.openstreetmap.org/wiki/Key:landmark is quite different from the one with the historic key :(
hatul (2025-06-04 09:43:29+00:00): reverted

https://www.openstreetmap.org/changeset/167169634
Fizzie-DWG (2025-03-23 05:41:31+00:00): Please see https://www.openstreetmap.org/user_blocks/17438
Nathan_A_RF (2025-03-30 22:37:21+00:00): Hi, I've updated the maxspeed:type tags to the correct value for 60 mph. If you need a guide for the tags to use, the wiki has the appropriate tags listed. Cheers!
https://wiki.openstreetmap.org/wiki/Key:maxspeed:type#United_Kingdom
Nadjita (2025-03-21 19:32:30+00:00): Ich will nicht anzweifeln, dass das alles richtig ist, aber warum um Himmels Willen zerlegt SC die surface jedes Mal, anstatt davon auszugehen, dass surface dann für beides, Radweg und Fußweg, gilt :o(
Langlaeufer (2025-03-21 19:58:38+00:00): Da gab es mal eine Diskussion drüber. SC setzt alle 3 Werte (surface aus abwärtskompatiblitätsgründen für Anwendungen die footway/cycleway:surface nicht verstehen). Das sie das gleiche surface für footway und cycleway jeweils separat speichern wollen liegt daran, dass sie einem einzelnen  surface nicht trauen (also ob es wirklich für beide Wegeteile gilt)
TrickyFoxy (2025-12-17 12:01:08+00:00): И зачем вы делаете отношения из одного участника и даже не убираете теги с линий, которые включили в отношнение?
clay_c (2025-06-06 22:11:09+00:00): Hi there 👋

I noticed that some streets were changed here so that the cardinal directions in the names are now abbreviated. On OSM, we generally avoid abbreviations in names (see [1]) - otherwise, text-to-speech engines wouldn't be able to distinguish between a cardinal direction and a literal letter (like "Avenue E"). Could you please return these to their unabbreviated forms?

[1] https://wiki.openstreetmap.org/wiki/Abbreviations
Waller County (2025-06-09 12:27:31+00:00): Avenue E is the name of the road, it is not abbreviated.  Thanks.
clay_c (2025-06-09 18:51:43+00:00): In case it wasn't clear, the names that have been changed here are "E Navigation Street" and "W Navigation Street". These should remain unabbreviated.
Waller County (2025-06-09 19:06:00+00:00): They are updated.  No I did not see the section you were referencing, so no it was not clear.
alexwohlbruck (2025-03-29 23:44:02+00:00): I am reverting this change as the business info tags were placed on the inner building part instead of a separate node. Will replace the POI with it's own node and tags
alexwohlbruck (2025-03-30 01:01:49+00:00): I've visited the location and found no signage or wayfinding that suggests Brownstone Law to exist here. Suite 110, described as the office's location, is a UPS store and extends from both sides of the building. I am removing this POI
os-emmer (2025-05-03 21:50:00+00:00): Hallo bwbuz,
du hast hier einige addr:country="Dlich>" ergänzt. Kann es sein, dass das Tippfehler für addr:country=DE sind?
https://overpass-turbo.eu/s/23qC
bwbuz (2025-05-04 15:23:28+00:00): Hey os-emmer, ganz offensichtlich ein blöder Fehler von mir, sorry. Wäre lieb, wenn du die Korrektur übernehmen könntest. LG bwbuz
os-emmer (2025-05-04 15:26:18+00:00): Danke für die Rückmeldung. Das kann ich gerne machen. Hat das "Dlich>" irgend eine Bedeutung oder kann ich das einfach mit "DE" überschreiben?
bwbuz (2025-05-04 15:28:50+00:00): Einfach überschreiben bitte...war ein Tippfehler...sonst nichts. ;-) Danke!
os-emmer (2025-05-04 15:46:08+00:00): Ist erledigt:
https://www.openstreetmap.org/changeset/165806559
b-jazz (2025-03-22 06:24:11+00:00): Hey Zach, please go back to the notes I left on a previous change from you last week (https://www.openstreetmap.org/changeset/163446770). You are crossing greens and fairways and shouldn't be. Please examine the wiki pages and make sure you aren't creating greens and fairways that intersect like in https://openstreetmap.org/way/834709162. Please leave a comment here so I know that you got this message. Thanks.
Dimitar155 (2025-03-22 05:22:27+00:00): Здравейте!

НДК вече е отбелязан върху основната сграда. ДНК изглежда че е друг обект. Предполагам че ДНК не е закрит?

Поздрави,
Митко
Andrea Del Sarto (2025-03-25 11:40:01+00:00): ciao,
ho sistemato la relazione secondo le linee guida CAI https://wiki.openstreetmap.org/wiki/IT:CAI

ma il  percorso esiste o è in fase di progetto?
silversurfer83 (2025-03-21 21:36:26+00:00): Gude Deus,

Brauereinamen bitte groß schreiben und schau mal ganz genau auf deine Öffnungszeiten :)

cheers
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/163922328
Deus Figendi (2025-03-21 21:43:53+00:00): Ja, die Öffnungszeiten hab ich wohl verhunzt, ist jetzt korrigiert.

Die Brauereien hatte ich groß geschrieben, aber iD hat es mir weg korrigiert, da nahm ich einfach mal an, das soll so.
Goudanius (2025-07-01 13:55:21+00:00): Deze Odin is niet op Maandereind 42, maar op Maanderweg 42 in Ede. 
Hij is daar ook al ingetekend (alleen nog niet met zo veel informatie als hier).

Ik heb de informatie overgedragen naar de andere winkel en zal deze hier verwijderen, als je dat ok vind.
A67-A67 (2025-07-01 17:36:15+00:00): Bedankt voor de verbetering en het overzetten van de info.
goedegazelle (2025-03-22 13:36:33+00:00): De website van het restaurant levert een foutmelding op en lijkt niet te bestaan.

Ik heb hier al vaker naar gekeken en ik vraag me af of er enige aanwijzing is dat dit restaurant daadwerkelijk bestaat. Wat mij betreft kan het weg.
A67-A67 (2025-03-23 21:03:15+00:00): Mijn wijziging ging vooral over de winkel Odin. Het restaurant Het Hart van Heerde had ik meegenomen omdat er een omschrijving in de naam stond. De website doet het inderdaad niet, dus daarom heb ik het niet verder aangevuld. 

Als het restaurant niet meer bestaat, dan kan het weg. Maar ik gooi niet zomaar een POI weg als de website het niet doet.
goedegazelle (2025-03-24 11:57:39+00:00): Met dat laatste ben ik het volledig eens. Ik had eigenlijk gehoopt dat je het bestaan van het restaurant zou kunnen bevestigen. Volgens mij bestaat het restaurant niet meer maar ik zal het voor de zekerheid navragen bij Odin.
vasony (2025-03-22 07:11:57+00:00): Szia!

Javítottam a szerkesztéseidet.
- a sírok közötti gyalogutak highway=path (ösvény)
- a neveket egységesen és nem rövidített formában használni, ref= kulcsban add meg. pl. A1 pont nélkül.
- a kripta nem egy név, ezt a megfelelő címkével kell kifejezni
- az ösvényeket össze kell kötni egymással, ha valójában átjárhatók, az önmagában létező vonalaknak nem sok értelme van
- a területekbe, mint a szektor, ne kösd be az utakat

Próbáld meg a meglévő sémát követni.

Tamás
mga_geo (2025-03-24 06:48:17+00:00): Bonjour,
Pourquoi avez-vous modifié la valeur de l'attribut network de la relation https://www.openstreetmap.org/relation/11920873 ?
La valeur est bien "FR:TUB".
Pouvez-vous corriger ?
Marc
EUMapper (2025-03-24 09:16:54+00:00): Bonjour,
désolé, je l'avait sûrement corrigé parce qu'il y avait un signalement dans ID. Est-ce que vous pouvez corriger? Je ne toucherai plus au relations, Merci!
mga_geo (2025-03-24 09:28:23+00:00): Je viens de corriger.
Les suggestions d'iD ne sont pas toujours à prendre en compte.
Bonne continuation
Marc
raphaelmirc (2025-03-31 14:18:34+00:00): Olá,
tudo bem? 
espero que sim. 
por favor não abrevie nomes de Ruas no Openstreetmap, sempre mapear o nome completo da Via com o primeiro nome sempre em maiusculo. 

atenciosamente, 

Raphael de Assis 
UMBRAOSM União dos mapeadores Brasileiros do Openstreetmap
NeisReview (2025-03-22 06:38:16+00:00): #HighwayChanges

Hello, welcome to OSM.

In this changeset, some types of highway are being added or modified by you. 

Could we know the sources that you used? Thank you.

More information about the changeset: https://resultmaps.neis-one.org/osm-change-viz?c=163923580
reppamrefinoC (2025-03-22 07:56:03+00:00): Hi there,

The changes to highway elements have been sourced from OS OpenData Streetview, Bing Aerial Imagery, and surveys/local knowledge

conifermapper
Willcro (2025-04-09 00:34:32+00:00): Hi zachshanson, I have some questions and concerns. I see you have been making a large number of edits around Bloomington. I want to know more about the resources you are using to make these edits. The reason I am asking is that while randomly poking around, I noticed that this change removed 2 different ways that definitely still exist.
1. An asphalt path connecting https://www.openstreetmap.org/way/1256415733 and https://www.openstreetmap.org/way/560213016 in Countryside Park, forming an "A" shape.
2. A tunnel running underneath Lindstrom Drive, connecting the walking paths. https://www.openstreetmap.org/way/1059984687

Neither is a super important piece of infrastructure, but they do exist.

These pictures were taken today:
https://storage.googleapis.com/vzvmhvmw/PXL_20250408_215057753.MP.jpg
https://storage.googleapis.com/vzvmhvmw/PXL_20250408_215153602.jpg
https://storage.googleapis.com/vzvmhvmw/PXL_20250408_220104122.jpg
https://storage.googleapis.com/vzvmhvmw/PXL_20250408_220132446.jpg
rskedgell (2025-11-24 13:37:13+00:00): As these aren't addressable objects in the usual sense, might it be better to use postal_code=* rather than addr:postcode=* - or are there data consumers which rely on the latter?
RobJN (2025-11-24 17:53:17+00:00): Good question. I think there is value in being able to record the "addresses" details as the owner sees it (e.g. apps can then display that information). That goes beyond just postcode though. Almost like we need a replication of the addr: namespace for "addresses" that you cannot post mail to. Will look at what discussions have happened in this space.
RobJN (2025-11-24 18:09:33+00:00): A relevant recent thread is here: https://community.openstreetmap.org/t/are-addr-tags-for-postal-addresses-only-or-for-locations-in-general/132565

I'm not sure there was a consensus. Perhaps we need to start a UK thread on this...?
rskedgell (2025-11-24 18:35:25+00:00): Thanks. I'll leave the tags untouched until/unless a consensus develops.

There are probably some other objects which fall into the category of not being able to receive mail, but still having some sort of address to describe their location. Electricity substations, bus stops and postboxes might be cases where some data consumers could find it useful.
Paul Berry (2025-11-27 19:40:04+00:00): As a further example, defibrillator boxes often have postcodes to describe their location and some have taken to expand to that to addr:* tags. As with similar objects, and to echo comments above, I think the consensus is if they're not places capable of receiving mail (tip: is it even a building?) then addr:* tags should not be used, but postal_code is acceptable for a common way to geolocate them.

I will see if there's a thread in the talk-gb archives about this. I'm sure it's been raised before.
emvee (2025-07-06 07:54:44+00:00): Ik vraag me af op basis waarvan de update gedaan is.

Zo te zien zijn er geen SNS automaten meer, https://www.snsbank.nl/particulier/service/meer-mogelijk-bij-geldautomaten.html

En hier is geen geldmaat te vinden.
lyctkel (2025-07-06 09:57:52+00:00): Hoi emvee,
de changeset comment is verkeerd geformuleerd.
Wat er werd bedoeld was het updaten van het node door de operator en het brand toe te voegen, evenals de wikipediagegevens.
Groet,
lyctkel
emvee (2025-07-06 13:31:06+00:00): Okay, goed te weten.

Staat op de lijst van waarschijnlijk niet meer aanwezig. Deze specifiek is moeilijk omdat hij onder een groot afdak zit en ook niet langs een weg.
emvee (2025-07-06 13:38:40+00:00): Ik hem voor deze maar eens een note toegevoegd
BubbaJuice (2025-07-28 03:54:31+00:00): Nice job identifying the substation.
SomeoneElse (2025-03-22 15:32:30+00:00): Hello, 
I think that this edit has broken some relations in Dublin:

<  -10709165 | Monkstown Parish
<   -8851327 | Holy Trinity Kingstown Parish 1900

<   -8856889 | Diocese of Dublin 1900

<  -11298801 | Province of Dublin

<  -15480473 | Killiney DED 1971
<  -12498372 | Killiney ED

<   -4622511 | Killiney
<   -4622479 | Rocheshill
<   -4592163 | Ballinclea
>   -4486085 | Spinans West

<   -4672601 | Killiney

<   -4574127 | Rathdown

<   -282800 | County Dublin

If you download each in JOSM and hit the "validate" button you'll see what has happened and will be able to fix.

Best Regards,
Andy
SomeoneElse (2025-03-30 12:05:31+00:00): For completeness, there is still an issue here.  Since at least 4 people are fixing things, I've posted in the Irish forum at https://community.openstreetmap.org/t/coastline-and-relation-breakage-in-killiney-south-of-dublin/128102 suggesting that people work together there.