https://www.fairwaymapper.com/map/the-country-club-at-golden-nugget-us

I do care.

Guess what? No one really cares. Most people drop an edit, do some random work (that is usually sloppy) and move on. There are only a few people like yourself that care about their legacy edits, "and the process." And there is really no reason to retain the history of an ephermeral golf course - They change constantly, and when they do, do you really need to know that 'joe123-golfdude,' made that initial putting green that hasn't existed in that specific shape or place for 5 years? I'm happy to retain and edit existing objects if they are in the correct EPSG projection with the other course objects and there are only a few nodes that need to be altered, or if the same shape only needs to be moved.

You are crazy if you think mayman521's work is even remotely acceptable. Thanks for the laugh. Nearly identical, means they are not identical. When a mow line changes, it no longer exists. When a tee box is removed and replaced by the course, that is exactly what happens, they don't "edit" the existing tee box. Anyway, please stay in your lane and I'll stay in mine. This is my job.

I do hundreds of golf courses a year... and in this case, I'm pretty sure I deleted the putting green that I made 18 months ago that was just an alignment (plot dimensions) placeholder when testing the USGS LiDAR. Anytime the objects are misaligned with the current elevation data and/or are using multiple projection (sat image) sources (usually due to multiple people doing edits) it is almost impossible to make clean and aligned edits to existing objects. Seriously, most of these golf course objects are so out of whack it would take 10 times as long to edit and retain the previous objects/cart paths instead of creating new ones. Since these are all golf course features, if I am updating/replacing them it is due to the features no longer existing in their previous state. An old bunker does not 'move' to a new place or change shape, it is gone, no lonmger exists, and is replaced. I have been doing this for years, have created the development tools for OSM maps to be used virtual golf course creation. However, if you are curious what the golf may have looked like in the past take a look at the ESRI Clarity beta.

And I was unaware of the Par 5 needing 4 nodes instead of 3. I'll correct that going forward.

Sorry about the crash out. I was still in the middle of this edit and I know for certain I did not intentionally create a new node on a Par 3. Seriously, I thought we had all this worked out, and I am on your side when it come to proper OSM edits. If I did, that was a mistaken double click. Yes, Everyone building courses for the PGA 2k series should be using my Tool because it supports the OSM multipolygon standard (no more lollipops and everything needs to be inner/outer), the other tools do not. And they should all be following the official OSM mapping standards. Whether they do or not, that is on them. You seem to misunderstand my "Tool", my tool if for offline processing of the LiDAR/DEM elevation data and it uses the OSM spline data. It is not for editing OSM data on the servers. Hope that clears everything up. If you see a mistake please point it out, but I can assure you that I am not making them on purpose.

And if you are going to make edits, why don't you make sure they are adhere to the actual sat imagery/hillshade instead of just doing your thing. Which will need to get deleted and/or modified so it is in alignment and actually represents the real feature?

And I am still actively working on this course... I try to make sure everything is done properly and usually give it the final check before I move on to the next course.

https://github.com/malifica/TGC-Designer-Tools/releases

I didn't do that. That node already existed and was tied into the water. I detacthed it and moved it. By the way, I released my private goldf course tool so EVERYONE should be using only the correct way to spline all golf features since I translate everything to the game heirachy automatically. Your welcome!

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.