[RFC] Feature Proposal – Relation:golf

General talk Tagging general discussion
, ,
1

Hello,

We are proposing the creation of a new relation to support the effective mapping of golf course facilities. This proposal covers:

  • Where multiple courses within a single golf facility (leisure=golf_course) exist
  • Where single courses within a single golf facility exist
  • Extends the tagging schema to support data specific to the individual courses themselves (notably, golf tee sets)
  • Is built on general standards/principles from The R&A ( The R&A - Wikipedia ) and USGA ( United States Golf Association - Wikipedia ) who govern the rules of golf.
  • Keeps existing tagging structures backwards compatible

The wiki proposal link is here: Proposal:Relation:golf - OpenStreetMap Wiki

Please discuss this proposal on its wiki talk page.

1 Like
2

I may be missing something here, but it seems to me like this could be handled just as well with a generic site relation with a leisure=golf_course tag on it?

1 Like
3

Kinda, but not really. Combining multiple courses that share the same grounds into separate entities could be done with a site relation, but this proposal goes much further, including golf specific data like tee values, which have no place in the very universal but also therefore unspecific structure of a site relation, which also has to include the option to combine wind turbines into a wind farm entity.

4

You can add any tags you like to a site relation and this proposal’s leaving all the roles empty anyway.

1 Like
5

The first problem we encounter if one would use a site relation with the leisure tag is that the leisure tag describes the grounds - not a relation between features.

6

In response to the relation:site suggestions in this thread, we’ve expanded the proposal on reasons why we don’t feel this is a useful suggestion in the context of the problem we are attempting to solve with the proposal.

Further feedback/debate is very welcome!

7

Thank you. I found 218 relations type=disc_golf_course. It has no wiki page but taginfo lists useful examples.

Also there are 89 relations type=golf_course. (Taginfo)

Is there a reason why not continue this existing mapping? What advantage has type=golf or disadvantage has type=golf_course?

1 Like
8

Its that it is both used for golf courses but also for tee marker relations.

9

I’m very out of the loop here so forgive my ignorance, but what’s the purpose of a tee marker relation?

This is probably a naive take since you’ve obviously thought about this way more than I have, but if I were designing a tagging scheme for this from scratch I’d probably map each course as a relation containing multiple holes (each mapped as a way from the tee to the hole), with the hole info tagged on the holes (par, distance, etc) and the course info tagged on the course. Why do you need a separate relation specifically for the tees? Is the idea that each hole can have multiple tees, and that starting from a different tee doesn’t constitute playing a different hole, even though the par, distance, etc, can be different depending on which hole you start from?

10

Yes, that’s correct.

Each hole can (and by standard rules of golf does) have multiple tee markers - typically broken down into different colours (red/yellow/black/etc). Each tee-set is associated with each golf hole. These tee-sets themselves have their own publicly signposted data associated with them.

One of the course in the RFC Relation: 20630890 | OpenStreetMap has two nested tee-sets by way of example so you can see it in practice.

1 Like
11

That’s a very narrow reading of a wiki that’s always playing catch-up to actual tagging practice.

The relation is spatial as with oh so many things in OSM.

We don’t need a special zoo relation to relate each individual animal enclosure back to the overarching zoo or a special them park relation relating every ride back to the theme park it’s in or a special marina relation tying every bit of dock and black water pump out pump together. Most of the time a tag on the area is enough and on the rare occasions where you have two different things mixed in with each other you use a site relation to distinguish them.

In this case most golf courses are a course with their own grounds. The ones that have multiple courses sharing facilities are just as well represented as multiple site relations as they would be by this with the added benefit that you might get some software recognising them without any special work.

1 Like
12

No it has not! There is no nested relation in it. It has been changed yesterday in Changeset: 187180066 | OpenStreetMap

Please provide an example directly in the wiki so it cannot get altered during the discussion.

Hjälp med Archie igen
13

I have now reverted the change from that user, he is a known offender in using QA tools blindly without changeset or discussions in the Swedish community. Should be fixed now. Your right: We should link to more persistent versions and record in the articles in plain wikitext for it too.

1 Like
14

Don’t know if you people already know about this but you can link to historic versions like this https://www.openstreetmap.org/relation/20630890/history/6 or https://www.openstreetmap.org/relation/20630890/history/8 (the second one being the current version when creating the link>.

2 Likes
15

but this will not solve the question of consistency, because you will have to look at the correct version of all members at a given time and date (e.g. node positions of ways, or state of relation members) to get a consistent reference.

16

I think it’s important to start from a position of shared understanding. leisure=golf_course has existed for a very long time, and has, to date, provided a very effective vehicle for mapping the boundary of a course. What it has failed to do up to this point, is provide a meaningful structure for the definition of courses within that boundary.

For example, leisure=golf_course can quite happily today have multiple versions of golf=hole + ref=5 within the same geospatial boundary. They could as you say be grouped by a site relation but we’ve documented why we don’t see that as a viable solution in the proposal. It gets worse when you then consider that each golf=hole has multiple different tee-sets within them - each with their own required structure and complexity.

“In this case most golf courses are a course with their own grounds.”
I would respectfully disagree. Golf courses technically have explicit boundaries of their own. Practice areas, driving ranges, out of bounds areas, patios etc - all hold distinct boundaries within the wider leisure=golf_course grounds. I think a part of this confusion comes from the misnomer of leisure=golf_course - it should actually be leisure=golf_club - but we’re not seeking to change very well established tags here … just extend the construct to cater for the complex requirements that exist within this micro-climate of OSM.

The Zoo/Marine Examples
I think the difference between your Zoo/Marine examples and the Golf scenario is that the relationships between different tee boxes, holes, and indeed the courses themselves are not just implied relationships - they are explicit.

An animal enclosure being within a zoo is an implied relationship - it is within the geospatial boundary of the other, therefore they are linked. Nobody disputes that. In the same way that a building=yes being within the bounds of a leisure=golf_course can be implied to be part of it. It is very common sense.

The difference with golf, is that the relationships of a specific tee box, and a specific hole on a course are not necessarily implied just because they are within the boundary of the wider golf facility.

For example: Way: ‪Leeds Golf Centre‬ (‪145565160‬) | OpenStreetMap

There are circa 27 golf holes within this leisure=golf_course. As a data consumer, it is not currently possible to:

  • Know which holes belong to which course
  • Know where tee boxes start and which course they relate to
  • Differentiate the distance of a golf=hole + ref=x from the distance of a golf tee-set (bearing in mind, tee-sets are physically signposted and there are circa 100-120k of them globally)

Closing
The Golf relation proposal seeks to solve all of those issues, in a backwards-compatible way. It is an extension and strengthening of the tagging structure which will allow for more complete, detailed and accurate mapping.

1 Like
18

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.

19

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

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

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

1 Like
20

I think it’s a good suggestion and if it moves us past the debate on the specific type= to use to an outcome focused conversation I’m all for it.

Key:sport - OpenStreetMap Wiki - does seem to explicitly reject the use of it though, which is interesting in itself.

21

The wiki template means it’s not used now. It can be proposed.
Some sports are considered as traveling in the open, and are route https://wiki.openstreetmap.org/wiki/Tag:route:inline_skates (I don’t find continuing with network=rin from =rcn as scalable though)