I've reverted this change (see changeset/161725911 for details) because of two problems. The first is that history was destroyed by deleting someone else's existing work. That is frowned on unless absolutely necessary. The other problem is that you extended the fairway into the green instead of making them butt up against each other.

See leisure=golf_course#Common_mapping_pitfalls for examples of golf course mapping that should be avoided.

And (hopefully) my final update to all of the "North" names in Springfield was made in the following changeset: changeset/161686781. Nice to get this standardized finally. Sssh, don't tell Google. They've still got it wrong in many places.

After seeing the changeset boundary, I realized I made two mistakes. One in Cottage Grove and another in Creswell. Both have been fixed now.

"Something isn't renamed just because a president says so."

Well, if he utters the idea in passing during a speech, that's one thing. But signing an EO and moving federal agencies to officially rename it is a vastly different thing. I hope you agree.

loc_name doesn’t feel right either because it isn’t really a “slang” term. That is the new legal name in the US. int_name didn’t sit right with me either.
Either way, this will be an interesting conversation.

But isn’t “en” too broad of a category seeing as how people that speak the King’s English are likely to still call it GoM (while spilling millions of gallons of crude into it :-/ )

There doesn’t seem to be an official name:en_us (though taginfo does show a single solitary usage of that key). The name change for the US is, or within hours will be, the law of the land.

Hey there Daviskj, thanks for your golf contributions. We all really appreciated it. But I wanted to reach out and correct a mapping method that I saw you use in hopes that it won't spread to further mapping efforts. The problem is what is referred to as "lollipops". On the 7th hole, you created two golf=rough spots in the middle of the fairway (that's great), and then you extended the fairway to diverge towards the rough, circle it, and then back out to the fairway boundary. While the goal of making sure a patch isn't referred to as both rough AND fairway is appreciated, there are better tools to do that. The correct method is to create a "multipolygon" where the fairway is the "outer" boundary and the roughs in the fairway define an "inner" boundary. It creates a topology that resembles a donut. In the iD editor, you want to select the various pieces (1 fairway and 2 inner roughs in this case) and by holding down shift when selecting the 2nd and 3rd objects. Then you can right click and select "Merge", or just type "c" for the keyboard shortcut. It's pretty easy.

If you have any questions/comments, I'd love to hear them. Thanks!

Hey there Evan,
Thanks for contributing to the map. I noticed some problems with some of your fairways that surround bunkers. You are using multiple polygons to surround the item, instead of properly using "multipolygons". See leisure=golf_course#Common_mapping_pitfalls for more information about proper golf course mapping. I've gone ahead and cleaned up but wanted you to know for future mapping that you might do.
Thanks.

Hey there Kenny,
Thanks for contributing to the map. I noticed some problems with some of your fairways that surround bunkers. You are using multiple polygons to surround the item, instead of properly using "multipolygons". See leisure=golf_course#Common_mapping_pitfalls for more information about proper golf course mapping. I've gone ahead and cleaned up but wanted you to know for future mapping that you might do.
Thanks.

Then why did you name it Shashta? :-D

Hope you're doing well.

FYI, restoring this to Fernhill Loop. The Lane County roads GIS has this as Fernhill Loop and a survey confirms. Not sure why you thought it was Forest Ridge.

As someone that went through the days long trauma of having my house incorrectly shown on government maps as being destroyed in a wildfire, I agree that extra care needs to be given to reporting accurately.

LOL. Someone's automation changed "73rd Street" to "73Road Street". Somehow this wasn't a problem on 63rd Street.

Hey there Numac,
Thanks for the golf course contributions to OSM. I notice that you're putting in what I call "lollipops" when you are drawing the fairway around something like a sandtrap. The proper way is to just draw the complete fairway and the complete sandtrap as is, then select them both and "combine" them (in iD) into a "multipolygon". If you need help, please reach out and I'll help you along. Thanks!

High desert golf must be something wild.

Thanks CurlingMan. It's my goal to get all of lollipops in golf courses cleaned up this year. You can read more on the OSM-US Slack server in the #golf channel if you're interested.

The translation of your comment to English makes zero sense, so you’re going to have to translate this for me or I can’t help you.

Hey there mech32. Nice to see that other people are actively working on golf course mapping. Thanks for your contributions!
There is one thing that I'd love to see you (and others) change in how things are mapped regarding fairways and greens. I see a lot of fairways that extend onto the green such that the ways for the green and fairway overlap, which isn't topographically correct. It might look okay when rendered, but isn't the "right way" to map things. It's like your saying that grass in the overlapping part is both green and fairway, which isn't right.
The correct thing to do would be to draw the fairway all the way around the green (extending slightly) and then combine the green and fairway into a "multipolygon" that says this whole thing is a fairway EXCEPT for the "inner" polygon that is the green. Here's an example: way/1232699314.
Alternatively, if it makes sense based on satellite imagery, run the fairway up to the green and re-use the points of the green to define the border between the green and fairway.

If any of that is unclear, please let me know and I'll work to better explain it. Thanks!

Ugh, yes, this is a known issue with "https_all_the_things". See https://gitlab.com/b-jazz/https_all_the_things/-/issues/8.

It happens very rarely though so it hasn't been a high priority (as you can see) over the last 5 years. I can't make any promises, but I'll see if I can dedicate some more time to getting a fix implemented. Feel free to follow the issue on gitlab to get updates.

In the meantime, I'll fix the mistaken edit. Thanks for pointing it out. Much appreciated.