I should expand that to say that fairways should also not be crossing bunkers, water hazards, and tees and other golf features. See 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: leisure=golf_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 (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).

Let me try to address some of these issues in my response that I'm working on to your other comment so that we don't have two threads going. I appreciate the discussion.

Thanks for getting back to me malifica so we can discuss this further. I'm not sure exactly what is "comical". There is only so much that someone can do to correct mapping irregularities. Because I don't get to them all in one instant doesn't mean I don't care about them and won't eventually get to them. If you could point out the other failures, I'd be glad to discuss them and any plans that I have for them. Thanks.

As discussed in changeset/163633938, you shouldn't be making your fairways and greens overlap, but instead you should be sharing every node at their border. Please see the wiki in the previous comments for further instructions on how to properly map these golf course features. Thanks.

As I wrote in changeset/164269073, you shouldn't be using lollipop mapping when trying to place a feature like a bunker within another feature (like a fairway). See my previous notes for the wiki that describes the proper way to map these features. Please let me know that you've seen this comment. thanks.

RE: way/1372369336

Your fairways and greens need to share all of the nodes between them, not just a select few. See the wiki for more helpful information about mapping golf courses. leisure=golf_course

Also, don't draw lollipops in order to get around a feature contained in another feature. For example: a bunker in the middle of a fairway. See way/1373179981 where you did this. The wiki mentioned above shows the proper way to use multipolygons to map something like that.

RE: way/1373179979

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 must 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: leisure=golf_course#Common_mapping_pitfalls. If you have any questions, please reply here and I'll gladly help clarify things. Thanks!

Interesting. I didn't realize there were separate notification prefs for those two types of communications. I get emails for both, so I assumed everyone else does as well.

You shouldn't be using the "lollipop" style of mapping as seen in way/1372794901. You need to create proper multipolygon relations in order to map features like roughs/bunkers that are within other features. Please see osm.wiki/Relation:multipolygon and leisure=golf_course#Common_mapping_pitfalls for help in understanding how to map this situation.
And you shouldn't be creating a multipolygon just to split the fairway into two segments. That's not the right use of multipolygons.

If those aren't clear, please let me know and I'll help explain them further. Thanks.

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: leisure=golf_course#Common_mapping_pitfalls. If you have any questions, please reply here and I'll gladly help clarify things. Thanks!

Well. That was something.