Please make changes over smaller areas. You destroyed the area around PNC Park and made it difficult to revert those changes.

Heh. You can see my bot changed something nearby and the name shows up at the bottom of his OSM window at that timestamp.

So yeah, we know about this guy. He's been banned from OSM for putting out bad information and refusing to correct it. He's even turned off comments on the video so people can't add something along the lines of "hey, don't do that thing he talks about at 9:43 in the video. Do this instead..."

How did you come across the video? Just a google search or did something from TGC lead you to it? Maybe we can address it further up the chain.

Thanks for the response.
Could you send me a link to the tutorial? I'm pretty sure we are aware of it and have tried to get the creator to amend it or somehow get the correct information out. But just in case, I want to make sure we cover all bases and address each tutorial that might lead people down the wrong path. Thanks.

osm.org/node/12090867003 seems slightly out of place, being in the middle of a golf green and all. I'm assuming it is supposed to be by the nearby water feature.

RE: osm.org/way/1375030597

Please don't share the nodes of the green if you have the fairway surround the green. If you can't see any fringe around the green, you should make the fairway butt up to the green and share the nodes on the boundary between the green and fairway instead. Please read the wiki for visual examples and instructions on how to better map golf courses: osm.wiki/Tag:leisure%3Dgolf_course#Common_mapping_pitfalls. If you have any questions, please let me know and I'll gladly help clarify things. Thanks!

Please don't share the nodes of the green if you have the fairway surround the green. If you can't see any fringe around the green, you should make the fairway butt up to the green share the nodes on the boundary between the green and fairway instead. Please read the wiki for visual examples and instructions on how to better map golf courses: osm.wiki/Tag:leisure%3Dgolf_course#Common_mapping_pitfalls. If you have any questions, please let me know and I'll gladly help clarify things. Thanks!

Please don't use the "lollipop" style of mapping golf course elements as seen in osm.org/way/931454583. You need to create proper multipolygon relations in order to map features like roughs/bunkers that are within other features like fairways. Please see osm.wiki/Tag:leisure%3Dgolf_course#Common_mapping_pitfalls and osm.wiki/Relation:multipolygon for help in understanding how to map this situation. If those aren't clear, please let me know and I'll help explain them further. Thanks.

Why did you change the first hole on the golf course?

Thanks for reverting your changes. FYI, the bunker belongs in the multipolygon as well.

Can you explain this a little more. There is nothing wrong with fairways "overlapping" greens when they are properly defined with multipolygon relations. There is a fringe around the green and that is typically mapped the way I had had mapped it. It would be nice if you didn't undo all of my hard work. Maybe I'm missing something.

I really wish JOSM would prevent you from doing changeset areas without forcing you to confirm it first. It notifies you, but that isn't enough if you're in a groove.

I should expand that to say that fairways should also not be crossing bunkers, water hazards, and tees and other golf features. See osm.org/way/1373723302 for an example of where you make this error.

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 osm.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: osm.wiki/Tag:leisure%3Dgolf_course#Common_mapping_pitfalls. If you have any questions, please reply here and I'll gladly help clarify things. Thanks!

Hi there. Please stop drawing a bunch of connected or overlapping shaped representing the same area. For instance the rough around this object (osm.org/way/1373629377) touches several other rough areas.

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: osm.wiki/w/images/5/58/Golf_Course_Lollipop_Example.png

>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.

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.

"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.

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.

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 osm.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).