Thanks for getting back to me, and I’m sorry there has been confusing messaging in the past on the issue. We are trying to clear things up with documenting best practices on the wiki and spreading the word.

The problem originally stems from a very popular video that encourages people to *overlap* the fairway and green, which is very wrong. Tens of thousands of golf course holes have been drawn like that and there has been misleading messaging to stop doing that. But the correct thing is to butt them up together and carefully share the nodes at the boundary.

I’ve embarked on a massive cleanup project to fix all of these so people have good examples to follow and I’m also working on chasing down anyone that makes this particular mistake and getting the word out to prevent it from happening going forward.

Thanks for listening,
b-jazz

Please fully connect fairways and greens together (like way/1378169412) by sharing all the nodes that border between them. See the golf_course wiki for examples of what this would look like: leisure=golf_course#Common_mapping_pitfalls

Thanks. Please feel free to reach out if you need help.

RE: relation/18852672

Hi Compo. Welcome to mapping out golf courses, and mapping in general. I want to point out some problems in hopes that you can improve your mapping going forward.

First thing is that you have deleted parts of a multipolygon relation. You can read more about multipolygons on the wiki: osm.wiki/Relation:multipolygon. When you deleted the green, you broke the relation and left the fairway without it's inner boundary (the green).

That leads to the next problem of deleting things in order to recreate them from scratch. There is a core belief that history should be maintained instead of deleted. So it's best to modify that green instead of deleting it. See the wiki: osm.wiki/Keep_the_history

If you have any questions, please feel free to ask.

Please be careful when you join two objects like way/746356398 and the fairway that you share all of the nodes at the boundary, or you get overlap and trigger Quality checks. Thanks.

Yup, I done f'd up. Apologies.

When you say "OSM doesn't play nice with nodes that close together", I'm guessing you are talking about the iD editor, or maybe another editor that "snaps" nodes together when you get close. You should be able to zoom in another zoom level or two which will separate the points enough to make snapping not be an issue.

Vintage Club looks great. That's textbook fairway mapping for greens that don't have an (obvious) fringe.

What makes you say that golf holes must have a total of three nodes? I've never heard that before. I pulled up a bunch of classic, real-world golf course maps and every one of the the par-3, straight shot, holes each had a straight, 2 node, line defining them. Is this a rule imposed by simulators?

For your amusement, check out this golf hole: way/975834938

At some point, I'd like to clean all of those up. Especially where people have erroneously added shared points to every tee, fairway, bunker, and green that they intersect with.

Hi there Aeuri,

I think your creation of multipolygon relations for where greens and fairways meet makes things more complex than they should be. It's best to draw a complete green and complete fairway and share nodes that are on the border of the two objects. iD and other editors should highlight the other object if you get the cursor close to another node. Give it a try and let me know if you have any issues. Thanks.

Fantastic. Thanks. If you run into the problem again, leave it alone and let me take a look at it and see if I can't help understand the problem so that I can come up with better instructions in the future. Thanks.

Hey malifica, when you have a green like way/1377611606, instead of drawing the fairway around the green and sharing a bunch of nodes (because the green is at the edge of the fairway), could you draw the fairway so that it borders the green (instead of surrounding it)? I hope that makes sense. Let me know if not.

I also notice a lot of golf=hole ways that you draw have a couple of points close to each other on the green. What's the purpose of this? Most times I see a single endpoint node in the green.

thanks.

As I mentioned in changeset/162300773, you are mapping the greens incorrectly when you share all of the nodes between the green and fairway when the fairway goes completely around the green. You should either draw the fringe, or you should exclude the green when drawing the fairway, but then and only then should you share the nodes between the fairway/green border. If you don't understand, please reach out and we can work to make it clear. Thanks.

Hey there Gryndn,
I've reverted this changeset because you are handling multipolygons/relations incorrectly.
I understand when you click on something that looks like a fairway and it is missing the fairway tag, there is a strong urge to label it a fairway. However, in these cases, there is a relation in place that correctly tags the fairway. It says that everything inside the outer ring is a fairway, EXCEPT for the things outside of the inner ring. For you to add an additional tag saying the outer ring is a fairway is incorrect because it makes the green a fairway as well.
If you need help understanding the issue, there are a couple of wikis you might find useful:
leisure=golf_course
and
osm.wiki/Relation:multipolygon

Please let me know if you need help understanding this. I'd be happy to help work with you to help figure it out.

iD also creates lots of duplicate nodes at the same exact location. I've reported it before and discussed with the developers but they have bigger fish to fry. I appreciate iD, but much prefer JOSM over it.

Hey there GatewayGolf. It's awesome that you are creating multipolygons when the fairway completely encloses the green (way/1377317684 for example). But don't forget to add the bunker as another "inner" member that multipolygon. Thanks!

Hello Brothers Manoukian. Thanks for the information. You can feel free to update the map to reflect the changes in ownership. You don't need me to do it for you. In fact, as you are local to the change, you would be the better person to make it. There should be a tutorial when you signed up for OSM. There is also https://learnosm.org that can be helpful. Good luck.

Shit. My bad. Sorry.

Unless the units in this building are actually laid out as triangles, they shouldn't me mapped like this. I find it best to use single nodes for each unit.

This has been a fascinating thread. I hear a complete 180 from tpatte and I welcome the new attitude. I am optimistic, but am a little skeptical. My fingers are crossed hoping we can move forward with a better understanding. To whit: I have some comments on the conversation.

>I’d like to clarify that my intent has never been to introduce “test” or “invalid” data into the live map.

Your changeset description specifically used the words "Testing" with a promise to delete at a later date. The change had dozens of golf course elements that didn't exist in the farmland that they were mapped over. You say "my edits were made with a real use case in mind". This only reinforces that this changeset was indeed test data for a "real use case" that might exist in the future. that should have never been uploaded. Can we agree on that? This seems pretty black and white to me.

>The way those users approached the situation felt more like gatekeeping than collaboration, and it left very little room for discussion or understanding.

It's challenging to discuss proper mapping techniques with someone when they claim that standard mapping is "just opinion" and that their "opinion" is equally valid. GIS/topology/geometry has been around for decades and has evolved some rich standards for how to describe things. Multipolygons are the right way to describe things like greens and fairways and the parts of fairways that are greens and not fairways.

>Having a “pain point” is not an excuse for singling out users or treating them with hostility.

The way that is phrased makes it sound like we (myself, Allison, other OSM mappers) have a pain point. Let's be clear, this is your pain point, not OSM's. You have a tool that doesn't handle OSM data correctly and you can't expect OSM to bend over backwards to handle this pain point for you. Third party tools need to be fixed. OSM features that aren't handled by said tool aren't to be deleted and recreated in such a way that that particular tool will work. Please remember that you are just one "data consumer" and you live among millions of other consumers. That's why there are standards to work with.

You are not being singled out. As I've said, I watch all golf course modifications in the country and am working vigilantly with mappers that are exhibiting improper mapping. I've worked with over 70 mappers this year alone trying to educate and correct mapping misinformation and other bad assumptions. I'm hostile with none of them, or you. If you can show me where you feel I've been hostile, I'd love to see the example so I can adjust further interactions.

I'm looking forward to working with you to be the best golf course mapper you can be.

I follow ALL golf course mappers (in the US). Enforcing community standards is not "harassing". I welcome you involving data@openstreetmap.org. It would be good to get them involved.

I'm not "picking" on you. We all need to follow the same rules and you appear to show no respect for the rules and flaunt how you plan ignore them.
If your use case involves placing test data on the production instance, maybe your toolchain needs to be reworked. I don't see others creating "test" data. At the very least, draw your vandalism on Null Island instead of legitimate map locations.

Reverted in changeset/164694035. Do not upload test data to OSM. Use the dev instance of OSM for that.