I’ve come across a golf course where two of the holes have the closely mown fairways that surround the greens. I noticed that the fairways are designated as lines with the relation as outer and the greens designated as areas with the relation as inner. Based on the Wiki this appears to be wrong. Here is a link to that Wiki page------->File:Golf.png - OpenStreetMap Wiki In this Wiki example the rough area island is located within the fairway and is tagged as an area (golf=rough) with the relation as inner. The fairway is tagged as golf=fairway with the relation as outer. Is this correct? If it is,
then it seems to me that the same designations would apply to a putting green area that is surrounded by a fairway area. Clarification would be appreciated. Thanks.
Maybe it would help if you linked the relevant objects of interest.
In general, what the graphic wants to tell you is that the different golf=bunker/grass/rough/fairway areas must not overlap. This can and usually does require a multipolygon, which is a relation with two or more lines of which one is the “outer” and the others are “inner”. You can think about it like you are subtracting the “inner” areas from the “outer” area.
Thanks for raising this here. Can you explain a bit more about where you are seeing things “designated as lines”? Is that in some consumer of OSM data, and if so which one?
With some research, I believe this is the area of interest, hole 10: OpenStreetMap
and this one, hole 16: Way History: 673745110 | OpenStreetMap
Looking at the history, there is an edit-war going on between @Blixt99 and @Spaghetti_Monster
I took a look at
and @Spaghetti_Monster 's method of mapping is correct.
I seem to remember that we have been over this issue before with the same mappers.
Yet the fairway as currently mapped is an area, not a line:
And the putting green is another area “carved out of” the fairway.
So it’s not clear why the question about the fairway being a line, or what exactly the edit war is about, as the current mapping already seems to match what @Blixt99 wants?
I think @Blixt99 wants the fairway mapped as a closed way rather than a multipolygon relation, perhaps to work with some golf app that doesn’t recognize OSM multipolygons, or because they are not familiar with the concept of multipolygons in OSM.
To also directly answer the title:
OSM doesn’t have a concept of an “area”. We can only add nodes and draw lines. This is already contentious on its own and many tried to remedy this situation, but that’s what we are working with.
If a line is a closed way (i.e. start and end node are the same), some tags imply that it is supposed to be an area. Obviously area=yes does that, but also landuse and a few others. This is an indication for renderers to please fill that closed way with something.
However, sometimes areas aren’t simple shapes and have holes in them. Like your golf course: The fairway doesn’t cover the bunker or the rough: the fairway has holes. In that case we use a multipolygon, which I’ve explained previously. The holes are either multipolygons themselves, or commonly simple shapes. If they are a simple shape without holes, the inner boundaries become “areas” and are tagged directly.
The outer line doesn’t represent an area, instead it’s the outer boundary of the multipolygon. As such, it doesn’t get any tags - they are derived from the multipolygon relation it belongs to.
@Blixt99 I hope this clears it up. If you have any questions, feel free to reply in this thread.
From what I’ve seen, the other golf courses are mapped incorrectly. If you like, you can make them multipolygons and correct the mapping.
I also found this quote in Changeset: 157023417 | OpenStreetMap which is attributed to @Blixt99:
Just because I’m mapping for use in my golf game course creation editor […]
This lends credence to this theory:
If that is in fact the case, then please contact the support of the editor/golf app, so they can add rendering for multipolygons, given that they are quite common and the Wiki page specifically points out that they are the right way.
@Blixt99 feel free to point the support staff of the app you are using to this thread.
Just to add one more thing that might help to visualise things - this overpass query can query the way in question here, and this one the relation, at different points in time. The latter query (the current state of the relation as I write this) is a valid multipolygon. Any software that processes that for display by a data consumer needs to be able to understand data like that - it’s one of the fundamental forms that OSM data can take.
Every time I have wanted to consume OSM I’ve not had to worry about “how to handle multipolygons” because the available software and libraries for whatever platform have built-in support for them. I seem to remember there was an attempt a couple of years ago to persuade one bit of golf software to understand this sort of data; that’s why I asked which actual software was the problem.
Most likely its GitHub - chadrockey/TGC-Designer-Tools: Tools to support course creation and Lidar/Terrain Creation in The Golf Club 2019.
Other mappers have helped fix issues before Fix OSM path handling by Woazboat · Pull Request #119 · chadrockey/TGC-Designer-Tools · GitHub
The latest changeset by Blixt removed the golf=green inner way from a fairway multipolygon, copied the multipolygon tags to the outer way, and used the golf=green way as an outer member of a new golf=green multipolygon. OSMCha
From what I understand the tool requires the outer way to be tagged which I’ve tried explaining is wrong for multipolygons but I’m not sure if Blixt reads changeset comments or I explained badly since Blixt doesn’t respond to changeset comments.