Proposal:Relation:golf

From OpenStreetMap Wiki
Jump to navigation Jump to search
type=golf
v · d
Proposal status: Proposed (under way)
Proposed by: HuggeK, PizzaTreeIsland, FairwayMapper
Applies to: relation, way
Definition: A scheme for recording the individual courses within a golf facility, the sets of tees each is played from, and the scorecard values that vary between them.
Draft started: 2026-07-28
Proposed on: 2026-08-09

Proposal

Formalise how a golf facility containing more than one course is mapped, and how per-hole values that differ by tee are recorded.

Unfinished Parts:

  1. What tags on the realtion should be used (currently proposed type=golf at Relation:golf)

Plus four clarifications to existing documentation: hole ordering authority(In practise ref=* is used for hole numbering), and which tee an unqualified golf:par=* refers to.

Nothing is deprecated. Existing single-course facilities remain valid unchanged, although can be optionally uplifted to specifically call out a single course within the wider facility. Note that it is also not possible to tag such courses with additional course-specific tags and tee marker information becuase you would be describing the facility/ground and not the course itself.

Rationale

leisure=golf_course denotes the grounds, not a course. Where a club has several courses there is currently no way to say which hole belongs to which, so a 36-hole facility is indistinguishable from an 18-hole one with duplicated hole numbers. Data consumers either guess spatially — which fails wherever courses interleave — or refuse to interpret the facility at all.

The type=golf relation solves this, but as of 2026-07 only ten exist planet-wide, while 6,104 golf=hole ways carry golf:course:name=* directly. The relation is therefore the better-specified option and the far less used one; this proposal aims to settle its definition so it can be adopted deliberately rather than by accident.

On the per-hole keys. Distance, par and stroke index are not derivable. They are registered with a national association under the World Handicap System, printed on course signage and on the scorecard, and they vary by tee: on an ordinary UK card, holes may carry a different par and a different stroke index off the forward tees, and the course total differs accordingly (e.g. par 70 off white and yellow, par 75 off red). A distance computed from mapped geometry is a different quantity from the signposted one and should not be confused with it.

Sub-namespacing on the hole keeps these values where the hole is, and avoids duplicating the tee colour onto every tee area — the colour is already carried once, by the tee marker relation. A data consumer could also route between the last green of a course in what direction the player should go after they have finished a hole onto the next golf=tee - as usually dentoed by an arrow on a regular course guide map in print.

Tagging

Facility

Unchanged. leisure=golf_course on an area, carrying name=*, operator=*, website=*, opening_hours=*, fee=* and address tags. Course-level attributes should not be placed here however they can continue to do so on a facility with exactly one course, but it is preferred that they migrate to the revised tagging structure going forward.

Course relation

Tag Requirement Meaning
type=golf required Identifies the relation family
golf=course required
name=* required Name of the course.
golf:course=* recommended 9_hole, 18_hole, pitch_and_putt, driving_range
golf:par=* recommended Course par. See Clarifications below
operator:wikidata=*, operator=*, architect=*, start_date=*, fee=* optional

Members: the golf=hole ways of that course, empty role, in hole order (where ref=* is authoritative); and optionally tee marker relations (see below), also empty role.

Tee marker relation

Tag Requirement Meaning
type=golf required
golf=tee_markers required
tee=* required The tee set, normally a colour (white, yellow, blue, red) or a number.
distance=* optional Total length of the course from this tee set
golf:course_rating:male=*, golf:course_rating:female=* optional Course rating. The suffix is sex, not tee — the tee is given by tee=* on the same relation
golf:slope_rating:male=*, golf:slope_rating:female=* optional Slope rating
golf:par=* optional Course par from this tee set, where it differs

Members: the golf=tee areas played from by this set. A tee area may belong to several tee marker relations, and a tee set may include several areas. Where one tee position is physically split across disjunct patches, map it as a type=multipolygon golf=tee.

A tee marker relation should be a member of the course relation it belongs to. Membership of tee areas is optional: a mapper working from a published scorecard can record the ratings and totals without knowing which patch of grass is which colour.

Per-hole values on golf=hole

Tag Meaning
ref=* Hole number
par=*, handicap=*, dist=* Primary (championship) par, stroke index and distance
par:<tee-color-or-indicator>=** Par from that tee set, where it differs from the primary
par:<tee-color-or-indicator>:female=** Par from that tee set, which differs from the primary but also has a sex-specific variation
handicap:<tee-color-or-indicator>=** Stroke index from that tee set, where it differs
handicap:tee-color-or-indicator>:male=** Stroke index from that tee set, where it differes from the primary but also has a sex-specific variation
dist:<tee-color-or-indicator>=** Signposted distance from that tee set

<tee-color-or-indicator> must equal the tee=* value of a tee marker relation on the same course. That equality is the join; it is why the colour is not repeated on each tee area.

These are the values as signposted and as registered for handicapping — not distances computed from geometry.

Per-hole values on golf=hole where a course uses the same hole twice (e.g 9 hole courses which play as 18 holes)

The tagging follows the same structure as where a hole is only used once per course, with the introduction of multiple values to represent the respective iterations of the hole.

x is assumed as being the 'front 9' or the first half of the course, while y is assumed to be the 'back 9' or second half of the course.

Tag Example Meaning
ref=x;y ref=3;12 Hole number
par=x;y, handicap=x;y, dist=x;y par=4;5, handicap=12;13, dist=440;470 Primary (championship) par, stroke index and distance
par:<tee-color-or-indicator>=x;y par:red=4;5 - or - par: Par from that tee set, where it differs from the primary
handicap:<tee-color-or-indicator>=x;y handicap:red=12;13 Stroke index from that tee set, where it differs
dist:<tee-color-or-indicator>=x;y dist:red=440;470 Signposted distance from that tee set

Clarifications to existing documentation

  • Distance units. A bare value is metres. Yards must be explicit: dist:white=342 yd.
  • Decimal separator. Ratings use a full stop: golf:course_rating:male=71.8, not 71,8. A comma is silently truncated by most parsers.
  • Hole ordering. Where relation member order and ref=* disagree, ref=* is authoritative. Member order is an editing convenience.
  • Unqualified golf:par=* on a course relation refers to the longest (championship) tee set. Where whole-course golf:par=* varies by tee, the per-tee value belongs on the tee marker relation. This should not be confused with the par=* tag which denotes that specific golf=holes par.

Examples

A worked example of a hole: 

golf=hole
ref=1
par=3
handicap=10
dist:white=182
dist:yellow=134
dist:blue=134
dist:red=118

Why not type=site

As part of the research on this proposal, type=site was considered as a possible avenue. The following reasons were deemed sufficient for it to not be considered an appropriate use.

The relation is not really a site

Relation:site defines the type as grouping objects with a single identity that "cannot be accurately described by other data types", and its Alternatives section repeatedly steers toward a plain area where one works (e.g. "Instead of an intricate site relation, surround the entire property with a single tourism=museum area"). A golf facility can be accurately described by another data type — the leisure=golf_course polygon, which already exists and which this proposal leaves untouched. What the course relation expresses is logical structure inside that area (which holes form which course), which isn't the problem site relations were made for.

No good defining tag

A site relation wants a defining feature tag, but leisure=golf_course already lives on the grounds polygon - repeating it on the relation risks consumers seeing duplicate courses, especially at multi-course facilities (one grounds, two course relations). A course-within-a-facility isn't itself a facility, so no existing feature tag sits comfortably on it.

The tee marker relation doesn't fit site at all

It's an attribute join. Tee areas grouped by colour so ratings and distances attach once — with no "one place" identity, and it nests inside the course relation (nested site relations are undefined). Using type=site for one half of the scheme would split it across two relation types.

Little reuse benefit

The consumers that support type=site treat it as "these members form one named feature", which doesn't match what a course relation is for (scorecards, per-tee ratings, course membership). Golf-aware consumers would need to special-case site=golf anyway, and it would become the only site value with nested member relations and a cross-relation tag join — arguably a bigger addition to site's complexity than a self-contained type=golf is to type=*. A consumer that doesn't know type=golf can simply ignore it.

Why not everything in one relation?

This proposal suggests establishing tee relations in order to create an osm feature that can be tagged with tee specific tags like par values and distances. That solves the issue of the data having to be on all individual tees, which would be redundant and could lead to contradictions. There have been suggestions to put all tees into the main course relation instead and solve the rest via roles and tags. This would simplify the relation structure, but lead to other issues, making this approach over all less clean: Values like distance or par can differ by tee colour and by hole. In theory, that can be used by using nested subspaces in the tags on the course relation: dist:blue:14=* could be the tag for the signed distance of the 14th hole when teeing off the blue tee. There are, however, several issues with that tagging approach:

  • The number of required tags on the course relation would be number of holes (mostly 18, sometimes 9, rarely different from those two) times the number of tee colours (at least 2, often up to 5 or higher), just for the distances
  • The structure of subspace tag keys is not that much simpler than just using a tee relation, especially given that the 2nd layer would be the colour and therefore a wildcard value, even though of course there will be certain standard values that are the same across most golf courses.
  • The subspaces of the tag keys would be different from how they are currently used: tags like operator:wikidata signify to which property of the tagged feature the tag is referring to. In contrast, a dist:blue tag would describe to what feature the dist tag belongs to, at which point it would be cleaner to just apply the tag directly to the (group of) object(s) it describes.

Aside from these cleanness and simplicity arguments, there is an additional problem with adding everything into one relation, which is handling several tees in one tee box:

  • More often that not, on some of the holes of a course, some of the tee colours will share the same tee box.
  • In practice, the tagging on those is done by listing the colours with the established syntax of using semicolons: tee=black;blue.
  • Adding the tee boxes to the course relation and solving the colour assignment with role values would either require adding the tee box to the relation several times with different role values, which is not supported by most editors and is a big point of contention in the hiking route space, or using the listing syntax inside the role value (role: black;blue), which would at least be possible to edit, but would be against the established structure of relations and their roles.

Instead, in our example, the black and blue shared tee box could just be a member of both tee relations, which is something you often already see with other relation structures on osm.

Rendering

Renderers that currently label a facility with a single course name may show one label per course relation and also be able to render colors/numbers of the tees - and also render which features is for what course to easier be able to pick out which features is for a particular course.

Features/Pages affected


The iD tagging schema will also be updated.

External evidencing

Statistics

External discussions

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Relation:golf&oldid=3074583"