I wasn't finished with this course. Until, I can get everything lined up with the elevation data, there may some elements that are in a temporary state.

By the way, I went ahead and fixed all those golf holes on Twin Lakes.

So you understand what I am working with, I use the course blueprints, latest (or requested) course/government/surveyor provided elevation data and whatever OSM sat image matches those the best. I will also use the 'imagery offset' in iD to get it as close to the elevation data as possible unless it is so off to cause confusion for anyone looking at the standard OSM layer.

The three node minimum is to establish proper yardages and sightlines for my output and something I have done for years. If the extra node on the Par 3 holes is an issue, I can leave it off (may be a hard habit to break) or make it less conspicuous.

(Checking out golf hole) Oh my, that is hilarious. #16 is especially humorous.

I loathe shared nodes. I understand they can be necessary, but when I come across a boundary, street, cartpath, and landuse feature all intersecting and sharing the same nodes, it makes it very time consuming to get anything done.

I'm not a fan of zooming too far in and increasing node count, but I may see about doing that on future courses where the imagery allows for me to be accurate within a foot or two. Unfortunately, all of this area I am currently working on has some of the worst sat imagery I have seen in a very long time.

Anyway, glad that we are mostly on the same page with similar goals.

If there are problem courses (like you the one you shared) that need some quick fixes/attention, I'd be happy to give them a run through and remedy the obvious errors. Just send me a note and link and I'll see what I can do.

The fairway, which has an intermediate cut of rough on it's edge, surrounds the green. It doesn't actually "share" the edge of the green. I suppose the more technically correct way to draw it would be to not share the nodes at all, but keep the fairway nodes separate by about 1 foot, but OSM doesn't play nice with nodes that close together and will Inadvertently pull the nodes together and/or cause the splines to intersect.

If they do not have the fairway/intermediate rough surround then the fairway would share the nodes on the "inside" of the green instead of surrounding it. Look at my edits on the course just to the W and NW (Vintage Club Mountain Course) for an example of that.

All golf holes should be a total of three nodes (unless there is a double dogleg par 5 with a blind approach shot which may have 4 nodes). I can move the middle waypoint node on par 3 holes to be in the fairway, but that just boils down to personal preference.

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.

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!

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.

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.

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.

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.

How about all of the rough/fairway/bunkers/tees/water that are not in relationships. Except, none of these should actually be in multipolygon relationships (refer to my previous comment as to why).

The fairways that share nodes all the way around greens (even the ones mistakenly tagged as tees) are another problem. These get rendered as duplicate nodes in all of the apps that use OSM as source data.

Your work. Accuracy. 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.

And yet, no comment about the rest of the course and all the obvious OSM "best practices" for golf courses failures. Comical.

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.