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)

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”?

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)

Why don’t you add the single tee markers to the relation but nest it in a separate 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)

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)

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

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)

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)

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

Resolved: Adressed. Already in use.

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)