Royal Aberdeen Golf Club, in Aberdeen, Scotland, Europe, originally known as the Society of Golfers, Aberdeen, is the sixth oldest golf club in the world.

The club has two 18 hole courses, Balgownie & Silverburn, 36 holes in total.

I have this week marked up the two courses using local knowledge and JOSM with over tracing of the sattelite images in the usual way.

How can I mark each hole as belonging to it's distinct course?

At the moment the two different 18 hole courses can be seperated, becasue the Silverburn course holes have no names, where as the Balgownie course holes all have names.

To make the distinction can I draw a way around each course and create a relationship, which is difficult to do becasue the fairways are sometimes mixed together in some places, or is there some way to mark the tags for each distinct fairway & course?

For example, would I do something like add an extra identifying tag to each of tee, hole, pin, fairway etc?

Here is the osm.fr rendering, which I think is clearer and therefore better than the osm.org rendering. http://tile.openstreetmap.fr/?zoom=16&lat=57.18025&lon=-2.07854&layers=B00000000

Ideally this needs to be at the point where an overpass query can produce something useful e.g:

club course hole name distance par handicap

"royal aberdeen" silverburn 1 - etc etc etc
"royal aberdeen" silverburn 2 - etc etc etc
.
..
...

"royal aberdeen" balownie 1 First etc etc etc
"royal aberdeen" balownie 2 Pool etc etc etc
.
..
...

asked 29 Jul, 09:56

ABZ_OSM's gravatar image

ABZ_OSM
3126
accept rate: 0%

edited 29 Jul, 10:11


This is a follow-up to Frederik's suggestions.

I would prefer the site relation to map this. If you want to use a tag, that should be fine as well. Is easier to handle for occasional users, but makes handling data a bit more complicated - you don't have a single object (the relation) but have to search for a specific key and hope that there is no other course with the same name elsewhere.

The tag 'ref_course' is not really a common choice:

  • Tags like "ref_XYZ" are not used much, so it should rather be "ref:XYZ".
  • I wouldn't call the name of the course a 'ref' either, it's still a name.

My idea would be 'golf:course:name' or something similar. There are already a few 'golf:course:XZ' tags used for details of the course itself, so it might be reasonable to use this scheme on parts of the course as well.

permanent link

answered 01 Aug, 19:17

mueschel's gravatar image

mueschel
261
accept rate: 0%

1

Thanks @Mueschel,

I have changed the tags from ref_course to golf:course:name.

This query http://overpass-turbo.eu/s/WFr does limit it's search area to within the specific golf club, which is what a query should do if there is more than one Silverburn or Balgownie Links course across the world which there may be, as you say.

I do not fully understand the process of creating relationships within JOSM. My concern with creating realtionships is that I could create a mess which would be alot of work for me or someone else to undo.

Perhaps relationships are as intuitive and easy as they seem. Certianly it is easy to understand how outer polygons can have inner polygons etc. The concept is easy to understand. But something about it just does not click with me and I have yet to find a good intuitive video or explanatory page with lots of practical worked examples. I did try creating realtionships on the golf course using the https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Relation_Toolbox plugin for JOSM. It still feel I'm creating a tangled mess, so I undid it. It feels like ERD's vs practical implementation in DBRM systems if you see what I mean. I'm not a database person.

(02 Aug, 10:53) ABZ_OSM

For example here is a video of someone adding a speed camera as a relationship, I think, to a road, in JOSM.

I'm sure he knows what he's doing, but it just looks like jibberish to me.

https://www.youtube.com/watch?v=2tnohs_8gFY

(02 Aug, 11:05) ABZ_OSM
2

Don't worry - as long you add just a relation in your changeset, there is not much that can go wrong.

  • Go to the relation window (Alt-Shift-R), click on the plus sign to make a new relation.

  • Add your tags in the top table, including type=site

  • Select some of the objects you want to add.

  • In the edit-relation window click on the left-facing arrows to add the selection to the relation.

  • Order of entries doesn't matter in your case, and you don't need to add any roles to the objects.

  • Repeating adding objects and tags until done.

(02 Aug, 11:07) mueschel

Hard as it may sound, you have to take a step back from thinking about how it looks on the map, and instead think about what makes sense from a data modelling perspective.

I am not into golf but the way you say it, fairways and holes belong to one course but a fairway can occasionally belong to two courses? In that case, it would make sense to create a relation for each course - perhaps a "site" type relation, certainly not a multipolygon! - with all the holes, fairways and stuff as members. That way, the same fairway can belong to two different courses.

If, on the other hand, a fairway and a hole can only ever belong to one course, then you could also invent a tag - perhaps some form of the ref tag, like course_ref, and apply that to each of the objects.

Neither of these techniques will lead to different rendering results on the standard maps. But a hyothetical "interactive golf map" could, with the help of a data service like Overpass, do things like "display all features that are part of the XYZ course" - something that your initial idea of "drawing a way around it" would not allow.

permanent link

answered 29 Jul, 10:07

Frederik%20Ramm's gravatar image

Frederik Ramm ♦
74.2k866691149
accept rate: 24%

Hi Frederik,

Thanks you for your thoughtful helpful reply.

> "Hard as it may sound, you have to take a step back from thinking about how it looks on the map, and instead think about what makes sense from a data modelling perspective."

Yes that's very important otherwise we won't be able to write complex useful queries in overpass. I am not a software coder or developer. The holes in my conceptual knowledge are frustrating, particularly regards how to create meaningful relationships, as you describe, and the finer detail and not so finer detail of constructing what I feel should be fairly easy and intuitive overpass queries.

(29 Jul, 10:48) ABZ_OSM

> "I am not into golf but the way you say it, fairways and holes belong to one course but a fairway can occasionally belong to two courses?"

I'm not into golf either. I see these big green spaces locally and they are empty so I thought to fill some of them up. Golf is not an exclusive game here in Scotland, Europe, as it often is elsewhere. So we have many courses. I've filled up three and improved some others.

Yes and sometimes, within the same course, fairways and a green can belong to two different holes, for example, holes 9 and 13 on the Silverburn course share the same green.

(29 Jul, 10:49) ABZ_OSM

> "In that case, it would make sense to create a relation for each course - perhaps a "site" type relation, certainly not a multipolygon!

Such relationships and multipolygon's is an area of OSM that I still do not understand, which is frustrating.
I am guessing that the hardest situation for many people is when they see a multi polygon with holes in it when editing ambient features of interest. Scary! In JOSM I just avoid these when I see them.
When I see pop-up's like multi polygon "inner" and "outer" I just abandon and avoid changes.

One thing I am sure of, though, is that this these are not difficult to understand.

I just can't find a resource that makes it simple to see through. I haven't really persued this udnerstanding though.

The same for creating meaningful relationships between objects as you suggest as a possible solution.

If you have any useful learning resource pointers these would be appreciated. I've just discovered this forum so will have a look on here too.

(29 Jul, 10:49) ABZ_OSM

> "If, on the other hand, a fairway and a hole can only ever belong to one course, then you could also invent a tag - perhaps some form of the ref tag, like course_ref, and apply that to each of the objects".

I was thinking that might be the way to go, where there is no mixed identity of each hole/ fairway / green etc.

(29 Jul, 10:49) ABZ_OSM

My original post has been edited, possibly since you first read it, to contain reference to overpass. The reason I initially considered this problem of naming each of the 18 hole courses with in this one golf club, was becasue of overpass and, as things are just now, inability to make a distinction between the holes belonging to each course.

(29 Jul, 10:56) ABZ_OSM

Relations can be easy to break if you're not careful, but are relatively simple in concept. 'Structurally' they are lists of other elements in a specific order with the option to label each element with a role to identify what that element does. They are the only type of element with a compulsory tag: the type=* tag is used to indicate what the roles in a particular relation mean and to hint at what other tags to expect. As new relation types can start as variations of old ones this can sometimes be confusing, but makes them very flexible.

Multipolygons are described quite well on the wiki and are generally quite well supported by software, but can sometimes require a bit of housekeeping to keep their loops intact and free of self intersections.

(29 Jul, 17:08) InsertUser

thanks @InsertUser. Your comments are useful to me.
After a thorough look at https://wiki.openstreetmap.org/wiki/Relation:multipolygon I find nothing there that is not straightforward and simple.
Everything on that page is simple & makes perfect sense.

I also downloaded the JOSM plugin https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Relation_Toolbox and had a good look through it while following this explanatory video https://www.youtube.com/watch?v=jfKfjxK7dYk

which was helpful. I'm still not sure when it is appropriate to create relationships though.

I think I need a more in depth resource that explains the necessity for these with many examples.

I will keep looking at the various resources though, I'm sure I will get it after a while.

(30 Jul, 11:11) ABZ_OSM
showing 5 of 7 show 2 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×11

question asked: 29 Jul, 09:56

question was seen: 202 times

last updated: 02 Aug, 11:47

powered by OSQA