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. Confirm the type=golf course relation (currently proposed at Relation:golf) as the way to record a course within a leisure=golf_course facility, identified by golf:course:name=* and holding its golf=hole ways as members.

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 except on a facility with exactly one course.

Course relation

Tag Requirement Meaning
type=golf required Identifies the relation family
golf:course:name=* required Name of the course. Its presence is what distinguishes a course relation from a tee marker relation
golf:course=* recommended 9_hole, 18_hole, pitch_and_putt, driving_range
golf:par=* recommended Course par. See Clarifications below
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
tee=* required The tee set, normally a colour (white, yellow, blue, red) or a number. Its presence distinguishes this from a course relation
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>=** Par from that tee set, where it differs from the primary
handicap:<tee-color>=** Stroke index from that tee set, where it differs
dist:<tee-color>=** Signposted distance from that tee set

<tee-color> 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.

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 par varies by tee, the per-tee value belongs on the tee marker relation.

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.

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

External evidencing

Comments

Two questions the authors would particularly welcome views on:

  1. Should type=golf carry an explicit discriminator — golf=course|tee_set|loop — following the type=route/route=* and type=boundary/boundary=* idiom? Today the three are told apart only by which tag happens to be present, and one of the ten existing relations is already malformed. With so few in existence this is the cheapest it will ever be to change.
  2. Should there be an explicit facility → course link? Nothing connects a course relation to its leisure=golf_course, so consumers still fall back to point-in-polygon.

Please comment on the discussion page.


| key = type | value = golf | type = relation | definition = Relation type for golf relations. | status = Proposed | draftStartDate = 2026-07-16 | rfcStartDate = | voteStartDate = | voteEndDate = }}

Statistics

External discussions

Comments

Please comment on the discussion page.

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