Lee Carré (2022-03-01 15:07:21+00:00): “the comment I selected from a previous course edit would classify the new course as being part of an old change set”

No, that's incorrect.

The comment is orthogonal to what the set contains (elements changed, area of the bounding box). The comment should describe the nature of the changes made. What makes for http://wiki.osm.org/wiki/Good_changeset_comments

The large bbox is due to editing in a distant area without first closing the set for the previous area.

In your editor of choice (iD), to close a changeset involves pressing the “Save” button.
The point / ‘suggestion’ I made was to do this between editing different golf courses (like with your other changesets).

Further reading: http://wiki.osm.org/wiki/Changeset

“open street map could make the comment selection process a bit more transparent”

OSM is a system, comprising many parts.

Sounds like your complaint is about your chosen editor.

What do you mean, exactly, by ‘make the comment selection process a bit more transparent’?
What's unclear & how could it be improved?

Comments are whatever you type in (as mentioned, they should be a clear description of the changes made in that set; what makes for http://wiki.osm.org/wiki/Good_changeset_comments ). The entries in any drop-down list are very likely to be your previously-entered values.

“changes I've been making to individual courses have not effected the actual courses”

Err, that's self-contradictory (unless you're referring to the physical courses in meat-space which are represented in OSM, but that misses the point).

Changes necessarily affect the element(s) being changed. Else, to have on effect, then the change-count would have to be zero (which is self-evidently not true).

Sounds like you're focusing on the default (Carto) rendered tileset, which misses the point. The tiles are rendered from the database. The database (of tagged elements) IS the map.

Mapping for any particular renderer is bad practice: http://wiki.osm.org/wiki/Tagging_for_the_renderer
If a renderer is having trouble with valid & accurate data (e.g. a tag it doesn't recognise) then it is the renderer which must be fixed. Corrupting the data is the wrong approach, for so many reasons.

“The changes I've been making […] in most cases have made the splining much more accurate.”

Splining? I'm not familiar with golf terminology.

Made them more accurate how, based on what (source)?

OSM is about mapping what's on the ground, in an accurate & verifiable way.

“I had assumed that I wouldn't be intentionally upsetting any other users with my changes”

OSM is a collaborative community (by necessity). Mappers must be mindful of this.
Other mappers are the basis for quite a few meta-features:
▪︎changeset comments
▪︎best practices (like small area changesets)
▪︎citing the source of changes
▪︎…

OSM isn't purely about producing a map; it's about managing a dataset (to ensure, as best we can, quality). A whole bunch of metadata (see the above list) is useful to other mappers (in various ways, in several situations).
Where data came from is also an indication of its quality (accuracy & recentness).

Many in this community care deeply about proper management of the project & maintenance of the data.
It's not a game; important things rely on this data. Messing it up has real-world effects.

Dedicated mappers often monitor their local area for changes. Both to be aware of relevant changes (by other mappers), and to catch errors (e.g., inexperienced newbies, or someone copying from proprietary sources).

Reviewing & verifying changes is part of the culture. For many excellent reasons. Just like at Wikipedia, or a software development source-code repository.

“because I made the changes on different days, different times and at different locations.”

Irrelevant. What matters is the quality of (your) changes.

I get the impression that you may be trying to fly under the radar with dubious changes. That's not gonna be received well, if it's the case.

“Now I know that the auto comment selection is actually directly linked to the change set geography.”

Again, incorrect. See above.

I strongly suggest that you do a bunch of reading, at the wiki, before making any more changes.

“The use of OSM for golf course is a very large community and ongoing thing.”

While that's fine in and of itself, that isn't excuse or justification to alter OSM against established policies for the benefit of some niche at the detriment of others.

When editing OSM, a golf game should be the furthest thing from your mind. It's always secondary to what's best for OSM.

If, in making quality changes, you want to focus on golf courses, then fine. The problem is if those changes are done for the wrong reasons.

Ignoring the rules is taken seriously, here. Bad changesets will be reverted. Persistent disruption will invite admin-imposed blocks on your account.

“The changes made by course designers will be kept within the boundaries of the course and are only ever improving the accuracy of the splining and map features within those golf course boundaries.”

Again, irrelevant. All that matters is quality (accuracy of representing what's on the ground, being verifiable, done so within existing conventions (e.g. tags used) & policy, else adhering to consensus of other mappers).

Bad changes are bad regardless of who makes them. Likewise for good changes.

The question of if changes are an improvement is decided by the community (and ultimately the Data Working Group).

Changes are only improvements if they serve OSM's goals (an accurate map).

“Things like footpaths that are actually golf walking paths or golf cart paths.”

If that's actually the case in reality, and the tagging used is acceptable (rather than ignoring existing conventions), then yes. Similar to marking stairs (via survey) along footpaths which were added from imagery. So long as there are actually stairs there, in reality.

“Correcting these not only benefits the import into the game, but also makes the OSM for that location even more accurate.”

This is where my concern lies, and I feel that your priorities (in terms of making changes to OSM) are backward.

Using OSM data (for a game or whatever else) is fine (so long as the license is obeyed). But, using existing data is one thing. Changing it is another.

A bit more bluntly; for me, personally, I don't really care about golf. My attitude toward data being used for games is benign indifference. It's not a problem, but also isn't deserving of any special treatment.

However, if you merely perceive OSM as a means to an end, then your motivation for editing is coming from the wrong place.

Primary focus should be OSM itself. Using the data in a simulator is secondary.

Manipulating the data, in a way optimised for one particular use, isn't acceptable (and such changes should (& eventually will) be reverted).

If you're making the map (regardless of intended use) more accurate; great.
If you're ‘tweaking’ the data for the benefit of some game / simulator; definitely not.

The difference comes when the interests / incentives between what's best for OSM versus a golf game, don't match, and you must choose.
It sounds like you're always choosing the secondary use, in spite of the primary.
This is wrongheaded.

The solution is to make the secondary use (golf simulator, or whatever) match the interests of OSM. So that importing data is conflict-free.

Expecting OSM to adapt to a golf simulator, is backward, and an attempt to ice-skate uphill.

“After all it's imperative that LIDAR data and OSM data align as closely as possible to achieve a satisfactory course design on golf simulators and games.”

Again, I disagree with your priorities.

There are many problems with this approach / attitude.

Firstly; where's this LIDAR data coming from? What copyright license applies? Copying (into OSM, which includes importing) from proprietary sources, is not allowed (because copyright law).

Secondly; how is the alignment being ensured? See the wiki for details about the problems relating to alignment of aerial imagery.

Thirdly; since your concern seems to be having OSM match some other (LIDAR) dataset, rather than determining if the dataset is worthy of and acceptable for inclusion into OSM; how is the recentness of the LIDAR data being ensured?
How is it captured (to ensure accuracy)?
What QA filtering (if any) is being applied?

Fourthly; the rules for importing a dataset into OSM are even more strict than for manual editing (again, for good reason). See the wiki.

Blindly importing datasets is a bad idea.
Importing should only be done if the requirements are met. If not, and the conflicts can't be resolved (e.g. in an incompatible license), then the data shouldn't be imported.
OSM itself trumps any particular external dataset, regardless of any individual's personal interest.

You're always free to export OSM data, apply whatever changes / imports (not withstanding copyright problems; but that's then your concern & liability) to that exported set, and use the result for whatever you wish.

Wishing to apply the same changes upstream (to OSM proper) means doing so by OSM's rules.

“Hope my long winded reply helps to clarify your concerns.”

Long-windedness is fine by me. Sadly, however, my concerns are stronger, rather than satisfied.

“[…] thank you for pointing out this huge area changeset. I had no idea that was happening.”

👍

“I'm grateful for you explaining how these changesets work.”

You really should ensure that you do understand how they actually work, before making any further changes: http://wiki.osm.org/wiki/Changeset .