piebro/osm-data huggingface dataset:
Dimacn (2025-03-15 11:29:17+00:00): Пожалуйста пользуйтесь спутниковыми снимками Esri, они намного новее чем Bing, которыми пользуетесь вы. Bing в наших краях очень старые.
b-jazz (2025-03-15 17:15:57+00:00): You shouldn't be using adjoining polygons to define a single feature like a fairway in hole #3. You should just use a single feature for the fairway, a single feature for the green, and then select them both and right click and select merge to make it a single object called a multipolygon.

If you need help, please check out the wiki at https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgolf_course

If you need help after that, please drop a comment here or reach out to me for help.
Spaghetti Monster🍝 (2025-03-16 02:05:01+00:00): reverted. 
https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
https://wiki.openstreetmap.org/wiki/Problematic_mapping/golf
CurlingMan13 (2025-03-15 17:41:11+00:00): As mentioned before, please use the correct tags...

The correct tag for letters on a mountain is:

man_made=geoglyph
CurlingMan13 (2025-03-15 17:44:25+00:00): This isn't how you map this......
Taya_S (2025-03-15 11:30:33+00:00): Reverted vandalism DWG Ticket#2025031510000197

https://www.openstreetmap.org/changeset/163646807
b-jazz (2025-03-17 17:33:31+00:00): Hello fellow 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 visual examples an instructions on 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!
malifica (2025-03-31 13:25:26+00:00): I'm very familiar with how to properly spline golf courses since I do it to create professional 3D representations using matching elevation data. Per the multi-polygon standards, complex shapes with many nodes should actually be omitted. Why? Because they cause rendering problems. Whomever wrote that wiki entry should probably actually use the various apps that utilize OSM as their source. In this course specifically, you would have every tee, bunker, green, fairway, rough and even some water in a multipolygon relationship with each other. This is not feasible. The multipolygon relationship is supposed to be used by the same type of tagged area that has obvious inner and outer boundaries. Like a lake with an island. A building with an atrium, etc.
b-jazz (2025-03-31 15:41:09+00:00): 1. "I'm very familiar with how to properly spline golf courses since I do it to create professional 3D representations using matching elevation data."

For the purpose of the discussion I'm going to assume you are using TGC 2019 (I'm not sure if these comments apply to PGA Tour 2K23, so take them with a grain of salt if so.)

2. "Per the multi-polygon standards, complex shapes with many nodes should actually be omitted."

Exactly what "standards" are you referring to? Complex shapes are the very reason that multipolygons exist and should be used. You can find the use of multipolygons used by OSM written on the wiki at http://wiki.openstreetmap.org/wiki/Relation:multipolygon.

3. "Why? Because they cause rendering problems."

Rendering problems are an issue with third party apps/software and are no reason to use improper mapping to get around those issues. There is a common saying in OSM: "don't map for the renderer". That only leads to problems. You should address those bugs with your software vendor. We are aware that there is software called Chad's Tool that doesn't handle multipolygons correctly yet. There is a bug fix that has been written and submitted (https://github.com/chadrockey/TGC-Designer-Tools/pull/143) but has yet to be pulled in and tested. Maybe you could lend your voice to get this fix implemented by dropping a comment on the pull request. It will make multipolygons less of an issue for you and other users of the tool.

4. "Whomever wrote that wiki entry should probably actually use the various apps that utilize OSM as their source."

What is important to remember is that OSM is a community project that is used by thousands of different pieces of software and millions of users. The standards are well thought out and have evolved over decades to focus on getting core concepts right. If there are problems with software that uses OSM, those are best addressed with the makers of that software instead of trying to work around them (and possible introducing problems with other users of OSM data).
b-jazz (2025-03-31 15:41:44+00:00): 5. "In this course specifically, you would have every tee, bunker, green, fairway, rough and even some water in a multipolygon relationship with each other. This is not feasible."

Yes, that is the end goal and is very feasible. In fact, I will show you that it is easy to accomplish using existing tools like JOSM. (Life with JOSM is so much better than the built in iD editor. I'd suggest looking into it.) I'll add a comment when I'm done.

6. "The multipolygon relationship is supposed to be used by the same type of tagged area that has obvious inner and outer boundaries. Like a lake with an island. A building with an atrium, etc."

Fairways and greens are one of those obvious inner and outer boundary use cases. (Where the fairway surrounds the green specifically. I realize that many fairways simply butt up against the green. And some fairways don't even reach the green.)

7. "The fairways that share nodes all the way around greens (even the ones mistakenly tagged as tees) are another problem."

Yes, I'm well aware of those. I review golf course edits (in the US) every day and have started leaving comments with new instances of that error and try to educate people so those won't be created any longer. My current major focus are the 20,000 fairways that are sloppily drawn across greens. After that, I will address those, but it will likely be later this year.

8. "If you want to be accurate, these nodes/splines need to be aligned with the most recent official elevation data, not whatever old sat image OSM is able to freely use. I've seen many splines be off by 20 yds or more."

Yeah, that has always been a problem. I only one man. I can't solve all mapping problems. My main focus is to get the geometries represented correctly and hopefully there are others that can work on getting everything properly aligned.
malifica (2025-03-31 16:11:04+00:00): TGCtools is opensource. My version has always rendered multipolygons just fine. I believe there is even work being done on a new "official" version to deal with that and all of the other OSM related issues. But that isn't what my comment was about.

Anything that uses a query to retrieve data from OSM takes a minimum of 20x more time when multipolygon relationships are used. This is the case with any app that uses OSM. It is a known OSM api problem. 

If I am on a course and using gps and OSM to track my shot, if it is a course with multipolygons, it is unusable.  Once you have an area with relationships of more than about 500 nodes, it turns into tens of minutes to retrieve even one hole (if the query doesn't timeout to busy servers).

If you want golf course geometries properly aligned and represented, please use the most recent elevation data available. Otherwise it is a waste of time.

Sometimes, even the courses have up to date imagery and lidar from drones. You can use JOSM and offline image sources to make them very accurate. I never upload my offline changes since they usually get changed back to whatever matches Bing and that work is specifically done for third parties that do not utilize OSM for anything other than the initial spline work.
b-jazz (2025-03-31 17:20:00+00:00): "This is the case with any app that uses OSM. It is a known OSM api problem." 

This is most certainly *not* an OSM problem. Multipolygons add minimal overhead in terms of data size. I was able to download this entire 36(?) hole course, multipolygons and all in 3 seconds. Your software shouldn't be directly accessing the OSM reference database on every hole. What should, and is likely being done, is to cache the data on TGC servers. Any download and rendering problems are with those servers and software and should be addressed with that entity. As I mentioned earlier, many many different people, apps, software, and tools access OSM data and everyone needs to conform to those standards and not map improperly just to satisfy one that is having problems. Gotta fix it at the source of the problem.
malifica (2025-03-31 18:09:27+00:00): My comment and current workflow has nothing to do with TGC. And FYI, that isn't how TGC ever operated anyway.

Those issues with multipolygons and multiple relationships are when you use the OpenStreetMap Overpass API. It has nothing to do with data size and "overhead."

This is why I do an initial spine in ID, then download the area and work in ArcGIS offline. If I need to vast changes to OSM data at that point, I will do that in JOSM offline.
malifica (2025-03-31 18:45:36+00:00): So, if you want to be consistent with multipolygons. You need to do the following:

Rough = Outer
Fairway = Inner
Bunker = Inner
Fairway = Outer
Green = Inner
Bunkers w/ Rough Surrounds in Fairway:
Rough = Inner
Rough = Outer
Bunker = Inner

Bunkers w/ Rough or Fairway elements within their boundry:

Bunker = Outer
Rough/Fairway = Inner

Bunkers/Water that intersect Fairway and/or Rough and Natural Surface:

No clue how this will work since multipolygon doesn't handle partial relationships and intersects.

This is a hierarchy nightmare and will vastly increase query times to where overpass will never work correctly. In addition, every 'parent' line will have lost their tag. 

This supposed "standard" is unusable and obviously not though out in actual practice.
b-jazz (2025-03-31 19:05:09+00:00): There are so many different possibilities for the inners and outers that you list above that it is not worth typing out how it should be done. I'll point you at the (unnamed) course in this changeset that I worked on this morning. Most everything should be tagged correctly now. If you'd like to find an example that you feel is wrong, paste the url of the piece and I'll take a look and discuss further.

I'd like to see an example of the "vastly increase[d] query times". Can you provide me an example query that takes an inordinate amount of time? Maybe the query isn't structured well? I don't know, but until I see it I can't know.

I don't see a "hierarchy nightmare". I see something that makes complete sense logically and is represented correctly geometrically. Yes, you can have a bunker inside a rough inside a fairway inside a rough. It's not that complex. And when you go and use spatial databases and query the area of rough, since everything is correctly tagged and laid out, you get the answer you're looking for.

Don't confuse "unusable" for "poorly implemented". If there is some software isn't written correctly to handle these complex relations, then it is the problem.

As for parent lines that have lost their tag... I've heard of this misconception before. The tag is still there, it is just where it should be: on the relation, and not the outer boundary. I've been meaning to write up a document to give some visual examples of this. Take a simple green in a fairway. The line the defines the outer fairway isn't the fairway. It's the fairway minus the green. And if you look at the relation, you'll see the outer/inner relation correctly defines that.
malifica (2025-03-31 19:53:15+00:00): Because when you go beyond a "simple green in a fairway" this system breaks. Go ahead and make all the multipolygon relationships as I laid out above and be consistent with what you are discussing. 

You must be joking about query times. If you have ignored all the posts regarding overpass queries and server timeouts over the years there is no use discussing this with you.

You do you, I'll do me. If you want to change some of my OSM work to be like how you want it, go ahead.
b-jazz (2025-03-31 20:10:33+00:00): >You do you, I'll do me.

I will follow best practices. The community needs you to do the same. If you make wildly bad edits like running fairways into greens, you'll be called out and will face being blocked. I don't expect you to turn everything into multipolygons. It would be appreciated if you did, but I'm not going to report you for that. But if you break existing multipolygon relations, that's another story. Another problem that the community has is when someone wipes out existing work and replaces it with their own. You should preserve the history of existing objects. Don't delete a fairway and redraw it, just modify it.
malifica (2025-03-31 20:38:43+00:00): First of all, I really do appreciate the time you have taken regarding all of this. 

Your tags look accurate and do make sense. 

Some of my workflow issues are likely with ArcGIS. However, the render and query times are drastically increased with multipolygons. This is documented and can't be argued.

I never purposely break multipolygons. If a feature no longer exists, I will remove it. If it can be moved and/or have the geometry slightly altered, I do that. If it is so poorly constructed and requires me to delete more than 50% of the existing nodes, I will remove it and re-create it. 

BTW, excessive nodes are a problem too. If a shape can be accurate with 10 nodes, it doesn't need 30+.

If I am splining out a single rough surround across a whole course or multiple fairways, it will usually be a single continuous line. This may end up in what may look like "lollipop" shapes, but is unintentional.

I never purposely run a fairway into a green. That behavior would undermine my workflow.

The fairway in question today that started all of this was someone else's work. I merely changed the lip, re-did the rough stripes, and moved it. I guess the nodes shared with the green weren't all actually shared. I know I deleted a couple of the nodes that looked out of place, but I suppose I didn't get them all. 

Ultimately, It seems like we want the same thing. Accurate golf course mapping. I'll do what I can to be one of the better ones.

Thanks!
b-jazz (2025-03-31 21:00:54+00:00): Thanks malifica. I appreciate having a chance to discuss it and work out our issues.

I am sorry to hear about the performance issues you're seeing. I typically have very fast data loads with OSM (short of rare server issues with OSM) so I'm thinking you might be right that it might be an ArcGIS problem. Have you ever looked into QGIS? It's free and runs everywhere and might help. I have no deep experience with either though.

Somehow word got out early on that the right way to join a fairway and green was to overlap them. This style was quickly adopted and spread like wildfire and we now have 20,000 greens like this and I'm doing my darndest to clean them up and get word out to hopefully stop that flow.

The lollipops I was referring to sound different from what you are doing. I used to run into them often and put together a 3 month effort to get rid of them (at least on fairways). Here's an example of what I'd see: https://wiki.openstreetmap.org/w/images/5/58/Golf_Course_Lollipop_Example.png
malifica (2025-03-31 21:35:55+00:00): I'm quite familiar with both issues and probably contributed to them back in the early TGC 2019 days. The rough splines I do may look like your example, but that is because there is actual (cart path / natural area) that causes the shape. 

The inside the fairway bunker lollipop is a longstanding TGC 2019 problem. There are better ways to handle that for the game, but I think many people that are just creating their home course probably still use that method. 

I may still create a fairway lollipop occasionally from doing my long single splines when there are vast bunker / waste area complexes and then forget to go back and fix it. If you come across one of mine, send me a message and I'll fix it.
Spaghetti Monster🍝 (2025-03-15 08:24:08+00:00): reverted. 
Please only add real features and names

https://www.openstreetmap.org/changeset/163640081
NeisReview (2025-03-15 06:41:23+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=163634410
Taya_S (2025-03-15 11:30:34+00:00): Reverted vandalism DWG Ticket#2025031510000197

https://www.openstreetmap.org/changeset/163646807
Allroads (2026-07-06 15:58:37+00:00): Hoi, ik heb hier een melding van OSMinspector Geofabrik,  dat de turn restriction niet klopt.  Als ik verder kijk dan staan er eenrichtingsborden. Dit taggen we met oneway= daar gebruiken we geen relaties voor.  Zie verkeersborden pagina.
https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring. 

Zou je de relaties willen weghalen welke niet van toepassing zijn, wegens eenrichtingsborden.

Groeten Allroads.

https://tools.geofabrik.de/osmi/?view=turn_restrictions&lon=6.67415&lat=53.40720&zoom=17&baselayer=Geofabrik%20Standard&overlays=invalid_restrictions_w%2Cinvalid_restrictions_n%2Crestrictions_w%2Crestrictions_n%2Cinvalid_restrictions_w%2Cinvalid_restrictions_n%2Crestrictions_w%2Crestrictions_n

NWB
https://wegkenmerken.ndw.nu/kaart?kaartlagen=TRAFFIC_SIGN,ADMINISTRATIVE_DIVISION,OSM&zichtbaar-gebied=6.67208,53.40602,6.68128,53.40893&verkeersbordfilter=70c28518.______________________________________________9_Aw
Frans S (2025-03-16 13:50:04+00:00): We welcome you as a new mapper.
Thanks for your contribution to this project.
This changeset is reviewed by a Global Validator to check that the tasks have been mapped in accordance with the quality standards of HOTOSM. 
We cannot expect from a new mapper that he/she delivers high-quality mappings from the start, so we offer some guidance.
Please pay attention to the next summarized issues. (see attached document with examples for more info)
-------------------------------------------------------------
buildings not squared.
Included the shadow into a building.

Explanation can be found in this document what  might be helpful to strengthen your mapping skills
https://docs.google.com/document/d/1Swwz-ZwM3_YOstqstsmCg1-lNAPbnMLpi1Al-h-2UOQ/edit


Best regards and keep mapping!
Frans S
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/163634966
Frans S (2025-03-16 14:21:25+00:00): We welcome you as a new mapper.
Thanks for your contribution to this project.
This changeset is reviewed by a Global Validator to check that the tasks have been mapped in accordance with the quality standards of HOTOSM. 
We cannot expect from a new mapper that he/she delivers high-quality mappings from the start, so we offer some guidance.
Please pay attention to the next summarized issues. (see attached document with examples for more info)
-------------------------------------------------------------
rather inaccurate (sloppy) mapped.
Most buildings are more or less rectangular.
Buildings not squared.
Do not cluster buildings.

Explanation can be found in this document what  might be helpful to strengthen your mapping skills
https://docs.google.com/document/d/1Swwz-ZwM3_YOstqstsmCg1-lNAPbnMLpi1Al-h-2UOQ/edit


Best regards and keep mapping!
Frans S
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/163635182
Frans S (2025-03-16 14:22:06+00:00): check this webpage to see your mappings and adjustments I had to make
https://overpass-api.de/achavi/?changeset=163690978
Best regards
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/163635182
NeisReview (2025-03-15 18:17:14+00:00): #NoTags

Hi, welcome to OSM.

I've reviewed your latest map edits and it seems that this changeset you created includes nodes and ways without any tags. Could there have been an issue during the mapping process?

Looking forward to your response.

Thank you!
NeisRevert (2025-03-21 20:38:10+00:00): #hotosm
Shawnster (2025-03-15 06:06:53+00:00): I added new pave ways to the map
NeisReview (2025-03-15 18:17:29+00:00): #NoTags

Hi, welcome to OSM.

I've reviewed your latest map edits and it seems that this changeset you created includes nodes and ways without any tags. Could there have been an issue during the mapping process?

Looking forward to your response.

Thank you!
NeisRevert (2025-03-21 20:38:18+00:00): #hotosm
dypa (2025-03-21 18:15:49+00:00): При указании размеченных не регулируемых пешеходных переходов нельзя использовать тег crossing=zebra, см https://wiki.openstreetmap.org/wiki/RU:Tag:crossing=zebra

Пожалуйста при внесении следующих правок используйте теги (Размеченный (нерегулируемый) пешеходный переход)
crossing=uncontrolled
crossing:markings=zebra

Заранее спасибо!
Shawnster (2025-03-15 06:06:22+00:00): I added new paved ways
Fizzie-DWG (2025-04-02 05:01:06+00:00): DWG revert - undiscussed import from unknown source

https://www.openstreetmap.org/changeset/164401673
Fizzie-DWG (2025-04-02 05:01:04+00:00): DWG revert - undiscussed import from unknown source

https://www.openstreetmap.org/changeset/164401672
真中あお (2025-03-17 21:20:02+00:00): 感谢您为OSM做出贡献！
不过，您对袁林（袁世凯坟墓）的编辑存在一些问题：首先，袁世凯的坟墓是一个院落，而不是单个建筑，因此需要去除iD编辑器对陵墓区域默认的“建筑物=yes”标签。其二，在添加英语等外语名称的标签（name:en=xx）同时，也需要添加一个中文名标签。也就是把已有的名称复制到“name:zh=oo"标签下即可。我现已对袁林完成了上述修正，可供参考。
祝您对OSM越用越顺手~

translated version, helped by machine: Thank you for contributing to OSM! However, there are some issues with your editing of Yuan Shikai's tomb (袁林): first, Yuan Shikai's tomb is a compound, not a single building, so it is necessary to remove the "building=yes" tag for the tomb area, which is default to be added in the iD editor. Second, when adding a tag for foreign language names such as English (name:en=xx), it is also necessary to add the tag for Chinese name. That is, you can just copy the existed value in name tag to the "name:zh" key. I have now completed the above revisions for Yuan Shikai's tomb, which can be used as a reference .
I wish you more and more comfortable with OSM~
Fizzie-DWG (2025-04-02 05:00:58+00:00): DWG revert - undiscussed import from unknown source

https://www.openstreetmap.org/changeset/164401670
Syl (2025-03-15 10:34:40+00:00): Hello, I revert your changes and fix the buildings.
In France "BDOrtho IGN" is a better imagery. Here Esri imagery is misaligned and should not be used to change building position.
Fizzie-DWG (2025-04-02 05:00:51+00:00): DWG revert - undiscussed import from unknown source

https://www.openstreetmap.org/changeset/164401666
Marek-M (2025-03-15 08:15:08+00:00): Jeżeli piekarnia nie ma nazwy, to wystarczy sam znacznik shop=pastry lub shop=bakery bez nazwy.

Poprawiłem tutaj: https://www.osm.org/changeset/163639908
DD1GJ (2025-03-15 16:11:58+00:00): Willkommen bei OpenStreetMap. Ich habe die Änderungen rückgängig gemacht, da das Fahrradgeschäft und ein anderer Punkt wohl versehentlich verschoben wurden. Was genau ist an dieser Stelle? Man könnte den Sitz der Geschäftsstelle eintragen, aber der ist in der Krumme Straße. Da der Club sicherlich nicht das gesamte Gebäude nutzt, bitte nur einen Punkt eintragen.

https://wiki.openstreetmap.org/wiki/File:Osm-tutorial.pdf
大山かなめ (2025-03-15 07:56:07+00:00): 備考：
私が普段、位置の基準にする背景画像に地理院標準地図を用いていますが、同駅を地理院標準地図に合わせようとした場合3m程度西への移動となり駅周辺の地物との位置関係に不整合が生じてしまうため、移動する量が最小で済むBingを仮に用いています