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

Yup, encoding problem. This one should work.

leisure=golf_course

Your latest argument makes no sense and isn’t convincing anyone that you understand mapping. If you’re saving your best arguments for another day, I guess we won’t be blessed to read them.

osm.wiki/Tag:leisure%253Dgolf_course

osm.wiki/Relation:multipolygon

osm.wiki/Keep_the_history

First you would need to find out what map provider is used by your vehicle for navigation. Is this something built into your car or are you just talking about a navigation app on your phone?

I see you are adding a bunch of addresses to the building, which isn't the best way to go. I'm not aware of routing software that looks for housenumber1..N. I've added a few address points that would be the "more correct" way to map multiple units in a building.

You should also be aware that there can be a huge lag time (weeks) between when you make a change to a map and when that actually shows up on navigation apps.

I feel your pain. I've dealt with housing complexes that had unnecessarily complex routing issues.

I'm sorry, but this isn't a question of opinions. It's just proper mapping vs improper mapping. And yes, this is a community project and we all need to respect each other's work and abide by a common set of goals and practices. Multipolygons are correct. While the lack of a multipolygon isn't necessarily "damaging", removing a proper polygon is most certainly damaging. Deleting other people's fairway so that you can draw your own *is* damaging. Sloppily drawing fairways across a green *is* damaging.
We appreciate golf simulator mappers filling out golf courses. There is no question about that, but we want them to map according to community standards.
There are well over 20,000 fairways in the US that have the fairway overlapping the green and they need to be fixed thanks to simulator mappers. It's going to take me a year to fix that and try to get others to stop that bad practice.

When you draw the polygon for a fairway, you are saying that absolutely everything within that polygon is a fairway. So even if there is a green in that fairway boundary, you are saying that it is a fairway as well. Both a fairway AND a green at the same time. The purpose of a multipolygon is to say everything within that boundary is a fairway EXCEPT any "inner" relations of the multipolygon. And yes, roughs should be drawn correctly and tagged as multipolygons as well.
I'm guessing you would probably agree, but just struggle because a tool you use doesn't handle them properly.

Thanks for reverting. Just because a third party tool doesn't behave correctly is no excuse to not map properly. There are hundreds of other apps/tools/services that use OSM and they all need to be following the same guidelines.

Are you talking about Chad's Tool? If so, maybe you could pressure the maintainers to incorporate the following fix into their next release: https://github.com/chadrockey/TGC-Designer-Tools/pull/143

It sounds like that might resolve the problem.