How to map a Disc Golf Course (Proposal)

General talk Tagging general discussion
1

Relevant link: Disc golf - OpenStreetMap Wiki

In this post, I would like to discuss how to map a Disc Golf Course (DGC). I have given this some thought, and feel like I have a sensible proposal for do’s and dont’s. The goal is to reach some consensus on how to map DGCs, and put that information into the linked OSM wiki entry for Disc Golf. The format is stating how I think it should be, and providing a reasoning after each point (in drop down to facilitate an overview of the proposal).

My proposal, with relevant discussion:

1) Add a node to represent the course, not an area. Tag the node with leisure=disc_golf_course and sport=disc_golf. Place the node at the course map if one is available, and next to the first tee if not.

Reasoning The area of a DGC is ill defined. The well defined points of a DGC are the tees, hole (reccomended disc flight path), and baskets. These are all tagged with disc_golf=*. The true area of a DGC would be the area in which discs typically land, which is extremely hard to define, and could overlap with buildings, water, and other areas.

Furthermore, the area is often part of a park or other area, meaning that the entire DGC area would overlap with an existing area, which is not ideal.

I therefore feel it is most sensible to tag the area as a node. The node should be placed near the start of the course to make the map data useful, as this is the point anyone wishing to use the course would navigate to.

2) The node should be named in the format “NAME Disc Golf”, where “NAME” should be consistent with the local part of the name of the given course in the UDisc app (if one exists). If there is no UDisc entry for the course, use the name of the local area.

Reasoning Including "Course" at the end of the name would make the names very long. It would also be redundant information (with the `disc_golf_course` tag added).

“Disc Golf” should be included in the name tag, as “NAME” is typically the name of the local area, and would be confusing on it’s own.

A space should be included between Disc and Golf (Common misspelling. I decided which one is correct based on the title of the wikipedia page, and the fact that “discgolf” returns about 33 million google hits, versus the about 78 million of “disc golf”).

Finally, “Disc Golf” is quite international and simple, and is easy to understand for just about anyone interested in the sport. This makes it well-suited for being part of the reccomended name-template.

3) If the tees, holes and baskets are mapped, these should be put into a relation together with the leasure=disc_golf_course node, using a type=site relation. The name of the relation should be identical to the node, with " Park" appended.

Reasoning Relation type "site" is defined as "A site relation is used to group several objects which together have a single identity as a whole but cannot be accurately described by other data types.". This feels perfect for a disc golf course, meaning that an appropriate relation can be added without introducing a new relation type. There is also a `sport` relation, but I was unable to find documentation or usage of this tag, and "site" feels appropriate.

The name could be consistent with the node because consistency is nice, and appending " Park" to the node name seems appropriate. It is also possible that if no guidelines exsist, many different relation name styles would be used, with a mix of local names, “Disc” “golf” and “park” with any combination of spacing, etc.

4) If available, add the udisc link as website=, the number of holes as disc_golf:course=, and par for a layout using all holes as disc_golf:par=. Par should be for the most commonly played layout (If unsure, prefer par for a layout that uses all holes exactly once).

Reasoning A lot of additional and usefull information is available for most DGCs on UDisc's page. It is **THE** authorative source of DGC data. As it is something that most users would want, and should be easily accessable from the node.

The number of holes and par for the course are easy to add, and important characteristics of the course. They should therefore be added. I do not know from where the latter two tags originated, but found them for most of my local disc golf courses.

Example

I have now mapped my local DGC in this manner, which may provide a useful point of discussion. I can not yet see it on openstreepmap.org, but it is added in this changeset.
I have also aligned Egeland Disc Golf Park to this style (see node and site relation)
Take a look, and see if you find it reasonable.

For context, the current results for disc_golf_course are a mess, with a mix of tags:

image
image557×718 36.4 KB

Important note on automating this task.

From the UDisc webpages, e.g. Øksnevad Frisbeegolfbane - Kleppe, Norway | UDisc Disc Golf Course Directory | UDisc, one can append /map to the url (Øksnevad Frisbeegolfbane - Course Map | UDisc Disc Golf Course Directory) to get an OSM map with the course details overlaid! This means that if someone buildt a tool/bot that scrapes this data and adds it to OSM, all courses can be perfectly mapped, possibly even with the leisure=disc_golf_course at the physical course map/next to tee 1. I believe the UDisc data is used to produce the physical printed maps, meaning that using that data would result in perfect consistency. Perhaps this could/should be done in collaboration with UDisc.

2

Am I correct in thinking you intend to mostly follow the golf tagging with the exception of the big areas that are less defined in disc golf?

RE: 1): If you’re creating a relation per item 3 then double tagging the course on the node is violating One feature, one OSM element which is a long standing principle in OSM. Overlapping areas happens all the times and generally doesn’t cause issues unless they share the same key. The concern about vaguely defined areas does sound like a good reason for avoiding area tags outside a dedicated course though.

RE 2): I think this goes against the “name is name only” principle OSM generally holds without a strong rational (sport is adequately tagged). It should be named according to signage and how it is referred to locally. Third party databases re generally no acceptable sources and aren’t relevant to OSM’s “on the ground” principles.

RE 3): see notes about name for item 2, invented names for convenience in the database is generally discouraged. If they need to be augmented for display this can occur in software.

RE 4): The usage for website is already well defined. If there is a signed website or one run by the operators then that should be the one used, not a third party’s.

There are very strict Import guidelines for this sort of thing that must be followed.

I don’t think this would succeed on OSM’s general policy on copying other maps and for similar reasons to the ban on info from Google. According to the UDisc terms:

Content on the Service may not be used, copied, reproduced, distributed, transmitted, broadcast, displayed, sold, licensed, scraped, or otherwise exploited for any other purposes whatsoever without our prior written consent. We reserve all rights not expressly granted in and to the Service and the Content. You agree to not engage in the use, copying, or distribution of any of the Content other than expressly permitted herein, including any use, copying, or distribution of User Content obtained through the Service for any commercial purposes.

I’m no lawyer, but that seems fairly clear on the “no reusing our stuff” front and if they’ve built a business around this data then the chances of them changing their mind and giving it away for free seem … slim.

1 Like
3

I have not looked to golf as a reference, but more or less yes.

I gave this some further though, and put those thoughts into a new comment, as this is the key issue. Please read that instead.

My old reply You are absolutely right, I did not realize that a relation counted as a feature. The relation feels more appropriate, which unfortunately implies that we should have no node. Do you know if a relation is sufficiently discoverable by mapping tools that it would be a good solution, keeping in mind that we want people to search for and navigate to the disc golf course?

If there is no node for courses with the holes mapped, then the physical course map should be a node with information=map (and sport=disc_golf?), and included in the relation of the course.

My reservation about recomending relations is that I believe that in using OSM, I would much prefer a node to a relation. It makes it easier to navigate, see on the map, and look for information at. But perhaps the ideal solution would be for the mapping software to represent relations and non-natural areas as nodes instead. This is what something like google maps does, and it is just the best version of representing places on a map. Is something like that even feasable?

More context on “name is name only”:
" The names should be restricted to the name of the item in question only and should not include additional information not contained in the official name such as categories, types, descriptions, addresses, refs, or notes. However - if something has the official name “East 110th Street” this full name should be in the name notwithstanding the fact that the “street”, the “110” and “east” might be deducible from some other information."

I know personally that whenever I would refer to a disc golf course out of context, I would say e.g. “Øksnevad Disc Golf”. Whereas for a shop, I would not say “Wallmart grocery shop”. Because I would often include “Disc Golf” in the name, it still feels more appropriate to me. Especially when the name is otherwise just the name of the local area.

But given the emphasis on local naming, something like name=Øksnevad Frisbeegolf (local, norwegian) and name:en=Øksnevad Disc Golf would seem close to ideal. Local sinage would determine the local name, but it would greatly aid discoverability to recomend including an english name in a standard format.

Good point. However I feel like this is a special case, as for me and those I know, UDisc defines the correct name. But I have only seen it consistent with local sigage, so it is more about where to get the information, as there is generally not a conflict. So the guidelines should emphasise the sinage, and read more like “The course name should be determined acording to local signs (e.g. the course map), and the name used locally. Typically, information from relevant websites (e.g. UDisc) will match the local signs, and may be used to set the name of the course until local signage has been investigated.”

There is the operator:website key, which seems more adequate for linking to the operator, no? For usage, the udisc website is far more relevant. Operator websites are more about the legal sides, such as parking, with less information about the actual course (Generally no reviews, layouts, pictures etc).

So web scraping is likely illegal and should be avoided. Gotcha.

4

On node vs way vs relation:

Way (Area) is out of the discussion due to being ill defined.
Relation seems a little off, as the different types of relation do not have much in common with a disc golf course. Furthermore, they are generally not renedered or searchable, as they can contain any other node/way (This discussion seems quite sensible, and recommends to only use relation=site as an administrative tool).

So what if we give up on linking all the nodes/ways, and just accept that there is no formal/techincal link? This would allow us to make no relation, and instead represent the course as a searchable, renderable node at the start of the course, which is where most of the value of the mapping efforts come into play.

5

quoting myself from a recent comment on discgolf issue on github:

I built a protoype of some overpass query discgolf map
Planet Discgolf

while doing it and mapping various courses I am not quite sure if the current scheme is perfect for rendering holes yes.
For example because there are courses with multiple “layouts” ( different teepads for different skill levels )

That would better be discussed in a topic on openstreetmap forums

But as for rendering on openstreetmap I think.

a: sport=disc_golf should be shown as a POI like it is already done in osmand for example ( or my prototype )
b: disc_golf=basket and disc_golf=tee should be rendered as they are clearly physical objects and I don’t see a change about these features for the problems I encountered.

osmand uses sport=disc_golf

as far as I see it on my map it is the Point that should be close to a parking place ( and maybe a infoboard )
so if you use osmand to filter the poi and then drive to it the routing is to the next possible parking

leisure=disc_golf_course in my opinion should be used to group holes to a course

6

As for

disc_golf=hole way and
leisure=disc_golf_course relation

I am currently struggling in finding a perfect solution that includes something that exists on some courses:

multiple layouts for example this one:

where there would be multiple disc_golf=hole, ref=1 holes that then maybe belong to different relations

Discgolf Caurus Egra RED
Discgolf Caurus Egra Blue
…

this is not implemented yet on my Planet Discgolf map as I am still trying to find flaws in it

7

For some reason i just now thought about searching here. I expanded the Wiki recently so there is at least some information there and added a sketch Tag:leisure=disc_golf_course - OpenStreetMap Wiki
Quite some information is not consistend on what you would like to be there.
Edit: And yes, i looked at golf_course for quite some stuff.

  1. Node or relation.
  2. Depends. My local is called “Discgolf Salzachsee” on UDisc its called just “Salzachsee”. I will go with whats it called locally (talk with people from there or there is a map or something like that) not with what udisc think is correct.
  3. The relation should be type=disc_gold_course
  4. No, if there is a website, us the website. contact:website=* and contact:udisc=* maybe.

On your “Import from udisk” - Terms | UDisc does not look like OSM should import anything beforehand without an written exception from the company thats available in the osm-wiki as well.

@zEn
Your site or your rendering is quite beautiful i have to say. Thanks!

Today i added a course and i checked some courses

Whats your input on all this, the wiki and the relation i added today? Should it be possible to include mando and drop zones as well?

Thoughtprocess is like this:

  1. Easy: Drop a node with the relevant information on the starting point or where the map is.
  2. Normal: Map the hole as way, add information to the tee, the hole, the basket, collect the holes(just the ways!) into a relation.
  3. Hard: Map everything individually and collect each hole into a relation and then the hole-relations together in a big disc_course_relation?

But maybe just the simple and the normal mapping is quite enough.

8

I created a custom style based on the wiki to make taggin easier Custom Map Style for JOSM for disc_golf_course - #11 by Negreheb

I have a question now: how should it be handled if one hole has two different hole-numbers?

For example, Parcours | Discgolf Übbser here is a 9-hole and a 18-hole, course.
On the 9-hole the “hole 6” is the “hole 8” on the 18-hole. I could tag ref=6;8 but then the reference on to what course which ref belongs to is lost or missing completely.

How would you handle that? Loose the ref=* on the hole and instead add two different relations that somehow include a ref=*?

EDIT: I got the suggestion to tag the bigger course with ref=* and the smaller one as a “special case” with ref:9hole=* for example. I like that suggestion. I thought at first simply using ref:9hole=* and ref:18hole=* and ignoring ref=* completely but it is probably better to keep one ref.