Talk:Tag:leisure=golf course

From OpenStreetMap Wiki
Jump to navigation Jump to search

Driving Ranges

I have seen very often driving ranges being tagged as leisure=golf_course. I don't think that this is correct, because a driving range is not a golf course!

I think a usable approach is to use the following for a driving range
- name=Driving Range (name of place)
- sport=golf
- leisure=pitch

Please see also my comment at Talk:Tag:sport=golf about indoor and simulator golf.

rudi 20:30, 3 November 2013

Most driving ranges are located inside a golf course. So it would not be unusual for it to be inside a golf course. Where it is not there is usually an outer area for stray balls that can be an outer area tagged as a golf course, these usually have practice greens as well so the tagging as a golf course is useful. Warin61 (talk) 05:41, 15 July 2018 (UTC)

Examples of completed mapped golf courses?

Could you please reply with a link to a completed golf course? Thanks.--Cordialement, gerdami 13:20, 18 August 2012 (BST)

this one looks pretty detailed. Don't know if it's a "good" example though -- Harry Wood 01:18, 17 December 2012 (UTC)
It 'looks' very pretty Harry. But it is tagged for the render. There are no fairways, holes, tees, driving range .. only the outer boundary and bunkers carry anything 'golf'. So, no it is not a 'good' example, sorry. Warin61 (talk) 04:32, 15 July 2018 (UTC)

Chehalem Glenn Example of the recently worked Chehalem Glenn. Golf courses are never complete, in fact they change on a daily basis - grass is mowed resulting in changes to shapes like fairways, tee areas, fringe, rough, greens; tees and pins are moved changing the path from tee to green; construction may alter amenities and features. All you need do is change the aerial backgrounds to observe that. The best we can hope for is relative stability. Maps are representative of generally static or time-framed features. Until better functionality is available to switch perspective, a map is as complete as the desired representation. --USGolfers (talk) 15:05, 27 July 2022 (UTC)

Lakes as water hazards

A part of a lake can be defined as a water hazard (yellow stakes) then as a lateral water hazard (red stakes), then again as a water hazard (yellow stakes). Hence, the lake should be composed of several ways with golf=water_hazard and golf=water_hazard. However, a lake remains a natural waterway. I suggest that we use add relation as a multipolygon tagged with natural=water to all ways that compose the lake.--Cordialement, gerdami 14:09, 18 August 2012 (BST)

Replying to myself... In real golfer's life, water hazards boundaries do not share real boundaries of the stream/lake, i.e. water hazard boundaries are between the fairway and and the stream/river/lake.--Cordialement, gerdami 18:27, 19 August 2012 (BST)

I think probably the page should make mention of the fact that lakes should (always!) be mapped as normal (natural=water), then these water hazard tags should be used in addition -- Harry Wood

Since 2019 water hazards and lateral water hazards no longer exist.

2019 Rule: Under the new Rules, “Water hazards” will be superseded by the expanded concept of “penalty areas”, and Rule 17 will provide the same basic options for relief that exist under the current Rules:
* A penalty area will include both (1) all areas currently defined in the Rules as a water hazard or lateral water hazard and (2) any other areas the Committee chooses to define as penalty areas (with recommended guidelines to be provided in the guidebook).
* Penalty areas may therefore include areas such as deserts, jungles, lava rock fields, etc.
* The two types of penalty areas will be known by the colour of their marking: red penalty areas (today called lateral water hazards) and yellow penalty areas (today called water hazards); and Committees will be given the discretion to mark all penalty areas as red so that lateral relief will always be allowed.
* The term “hazard” will no longer be used in the Rules.

Given these updated rules, should we migrate to something like red_penalty_area and yellow_penalty_area? Mattdot

This seems like they can modify the rules in 2 years and we would have to change all tagging again. I think the simplest is to make a note on this wiki that tags golf=water_hazard and golf=lateral_water_hazard should be interpreted as "penalty areas" under 2019 rules. The whoever is using the data knows what to do with it. --Mashin (talk) 15:16, 15 April 2021 (UTC)

Added natural=sand for things that are sand i.e. bunkers

I added natural=sand back in for this. I missed this before and I think Harry misunderstood my comments previously as natural=beach is wrong but natural=sand is correct. There is no reason not to add this. —Preceding unsigned comment added by Rovastar (talkcontribs) 2014-05-20 15:38

I think surface=sand is better. Using surface makes it clear that this tag is secondary to the golf tag. Warin61 (talk) 04:53, 15 July 2018 (UTC)

What is natural in a bunker?

natural=sand is just wrong for a bunker, but I do not know another wa to get it rendered. —Preceding unsigned comment added by Fx99 (talkcontribs) 2014-09-13 08:49

Agreed. This issue is mentioned in this request to get golf features rendered on the "standard" OSM map: Neuhausr (talk) 16:40, 24 November 2014 (UTC)

surface=sand should be used. natural=sand is for a way that has no other primary tags. The primary tag here should be golf=bunker (or in at least one case greens are made out of sand). Warin61 (talk) 04:36, 15 July 2018 (UTC)

Hole as way or area?

I noticed that there are two entries for golf=hole. The older one (and seemingly more common usage) describes golf=hole as a way, similar to how it is often depicted on golf cards, using the "standard playing path" or something like that. The newer one describes golf=hole as an area encompassing all parts of the hole and says this is preferable.

First, I am wondering who came up with this idea--there's no reference to a discussion or anything, and I don't recall anything on the tagging list.

Second, I'm questioning if this is the best idea. The bounds of a golf hole are not always verifiable on the ground (much less from imagery), but the different parts of a hole (tee, fairway, green, etc) usually are pretty easily identified. So, it seems easier and more accurate to trace a way from tee area to green for a hole than to try to draw a way encompassing the whole area of a hole. In addition, drawing hole as a way would align with the typical golf convention.

Personally, it sounds unnecessary, but if people want to group the components of a hole together, it seems like a site relation would be a better idea. Neuhausr (talk) 16:37, 24 November 2014 (UTC)

It has been two and a half years since my comment without any reply, so I have merged the way and area sections. I looked in taginfo and overpass, and it looks like the vast majority of golf=hole are linear ways, so that is reflected in the wording. Neuhausr (talk) 16:06, 18 April 2017 (UTC)

Why abbreviate GUR?

If we don't abbreviate other long tags such as "out of bounds" or "lateral water hazard", why abbreviate "ground under repair"? In general, obscure abbreviations are frowned upon. Neuhausr (talk) 16:43, 24 November 2014 (UTC)

I agree that we shouldn't abbreviate the term. As it was added only recently without any formal procedure I'm aware of, it would be acceptable to simply change this value. --Tordanik 23:00, 24 November 2014 (UTC)
I can't find it used at all in taginfo, either, so I will change it on the wiki page. Neuhausr (talk) 21:49, 25 November 2014 (UTC)

Relations not allowed???

I saw that it was proposed to not use leisure=golf_course on relations - I really do wonder why, and I have two examples why this is really not a good proposal

  • Some golf course are mapped re-using existing ways/lines to form a boundary, e.g. the boundary of a street and a river bank, etc..; whether that itself is good or whether one should just reuse the nodes in a new way is a different story on a much higher level than golf courses; but it is a fact that several courses are mapped using that approach
  • Many courses consist of a number of smaller areas that are not connected. Each of these by itself is NOT a golf course, but the union of them is - that is a classical multi-polygon in my point of view!

Thus, can someone bring some arguments why relations are not suitable for this tag? Otherwise I will change that ...

--Rudolf.mayer (talk) 10:42, 4 January 2015 (UTC)

Personally I think it would be OK. In most cases the type would be 'site'; in some cases it might be 'multipolygon' if there are residential areas inside the golf course, as in the case of this golf course --> . --Ceyockey (talk) 00:54, 13 January 2015 (UTC)
The only relation that really makes sense here are multipolygons. And these are included in the area icon. --Tordanik 09:09, 21 January 2015 (UTC)

Hole number or name

Not that I'm a golfer, but doesn't each hole have a dedicated number and/or name? --Skippern (talk) 12:22, 4 January 2015 (UTC)

Fairway and Green -- a multipolygon?

Wondering whether the Fairway and Green should be modeled as the outer and inner elements of a multipolygon as in this case --> . --Ceyockey (talk) 00:44, 13 January 2015 (UTC)

Rendering of Greens and Tees

As far as I can see, greens and tees are rendered the same color as fairways. If the fairway wraps around the green - or even if it just comes up to the front of it - how are you supposed to tell which is which? --ManitobaMark (talk) 21:16, 8 February 2016 (UTC)

A dedicated golf map could differentiate between tee, fairway, and green areas. I would not expect the standard tile layer map to do so, although if you had ideas you could always submit a pull request at the Github issues page for the "openstreetmap-carto" style. Neuhausr (talk) 16:11, 18 April 2017 (UTC)
The osmfr map renders the Greens, Tees and Holes from layer 16, see example. This should also be introduced in the Mapnik. --geozeisig (talk) 06:53, 26 April 2017 (UTC)
I like that rendering, and there are open issues on github requesting better golf rendering. From looking through a few of them, it appears this is held up by trying to get the golf key loaded into the database, which is being done at the same time as a number of other changes. See issue 1504 Neuhausr (talk) 14:05, 26 April 2017 (UTC)

Rendering of fairway

Why should we use surface=grass and not landuse=grass? 81% of users use landuse. So it is a vote with the feet for landuse. It has the great advantage that it is rendered. --geozeisig (talk) 07:11, 26 April 2017 (UTC)

This gets into the whole landcover/landuse/surface argument, which personally I don't have a strong opinion on. Since 99.9% of golf courses use grass, using any of these tags is extremely redundant--one can reasonably assume the tee, fairway, and green are all grass unless otherwise indicated--and when landuse=grass is being used, it's just so the features will show up on Once golf tags get rendered on their own (hopefully it will happen someday!), I'd advocate for removing the need for grass tags, both surface=grass and landuse=grass. Neuhausr (talk) 14:20, 26 April 2017 (UTC)
In my opinion, inventing landuse=grass was a mistake in the first place, as "grass" is simply not a "landuse" by any stretch of the imagination. Plus it's considered a feature on its own, whereas surface is used more frequently as a subtag for another feature, which makes it more suitable here. Whether or not it's currently rendered by any particular renderer should be irrelevant. --Tordanik 15:33, 30 April 2017 (UTC)
I agree with you that landuse=grass is not a very good tag. But in case of golf course the grass is essential and the land is really used for growing grass. So I can live with it. Of course it would be better if surface=grass or landcover=grass would render in default layer. But that is not going to happen it seems. Chrabroš (talk) 23:52, 30 April 2017 (UTC)
Meanwhile, I have also come to the conviction that surface=grass is the right solution. I also wrote on [1]. Maybe we rendered it in the future. As long as I use
One view point is, what is the primary tag? Using surface makes it very clear that the surface tag is secondary to fairway/green etc. As far as the human use of the land .. it is a leisure activity for playing golf! At least one golf course grows no grass - they use artificial grass when required... too little water to waste on grass. See, that would be a good test of a render that expects grass rather than sand for golf. Warin61 (talk) 04:49, 15 July 2018 (UTC)

Usually the green abuts the fairway and both usually have grass as the cover. If both are rendered as grass there will be no distinction between the two. I would suggest that there needs to be some other way of identifying these objects other than colouring in the area. Probably something similar to the method for administration boundaries where a border is marked in a darker colour. That would leave the centre to be marked with the surface rendering .. not always grass. Warin61 (talk) 00:28, 16 July 2018 (UTC)


I noticed via OSM Inspector that using golf_course as a key was flagged as a misspelled key, but a suggestion was golf:course. I don't see golf:course mentioned anywhere on the wiki, but it has over 2500 uses. Is this in some editor presets or something? It seems fairly widely used--should it be added to this page? --Neuhausr (talk) 16:35, 31 May 2017 (UTC)

Hm, the distribution of the key doesn't look natural at all. Not sure what's going on there. --Tordanik 20:12, 31 May 2017 (UTC)
Good hint. I added it to the Wiki. --geozeisig (talk) 05:45, 2 June 2017 (UTC)

Not all hazards are water.


Not all hazards are water .. so the term water should be removed from the tag value. This would then leave the hazard mapped as a line wherever it is placed by the golf course markers. Rendering can be done as a simple line in the appropriate colour -red for lateral hazards and yellow for ordinary hazards. Then the water/mud/rock can be mapped in the usual way (not using a golf specific key). Warin61 (talk) 00:11, 16 July 2018 (UTC)

Rendering of bunkers

As bunkers are depressions, using similar rendering used for cliffs would give a readily recognisable rendering. A line pointing down in to the centre of the area would be nice, probably a different colour to that used for cliffs. Then the surface tag can be used to render sand/mud etc in the centre of the closed way. Warin61 (talk) 00:17, 16 July 2018 (UTC)

Rendering of a driving range

A pattern of golf balls. It is simple and can be placed over any surface tag. It is what most would expect to see on a driving range after some use - lots of scattered golf balls. Warin61 (talk) 00:21, 16 July 2018 (UTC)


Why not tag with building=yes and description=clubhouse? This conforms with existing tags rather than creating a single tag just for golf clubhouses. Much better chance of it being rendered. It would make golf=clubhouse redundant. Warin61 (talk) 06:39, 17 July 2018 (UTC)

building=* should definitely be used in addition to any other tags! But description is not a sufficient replacement for a standardized, machine-readable tag. The value of description is human-readable freestyle text, so you can't really use description tags for anything except displaying that text verbatim. If you want to highlight clubhouses in a golf map or display the word "clubhouse" in the user's language, for for example, a description doesn't really help you. --Tordanik 17:36, 17 July 2018 (UTC)
OK, what about building=clubhouse? What I am thinking of is that clubhouses don't just exist in golf but in other activities too. Warin61 (talk) 23:31, 17 July 2018 (UTC)

Par for men vs women?

I see

If the par or handicap varies by tee, denote the exception after a colon (for example, par:red=* if the par from the red tees is different than the par from the other color tees

How should it be denoted if the par varies by gender?

Aren't the tee locations deliniated by different colored markers? E.g. red, yellow and white? These do not necessarily correspond to gender: -- Jeisenbe (talk) 05:48, 14 August 2020 (UTC)
There tend to be both men & women's tees of different colours (which can incidentally make a mockery of the hole as a line mapping philosophy as it usually represents the line a scratch male golfer would choose from championship tees). It is not uncommon for the tees for women to be located some distance from the tees for men (e.g., on the opposite side of the fairway). SK53 (talk) 21:06, 6 November 2021 (UTC)


How to tag a  swingolf course, pin… ?

--Pyrog (talk) 10:43, 17 August 2021 (UTC)


I note the previous discussions above.

As stated on natural=sand

bunkers are "*artificial* sand areas".

The sand used has been transported hundreds of miles, bleach cleaned & desalinated. Using natural=sand was 'tagging incorrectly to suit the renderer'. As golf features are now mapped on the 'standard' rendering without the requirement for secondary tags, this should be rescinded in favour of surface=sand.

The above argument also applies to landuse=grass

The iD editor is incorrectly validating golf=bunker, strong-arming contributors into accepting natural=sand (and landuse=grass for other golf features). I've started a discussion on its Github Page: Issue 8748.--DaveF63 (talk) 20:08, 6 November 2021 (UTC)

What does it have to do with landuse=grass? Although I agree it shouldn't be used on playing fields (or anywhere for that matter to me personally).
On top of Talk:Tag:natural=sand#golf=bunker: For your issue, it is a clear example of mistaking the lack of consensus as iD's fault, although they have quite a few problems (and I do have some strong opinions for certain ones). Just ask them to change it to surface=*. This case has no need for blaming.
---- Kovposch (talk) 08:53, 7 November 2021 (UTC)
landuse=grass is incorrectly being used on other golf features (fairways, rough etc) also perpetrated by iD. Golf features /are/ sport specific playing fields/pitches, for which landuse=grass is discouraged.
I have asked iD to change it, as indicated by me posting the Github issue number. Did you not see it?
Both landuse & natural were cases of 'tagging incorrectly to suit the renderer'. They need to be swapped to the accurate tags suggested.--DaveF63 (talk) 15:34, 10 November 2021 (UTC)

Toward The Improved Representation Of The Mapped Golf Course

I've observed that current golf course elements have primarily been structured from the perspective of the golfer, yet there are other stakeholders whose perspectives should be considered and others also that should not. A golf course is a place, most often of business, where most often exclusively the traditional game of golf occurs. That being said, disc golf is also a golf course, as well a newer game of footgolf is also occurring on traditional golf courses.

Element naming and terminology currently related to and representing aspects of a mapped golf course appear to have been developed using the Rules Of Golf as a foundational reference. While this may make sense from a player's perspective it is representative of a limited set of consumers and has been shown to present problems in mapping. In addition, much of the mapping has been performed by users unfamiliar with golf courses, the activities of golf course personal and administrators and even analysis as a general precursor to development. All reflective of quasi-democratic and unstructured open source projects.

That I am a golfer does not make me an expert on the characteristics of a golf course. That I am a software developer does not make me an expert on the structure of golf course map elements. That I've created a golf application does not mean that the design and components of my app are perfect for representation on a map used by all in the community. Yet, any and all of these are valuable contributions to the cause. To be frank I am very surprised at the limited discussion around mapping golf courses considering how many have been mapped: thousands, and how many there are to map: more than 50,000 worldwide. I'm equally surprised that more operators have not provided feedback, positive or negative, regarding the representation of their business, their bread and butter, their family of members using their facility sometimes daily.

I think there is excellent opportunity in open source and OSM. I think it has tremendous potential to not only bring the world through mapping, to users around the world but to also unite people toward common goals and to show everyone the strength and power of democracy in action. Democracy is not a dirty word, on the contrary it represents consideration and extends toward compassion. And this wasn't my idea. Whoever began OSM created it with discussion and talk, the fundamentals of democracy, as its building blocks.

Change is difficult. As a golf hacker I developed muscles counter-productive toward good golf performance. When I decided to focus intently on improving my game I was aware of how much effort I spent letting go of those ingrained habits, until I realized that I was spending time working on the wrong things. To let go of old habits is not to focus on them but to create and apply new ones. As a software developer I've watched many project owners extend the timeline often to death because of their desire to focus on the preservation of what they're trying to change. I am not naive to the difficulties involved in restructuring millions of data points, but with software, unlike muscles, the process can be honed to completion with limited disruption.

I am a passionate person in many things I do and golf, it appears, is no exception. As I'm using the structures currently in place to map a golf course I cringe at the thought of the change required to create and employ elements better representative of and more useful to the broader set of consumers beyond the casual golfer. And I also beam when thinking of the satisfaction and excitement of those same consumers when they see their business, their course, their sanctuary for five hours well represented to the world. I also have a particular golf related project which will rely on the accuracy of mapped golf courses and how its elements are represented. True, I could and had begun to create many of my own elements, bypassing OSM's representation, to accomplish my task but why do so much for only a few when singular effort can benefit many.

There seems to have been little discussion within the last few years around golf course mapping. So, this is the beginning of my discussion Toward The Improved Representation Of The Mapped Golf Course, I hope you will join in on this discussion and, as I do, offer suggestions for new elements and improvements to existing ones. --USGolfers (talk) 21:09, 20 July 2022 (UTC)



@DaveF63: Do you agree that golf=pin typically has no static position and is often being moved around? Mateusz Konieczny (talk) 11:01, 23 July 2022 (UTC)

The golf=hole way also "has no static position", being dependant on the player's ability.
Maps don't describe the real world, they are illustrative, in that symbols and swatches of colour are used as representations. I believe the pin icon, attached to the hole way adds to that representation. --DaveF63 (talk) 23:20, 15 September 2022 (UTC)

Multiple Named Courses in a club

I noticed the golf course near my home wasn't mapped, decided to give it a shot, quickly ran into a small hiccup.

The course in question has three named courses all nestled within each other. So there are, in short, three hole 1s, three hole 2s, etc. To differentiate which holes belong to which course, I have been naming the ways to the hole. These courses don't name their holes like other courses do so this doesn't interfere with the ref of the hole or another potential name. I'm concerned this method won't be viable when I come across a golf club or country club that does name their holes in addition to having separately named courses alongside each other.

What I'm curious about is if there is perhaps a better or more standard method to use when approaching a course that has more than just a standard Front Nine and Back Nine?

I've considered relations to group the ways to hole of each named course together in lieu of naming each way as well.

"I have been naming the ways to the hole." The problem with this is two fold - It's tagging incorrectly to suit the renderer and by extending the length of the string it often prevents the ref/name from being rendered at all.
As you state, the courses are occasionally intertwined & I've seen a couple that share holes. Creating relations when a simple tag will do has always appeared pointless, so instead I've using 'course:name' on the golf=hole name. I haven't documented in the wiki yet. --DaveF63 (talk) 02:46, 16 September 2022 (UTC)
For reference, type=circuit is an idea for racing. Another possibility is something in route=*. --- Kovposch (talk) 06:36, 16 September 2022 (UTC)

Public vs. Private

Say how to differentiate public vs. private golf courses. Via access=* perhaps? Actually I'm talking about

Jidanni (talk) 15:38, 11 September 2023 (UTC)



OSM Carto

Courses render beautifully. Except the boundary between e.g., the Nirfsburble Golf Club, so exclusive that nobody even knows how to spell its name, and the neighboring w:Golf course#Municipal, so non-exclusive that nobody even remembers if it has a name, is nil.

I mean the names, if any, show up, but nobody can see the boundary between the two courses. And no, any fence is hidden in some evergreen trees, so it can't be mapped from air imagery. Jidanni (talk) 15:49, 11 September 2023 (UTC)