Yup, encoding problem. This one should work.

leisure=golf_course

Your latest argument makes no sense and isn’t convincing anyone that you understand mapping. If you’re saving your best arguments for another day, I guess we won’t be blessed to read them.

osm.wiki/Tag:leisure%253Dgolf_course

osm.wiki/Relation:multipolygon

osm.wiki/Keep_the_history

First you would need to find out what map provider is used by your vehicle for navigation. Is this something built into your car or are you just talking about a navigation app on your phone?

I see you are adding a bunch of addresses to the building, which isn't the best way to go. I'm not aware of routing software that looks for housenumber1..N. I've added a few address points that would be the "more correct" way to map multiple units in a building.

You should also be aware that there can be a huge lag time (weeks) between when you make a change to a map and when that actually shows up on navigation apps.

I feel your pain. I've dealt with housing complexes that had unnecessarily complex routing issues.

I'm sorry, but this isn't a question of opinions. It's just proper mapping vs improper mapping. And yes, this is a community project and we all need to respect each other's work and abide by a common set of goals and practices. Multipolygons are correct. While the lack of a multipolygon isn't necessarily "damaging", removing a proper polygon is most certainly damaging. Deleting other people's fairway so that you can draw your own *is* damaging. Sloppily drawing fairways across a green *is* damaging.
We appreciate golf simulator mappers filling out golf courses. There is no question about that, but we want them to map according to community standards.
There are well over 20,000 fairways in the US that have the fairway overlapping the green and they need to be fixed thanks to simulator mappers. It's going to take me a year to fix that and try to get others to stop that bad practice.

When you draw the polygon for a fairway, you are saying that absolutely everything within that polygon is a fairway. So even if there is a green in that fairway boundary, you are saying that it is a fairway as well. Both a fairway AND a green at the same time. The purpose of a multipolygon is to say everything within that boundary is a fairway EXCEPT any "inner" relations of the multipolygon. And yes, roughs should be drawn correctly and tagged as multipolygons as well.
I'm guessing you would probably agree, but just struggle because a tool you use doesn't handle them properly.

Thanks for reverting. Just because a third party tool doesn't behave correctly is no excuse to not map properly. There are hundreds of other apps/tools/services that use OSM and they all need to be following the same guidelines.

Are you talking about Chad's Tool? If so, maybe you could pressure the maintainers to incorporate the following fix into their next release: https://github.com/chadrockey/TGC-Designer-Tools/pull/143

It sounds like that might resolve the problem.

That is 100% not true. Can you please tell me why you think that is? If you'd like to join the various forums/communities and discuss there, I'd be happy to join you.

Hello golf course mapper. The lines that define Fairways and Greens should never intersect or partially overlap each other and we noticed that they are overlapping in one or more of the fairway/green pairs in this changeset. If there is no obvious fringe around the green, the fairway should butt up against the green and every node between them should be *shared*. If there is a fringe around the green that is similar to the fairway, the fairway should extend around the green and the two objects should be merged together into a multipolygon (See osm.wiki/Relation:multipolygon for how to create them with your map editor). Please read the wiki for instructions and examples of how to better map golf courses: leisure=golf_course#Common_mapping_pitfalls. If you have any questions, please reply here and I'll gladly help clarify things. Thanks!

Thanks for helping map golf courses. There are some serious problems with your edits however and your mapping needs to be fixed going forward so you don't continue to step on the efforts of others. For starters, read the following wiki: osm.wiki/Keep_the_history on how important it is to *not* delete map elements when you should be updating them instead. You have been breaking multipolygon relations when you do this. You should also read the golf_course wiki (leisure=golf_course#Common_mapping_pitfalls) and the general wiki on how to properly work with multipolygons (osm.wiki/Relation:multipolygon#iD). Until you understand these issues, please refrain from modifying other mapper's work. Thanks. If you have any questions, please reach out and we'll gladly help you.

Where can I get the imagery used for this change? All of the rough drawn in seems more like clutter from the imagery that I'm using (Bing) and could easily be left out and still convey all the important information with fairways and greens.

Benny, did you read the Keep_the_history wiki page mentioned above? You are doing a lot of damage by wholesale deleting elements and recreating them. You need to make more of a effort to reuse existing elements and move their nodes around. This is especially important when dealing with elements that are part of relations. If you don't understand how to deal with multipolygons, you'll need to read up on those as well.

As mentioned in my comments on changeset/163633261, you shouldn't be using joining polygons to define a single feature like a fairway. You should be using multipolygons as described in the wiki page. Please refer back and let me know that you've seen this note. Thanks.

As mentioned in changeset/163866233, fairways and greens (and other golf elements) shouldn't intersect/overlap with each other. Please read the comments on your previous edit, read the wikis and change how you map golf courses going forward.
Please reply and let me know that you've read this note. Thanks.

Why? I can't think of a reason why this should be done. Please revert or explain this to me. Thanks.

Hello golf course mapper. The lines that define fairways and greens (and bunkers and other golf course elements) should never intersect or partially overlap each other and we noticed that they are overlapping in one or more of the fairway/green pairs in this changeset. If there is no obvious fringe around the green, the fairway should butt up against the green and every node between them should be *shared*. If there is a fringe around the green that is similar to the fairway, the fairway should extend around the green and the two objects should be merged together into a multipolygon (See osm.wiki/Relation:multipolygon for how to create them with your map editor). Please read the wiki for instructions and examples of how to better map golf courses: leisure=golf_course#Common_mapping_pitfalls. If you have any questions, please reply here and I'll gladly help clarify things. Thanks!

(See hole 18 for an example of a fairway with this problem.)

I'm sure you feel your edits are correct, but as someone that is very new to OSM, and even seasoned people don't fully understand relations and routes and what not, I can say with confidence that you are likely not using ROUTES in the proper manner. I'm not saying that the block around those three buildings and the grass area shouldn't be named roads. I'm saying you shouldn't have created the route relation(s). If you still think what you've done is right, show me how by quoting passages from the wiki. Thanks.

Thanks for helping with the golf clean-up challenge!

Great, thanks. Yeah, I agree that a "few more" outers won't be too big of a deal. When you get to 2000 outer segments, then we have some real problems. :)

I don't believe a route relation is appropriate here. Those are more typically used for things like bus routes or scenic routes. Not just a collection of similarly named roads.

Any chance I can convince you to keep your segments to a max of, say, 1500 nodes instead of the absolute max of 2000? If someone wants to come along and improve your work, they have to jump through a bunch of hoops to properly divide them, and those can be confusing for newer users that might not fully understand multipolygons and relations. And there are QA tools out there that tag those long segments if they are over 1800 nodes and I want to keep those tools clean by tackling those overly long ways. Thanks.