Proposal talk:Relation:golf

In regards to comment 2. Should there be an explicit facility → course link?

Resolved: Done - fixed text.

In regards to the 2. Point of comments: — ”the spatial query the relation was introduced to avoid.” - it’s an added bonus but not why we introduced the relation - to actually describe a set of features on the map - in our case courses and tee markers. I think it is wrong to think relations as ”links” there already exist information the that these holes lies inside of a facility - that is what information it represent in the real world which one already have. HuggeK (talk) 19:14, 28 July 2026 (UTC)

Yes technically this could be done with a spacial query. I feel like if I were a data consumer though I would much prefer just being able to grab that info from the relation, that would be much simpler and less error prone, assuming the tagging is done correctly...

I like the idea of tagging the facility as a member of the course, with role=facility. Worldmapper05 (talk) 20:09, 11 August 2026 (UTC)

"Where par varies by tee, the per-tee value belongs on the tee marker relation."

Resolved: Clarified text - fixed in this edit.

Is this statement correct? It sounds like the value belongs on the hole, according to the previous section which specifies par:<tee-color>=* Worldmapper05 (talk) 17:50, 10 August 2026 (UTC)

It´s an unfortunate thing that the game of golf dont have two words for the par on the hole vs the par for an entire course(sometimes but not always depending on what tee marker you chose to play it from) becuase on some courses there can be so big differences in lengths of the hole and in extension the whole course, you get more strokes to complete a hole if you chose tees which are further back. HuggeK (talk) 18:23, 10 August 2026 (UTC)

This could absolutely be better presented and we will make sure to properly explain it in the related wiki articles and this proposal for further clarification. HuggeK (talk) 18:25, 10 August 2026 (UTC)

Abbreviated

Resolved

Why is dist:*=* used, not distance:*=* ? The meaning can be interpreted from the feature, or it can be some *:distance:*=* prefixed. Kovposch (talk) 10:16, 11 August 2026 (UTC)

It is becuase the dist=* key is already in use to describe only a golf holes length and for a whole course the distance=* key felt more fitting. HuggeK (talk) 11:08, 11 August 2026 (UTC)

distance=* is used on route=* for total, and *=milestone for the position there. It depends on the feature. Random abbreviated tags shouldn't be endorsed. It should be meaningfully named to distinguish. Kovposch (talk) 09:21, 12 August 2026 (UTC)

Fair, I agree with you but we need to scope down this proposal and not touch to much already in use how it is used. That would fit another proposal or post on the talk page of that tag to depreaciate it. HuggeK (talk) 09:14, 20 August 2026 (UTC)

dist=* is currently "in use". Voting will make it "approved". That's difficult to deprecate afterwards, worse if more other applications start using it.

If there are tags that are not part of the vote, they should be explicitly separated

Kovposch (talk) 07:19, 21 August 2026 (UTC)

I understand that using distance=* would be the better way, but the dist=* is already in use and we don´t want to have to do an automated edit.

It is not every tag you mention in a proposal that gets automaticly approved, thats for the Proposal:Relation:golf#Features/Pages affected section - and by ommiting this specific tag thats already in use we do not change that pages status. HuggeK (talk) 21:34, 27 August 2026 (UTC)

No single feature key=

Resolved: Created golf=course and golf=course wiki pages.

Unlike other type=* , this relies on tee=* vs golf:course=* , I guess. golf=course can be invented for the latter, with the misnamed leisure=golf_course in mind. Maybe golf=tee_marker for the former. There's a problem with duplicated feature on type=site on standard features without a special site=* feature. Kovposch (talk) 10:34, 11 August 2026 (UTC)

Good point. I think golf=course and golf=course and golf=tee_markers is good - I updated the Key:golf to include these too: https://wiki.openstreetmap.org/w/index.php?diff=3070796 HuggeK (talk) 09:53, 20 August 2026 (UTC)

Why don’t you use roles “hole” and “tee marker”?

Resolved: The ommision of roles in the proposal does not add any new information and is solely tagging for specific editors, a form av tagging for the renderer.

Source of questions: https://community.openstreetmap.org/t/rfc-feature-proposal-relation-golf/146309/19 Nielkrokodil (talk) 18:11, 11 August 2026 (UTC)

This feels like a repetition of data that already exists and would be redundant. FairwayMapper (talk) 18:11, 11 August 2026 (UTC)

On the empty roles

I think roles often are redundant and this is no problem. See bus stops with role “stop” and platforms with role “platform”. For example on http://osm.org/ when you list all members, you jist see “relation 012345”. You have no idea what is behind this random relation number. With a role, it would show “relation 012345 as tee_marker”. This lets you get an overview without need for extra clicks. Nielkrokodil (talk) 18:11, 11 August 2026 (UTC)

If we are tagging for the sake of a specific editor, then that’s a limitation in an editor to not represent it better - that’s tagging for the editor, just like tagging for the renderer wouldn’t that be something that we shouldn’t do?

As said, that will just add more info and I see no hinder to actually tag it like that if you want to do that - but nothing that we in this proposal are enforcing work this tagging schema to work - they would work with either if you name them or not. HuggeK (talk) 19:58, 27 August 2026 (UTC)

Why don’t you add the single tee markers to the relation but nest it in a separate relation?

Resolved: Adressed by Proposal:Relation:golf#Why not everything in one relation?

Source of questions: https://community.openstreetmap.org/t/rfc-feature-proposal-relation-golf/146309/19 Nielkrokodil (talk) 18:11, 11 August 2026 (UTC)

We believe we’re proposing what you’re asking? e.g:

- The main course relation: :Relation History: 20630890 | OpenStreetMap

- The nested tee-set relations:

Relation History: 21100128 | OpenStreetMap

Relation History: 21100129 | OpenStreetMap

FairwayMapper (talk) 18:11, 11 August 2026 (UTC)

The relation you propose contains:

Hole 1 way

Hole 2 way

…

Tee marker relation 1

• • hole 1 tee way
  • hole 2 tee way
  • …

Tee marker relation 2

• • hole 1 tee way
  • hole 2 tee way
  • …

Why dont you do this (no nested relations needed)

hole 1 way

Hole 1 tee marker 1 way

Hole 1 tee marker 2 way

Hole 2 way

Hole 2 tee marker 1 way

Hole 2 tee marker 2 way

… Nielkrokodil (talk) 18:11, 11 August 2026 (UTC)

Why do you use the same type for both nesting levels?

Resolved: The core on what this feedback is we think can be resolved by the Created golf=course and golf=course

Source of questions: https://community.openstreetmap.org/t/rfc-feature-proposal-relation-golf/146309/19 Nielkrokodil (talk) 18:11, 11 August 2026 (UTC)

The relations can exist independently, someone may choose to only map the tee-sets without necessarily mapping the entire course, using the same type allows a level of consistency and relative ease of identification. I think this would remain the same regardless of whether it was type=golf or as suggested elsewhere if we used type=sport + sport=golf FairwayMapper (talk) 18:11, 11 August 2026 (UTC)

Well, I am confused if different things have the same name (in this case its the same type).

You propose a type=golf relation can contain a type=golf relation. But the first level relation ist different than the second one. Because the second one (the tee markers) does NOT have nested relations.

In public transport there are 3 levels of nested relations which I find pretty clear.

type=network contains multiple type=route_master relations

type=route_master contains multiple type=route relations

type=route contains ways and nodes

So, if you want to map tee markers as separate relations, I would give it a different type than the relation which contains all holes’ ways. Nielkrokodil (talk) 18:11, 11 August 2026 (UTC)

Agree with this. Right now the wiki page says type=golf isn’t enough for you to know the type of the relation, and you have to look for the presence of golf:course:name=* to see if it’s a course relation and tee=* to see if it’s a tee marker relation. I think it would be better if this were explicit rather than implicit.maptheworld2050 (talk) 18:11, 11 August 2026 (UTC)

Different type= isn’t a must. public_transport exactly has =stop_area and =stop_area_group , and type=railway has different railway= features (although some could have been =site ).Kovoschiz (talk) 18:11, 11 August 2026 (UTC)

Now fixed as Proposal_talk:Relation:golf#No single feature key= HuggeK (talk) 21:39, 27 August 2026 (UTC)

In the end the type= key is just another tag - why would we need to have multiple? And seeing that the defining tag was resolved under Proposal talk:Relation:golf#No single feature key= this can be used to know which is a tee markers relations or a course and if they can contain other relations or not as specificed on the wiki. HuggeK (talk) 21:08, 27 August 2026 (UTC)

Justification of using type=golf rather than type=sport + sport=golf

Source of question: https://community.openstreetmap.org/t/rfc-feature-proposal-relation-golf/146309/18 from kovoschiz on the forums.

I will link publicly here that the necessity of type=golf for sports individually needs to be justified. type=sport + sport= is enough, as =public_transport and =power are. Motorsports Racetrack Tagging Conventions

golf:course= and tee= can be treated separately. A different type= can be used for each feature, cf type=site + power=plant vs type=power + power=circuit for distributed generation and different circuits.

Kovposch (talk) 18:15, 11 August 2026 (UTC)

A: This is a fair suggestion, and the proposal could reasonably easily be modified to support this path without necessarily altering the overall proposal significantly. I've added this to a shortlist of pre-requisite "must decide" before proceeding to vote. FairwayMapper (talk)18:15, 11 August 2026 (UTC)

The need to have multiple types would be to dicern them and now the proposal have been updated after the feedback under Proposal talk:Relation:golf#No single feature key= by creating golf=course and golf=tee_markers wiki pages. HuggeK (talk) 20:38, 27 August 2026 (UTC)

type=sport could be used becuase there are no wiki documentation for it, but sport=golf can´t becuase as how the Key:sport is already written in the osm wiki - not allowing it on relations and it explictly needs a leisure tag for it: Key:sport#Associated tags. HuggeK (talk) 23:20, 27 August 2026 (UTC)

golf:course:name=* vs just name=*

Resolved: Adressed. Changed to use the name=* key.

Is there a reason why the name of the course is tagged as golf:course:name=* and not just name=*? The latter seems more consistent with the way other features are tagged in OSM. Is it just so you can use the presence of the key as a way to determine the type of the relation? If so I think you might be better served by having separate type=golf_course and type=golf_course:tee_set, or perhaps type=golf + golf=course, etc. (See also #No_single_feature_key=) Worldmapper05 (talk) 20:05, 11 August 2026 (UTC)

Yes, you can see it as an extension of the subspace golf:course=* where it is used for the course - It is born from that people started tagging courses on the facility leisure=golf_course where the facility already had a name=*. HuggeK (talk) 09:10, 12 August 2026 (UTC)

I agree it makes sense to not use name=* when you're tagging a specific hole with the name of its course (it's the name of the course, not the name of the hole). But here you're suggesting to tag the golf course itself with golf:course:name=*, which I think doesn't make sense. It'd be like if we tagged the name of highways with addr:street=* instead of name=*. addr:street=* makes sense if you're tagging something that isn't he street itself, but on the street itself it makes sense to just use name=*. Worldmapper05 (talk) 14:01, 12 August 2026 (UTC)

Your right, this can be better represented. Will change it to use name=*. And then use the explicit tags to denote what kind of relation it is as solved in: Proposal talk:Relation:golf#No single feature key= HuggeK (talk) 09:36, 20 August 2026 (UTC)

Par and stroke index vary by gender off the same tee, and the schema cannot say so

Resolved: Proposal has been updated to reflect options to gender tag par and handicap values per golf hole where necessary

The tee marker relation accepts golf:course_rating:male, golf:course_rating:female, golf:slope_rating:male and golf:slope_rating:female. So the argument that gender is a real, mappable axis is already won inside this proposal. It is only the per hole values that stop at a tee color: par:<tee-color> and handicap:<tee-color>. That is inconsistent on its own terms: under WHS the rating certificate that sets a gendered rating and slope sets a gendered par and stroke index for the same tee, and the scorecard prints all four side by side. In our data 74 of 127 tee sets are rated for both genders, meaning one physical tee box carrying two ratings, two pars and two stroke index allocations.

Measured across our 41 courses, comparing the men's and women's value for the same hole from the same rated tee set:

• stroke index differs on 901 of 1,386 holes (65 percent)
• par differs on 10 of 1,782 holes, and total par differs on 3 of 127 tee sets

One example. The Olde Course (Loveland, Colorado), Orange tee, hole 13: par 4 and stroke index 1 for women, par 5 and stroke index 17 for men. The hardest hole on the card for one player is the easiest for the other, from the same tee box. handicap:orange=* holds one of those two numbers, and a consumer that reads it allocates strokes to the wrong holes for half the field.

This is not cosmetic. Stroke index decides which holes a player receives strokes on, so it decides net score, and in our league it decides who gets paid. A single value per tee is not a simplification of the truth, it is the wrong answer for one gender, delivered with no way to detect it.

The ask: make gender an axis on par and handicap that is orthogonal to tee, the same axis already granted to rating and slope. The suffix ordering is yours to choose. What matters is that gender is not folded into tee identity, for the reason in section 3.Ryan4n6 (talk) 18:11, 31 August 2026 (UTC)

@Ryan4n6 FYI have removed the AI generated pre-amble and broken your points down into separate sections so they can be discussed independently. Generally I would steer away from AI generated content in these discussions since a lot of the 'flavour' that it adds can be difficult to read for non-English native speakers and its prone to waffle (I say that as an AI enthusiast!).

On this point specifically, in my personal experience in Europe at least the notion of sex-specific tees is diminishing fast but in North America I could see how it would be needed. Our belief is that Par:<tee-color>:male could be used, likewise for Handicap:<tee-color>:male. We will update the proposal to reflect this point. Thank you. FairwayMapper (talk) 08:22, 31 August 2026 (UTC)

handicap=* on a hole is a name that will be misread

Resolved: Proposal does not cover scope of changing pre-existing well used tags.

On a hole it means stroke index, the 1 to 18 difficulty allocation. In every golf system I have worked with, "handicap" is the player's number, or the course handicap derived from it. Those are different quantities, and confusing them does not throw an error, it silently produces wrong scores.

stroke_index=* is unambiguous and is what the scorecard usually prints. If the existing usage is too large to move, please at least open the key's documentation by saying what it is not.Ryan4n6 (talk) 18:11, 31 August 2026 (UTC)

The working group behind this proposal generally agree with your point - handicap vs stroke index is a point we have already debated, however have deemed it outside of the scope of this proposal since it materially changes existing tags which this proposal has steered away from explicitly. There may well be a follow up proposal (which might also take care of the ambiguity around leisure=golf_course being renamed to leisure=golf_club) and the aforementioned feedback to deprecate the use of the dist=* key in favour of using the "standard" distance=* key: Proposal talk:Relation:golf#Abbreviated . FairwayMapper (talk) 08:24, 31 August 2026 (UTC)

Tee color is not an identifier, and there is no controlled vocabulary

Resolved: Proposal updated to reflect possibility of strings beyond color as descriptors

par:<tee-color> assumes tee color is a stable, matchable key. Across 41 courses we hold 127 rated tee sets under 44 distinct names, and roughly a third are not colors at all: Triangle, Trike, T-Rex, Palm, Lantern, Jade, Copper-Jade, Graphite, Tour, League, Family, "5", "4/5 Combo". Fossil Trace (Golden, Colorado) rates a set called Trike at 73.3/147 for women. There is no color to put in that suffix.

Two further cases that a color suffix cannot express:

• Combination sets. 7 of our 127 are combos, played from one color on some holes and another on the rest. They are separately rated: Thorncreek rates "5" at 67.9/113 and "4/5 Combo" at 69.3/120. A combo is its own rated entity with its own par and its own stroke index allocation, not a pair of colors a consumer can decompose.
• Gender that is sometimes part of tee identity and sometimes not. Legacy Ridge rates "Women's Blue" and "Women's Blue/White" as tee sets in their own right, while most courses rate one Blue for everyone with two gendered ratings. Any schema that folds gender into the tee name gets one of those two shapes wrong.

The ask: hang the per hole values off the tee marker relation, which already has an identity and already carries tee=*, rather than off a free text suffix in a key name. Then a course can call its tees whatever the scorecard calls them and consumers match on relation membership instead of guessing at a string.Ryan4n6 (talk) 18:11, 31 August 2026 (UTC)

Generally accept the point that the example value of tee-color is overly suggestive - however it's important to note that it is suggestive and is merely a string. It can be adopted to use Triangle, Lantern etc. as per your examples. We will add a footnote to the proposal to that effect. FairwayMapper (talk) 08:25, 31 August 2026 (UTC)

Three nines make three courses, and hole numbers collide

Resolved: Proposal is not intended to handle routing between different courses.

The proposal covers a nine played twice with ref=3;12. That does not extend to the ordinary multi course facility. Three of the four in our rotation are three nines combined into three eighteen hole routings:

• Fox Hollow (Lakewood): Links, Canyon, Meadow, played as Links/Canyon, Canyon/Meadow, Meadow/Links
• Omni Interlocken (Broomfield): Eldorado, Vista, Sunshine, in the same three pairings
• West Woods (Arvada): Cottonwood, Silo, Sleeping Indian

One physical hole is hole 1 of one routing and hole 10 of another. ref=1;10 on the way gives a consumer no way to say which value belongs to which course relation, and no ordering convention rescues it, because the two lists belong to different courses rather than to the way.

The course relation already has ordered members. The cleanest fix needs no new tags: take the hole number from the member's position (or an explicit role) in the course relation, and let ref on the way mean the number on the signage. That removes the need for the semicolon syntax and makes composite routings expressible.

The fourth, Riverdale (Brighton), is two fully independent eighteens on one site, and it shows what consumers do today in the absence of this. Both courses number holes 1 to 18, so anything keyed on hole number alone returns two greens for every number. We separate them by reading golf:course:name off the hole ways, which is a de facto practice, is not in this proposal, and as far as I can tell has never been ratified. A course relation would settle it properly. That is an argument for the proposal, provided it can express routings and not only separate eighteens. Ryan4n6 (talk) 18:11, 31 August 2026 (UTC)

There is no current intent to address routings between different courses in this proposal. The proposal is principally aimed at creating the relevant structure around courses within leisure=golf_course facilities. In this context, the ability to map the three nine holes are dealt with neatly - however the routings between them, are better handled with the loop= concept (also not handled in this proposal deliberately). By mapping each 9 hole course independently, this allows you to change the ordering they are played (and invent new combinations) without needing to change tag structures or create convoluted routing structures. FairwayMapper (talk) 10:52, 31 August 2026 (UTC)

Two smaller things

Resolved: Do not currently believe either of the points require updates to the proposal.

Define the line dist is measured along. The page settles the unit, a bare value in metres with yards explicit as 342 yd, which is more than most golf data sources manage. What it does not settle is the geometry. Scorecard yardage follows the playing line and bends at the dogleg, while the obvious implementation measures straight from tee to green. On a real dogleg those differ by enough to matter, and whichever one a consumer picks, half of them disagree with the printed card and the data gets blamed rather than the ambiguity. One sentence fixes it.

Be careful about inviting tags nobody will maintain. A value that changes weekly, and that no mapper will revisit, is wrong most of the time while looking authoritative. Pin position is the clearest case: golf=pin nodes exist (we counted 169 of them in our own rotation) but a pin is where the flag stood on one morning, possibly years ago. The stable target is the centroid of the green polygon, which does not move and is right on average by construction. If mutable features stay in scope, please say plainly in the consumer guidance that distances are measured to the green rather than to a pin.

I am happy to share the anonymized course, tee and hole comparison behind the numbers above if it would help the vote. ~~~~ Ryan4n6 (talk) 17:54, 30 August 2026 (UTC)

The holes ref= does not define the geometry of a hole explicitly. Since mappers can and frequently do set hole centre lines in approximate locations, it's highly unlikely that any mapper can reasonably mark the exact start and end positions so inferring hole distance from the geometry of the center line is not appropriate. Data consumers should refer to the explicit dist= tag as being authoritative on the distance of the hole as per the scorecard for the course.

The AI's second point is noted but largely irrelevant to this proposal? FairwayMapper (talk) 08:30, 31 August 2026 (UTC)