Proposal:Relation:Sport for golf courses

From OpenStreetMap Wiki
Jump to navigation Jump to search
golf=course & golf=tee_markers
v · d
Proposal status: Draft (under way)
Proposed by: HuggeK, PizzaTreeIsland, FairwayMapper
Tagging: golf=course, golf=tee_markers, type=sport
Applies to: relation
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.
Statistics:

Draft started: 2026-07-28
Proposed on: 2026-09-12

History

This proposal started out in Proposal:Relation:golf, please read that and its Proposal talk:Relation:golf.

Proposal

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

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.

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=sport 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=sport 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=* Primary (championship) par, stroke index etc
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

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

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 par=4;5, handicap=12;13 Primary (championship) par, stroke index etc
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

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

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 (see Super-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=sport is to type=*. A consumer that doesn't know type=sport + golf=course or golf=tee_markers 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, slope, course rating etc. 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: distance: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), for all hole specific tags.
  • 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 which is hard to parse as a data consumer.
  • 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 distance:blue tag would describe to what feature the distance tag belongs to, at which point it would be cleaner to just apply the tag directly to the relation element.

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, e.g, one golf=tee area.
  • 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. We would also loose the ability to put tags on the tee markers themselves as an osm element - seeing that there are different values for what kind of tee you decide to play a course from.

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.

Voting

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