On Mapping Golf Courses

Posted by James Tait on 20 June 2015 in English (English)

I’m not a golfer. When I grew up, golf was a rich person’s game. Average Joes like me couldn’t afford to play golf. Things have changed. My boys are golfers. I’m just their geek dad, a Free Software nerd and OpenStreetMap obsessive who takes them places. Golf can still be a rich person’s game, but it doesn’t have to be. The rich kids just have more equipment.

One such piece of equipment is GPS assistance. A little custom-made gadget that knows about golf courses and the features and layout of each hole and assists with things like choosing your club and your line based on where you are and where you need to get to. This, to someone like me, sounds like a challenge. We have this data (or where we don’t, we can create it). So, ahead of the first round of the 2015 Derbyshire Futures Tour, I set about mapping the course.

Actually mapping the course, the holes and their features from the Bing imagery was a breeze. But when I got to thinking about how the software would work, I came up short. My idea was something like this:

  1. The golf club is represented by an area (leisure=golf_course; name=Name of Club)
  2. Each course at a club is represented by a relation (type=golf_course; name=Name of Club, Name of Course).
  3. The relation groups all the ways tagged golf=hole, and the ref tag on each way represents the hole number.
  4. The tee boxes (golf=tee) and greens (golf=green) are also tagged using ref for the hole number.
  5. Bunkers are tagged (golf=bunker, natural=sand); water hazards (golf=water_hazard; natural=water); lateral water hazards (golf=lateral_water_hazard; natural=water); fairways (golf=fairway); and woods (natural=wood) and individual trees (natural=tree).
  6. Search for a course. This would search Nominatim or similar for relations of type=golf_course that closely match what the user searched for. This could even be automated as a first step, so the user just has to select the course from a list.
  7. Download the data for the course, render it, show distance to the hole, recommended club, etc. Record strokes and distances. The sky’s the limit here.

But there’s a problem: tee boxes, fairways and greens are associated with a hole on a course, which is part of a club - but that’s not represented in the data. We only have a link from the course relation to its holes - there’s nothing linking a tee box to a hole or a green to a hole, and there’s nothing linking bunkers and trees to the course. Now for downloading the data, this is not necessarily a problem, as we can figure out the bounding box. But when it comes to “show me an overview of the first hole” then it becomes:

  1. Select the first item of role=hole in the relation.
  2. Look at its ref tag.
  3. Select all ways in our bounding box with the same ref tag (and probably golf=tee, etc.)
  4. Figure out the hole’s bounding box.
  5. Select anything else in that bounding box.
  6. Render.

If instead we had a hierarchy of relations, we could do:

  1. Select the first item of role=hole in the relation.
  2. Select the child relations for role=tee, role=fairway, role=green, etc.
  3. Figure out the hole’s bounding box.
  4. Select anything else in that bounding box.
  5. Render.

It’s only one step less, but by iterating over the child relations, all the related ways are selected explicitly, rather than having to iterate over every way we’ve downloaded and discard most of them. I think this would make for more coherent data and more performant applications.

Location: Shirland and Higham CP, North East Derbyshire, Derbyshire, East Midlands, England, United Kingdom

Comment from Warin61 on 21 June 2015 at 00:11

There is the proposal Has a number of tags. Proposed for over a year now.

On that you can see a way is proposed .. would that not be the ideal ‘course’ for the gold ball? The user could enter their maximum reliable range, hole number and the app figure out where that range circle (centered on the present location) crossed the way and show that to the user.

Comment from James Tait on 21 June 2015 at 22:21

Well, there are actually two proposals - “hole as a way” and “hole as an area”. I had thought, for some reason, that “hole as a way” had been superseded by “hole as an area”, but re-reading the discussion I see that there’s just some clarification required as to how the way should be plotted. I’m still left wondering, though, what happens when the hole moves every few days.

My initial problem, though, is there’s no easy way to recursively drill down the relations to get all the nodes and ways required to render any given course - I still end up relying on bounding boxes, which could be problematic if, say, a road crosses a course - I don’t want to pull in the entire road!

Comment from Warin61 on 23 June 2015 at 05:58

There may be some with airport runways across or even down them too.

Some may be mapped with ways, others with boundaries, some with both…

Yes, the hole will be moved from time to time.. and the map may not have the latest location. Work with what you have?

Comment from Govanus on 25 June 2015 at 19:32

the main way is to suck in all the data for series of bounding boxes that cover the site in question then use sort process (often linked to renderstyling files like Mapcss and ealy xml stylesheets. these rejct everything you don’t tell them to map in the render (mapcss can in advanceced use not only drill down but do both computation on varibles stored in tags and plot multiple line and area features {see the road lane stylesheet add-on option of a multilane highway to see it rendered with dashed line between each lane on a route widenend to meet the number of lanes}. MapCSS can in most systems if study yhte advance guides work with nested relations withen boolean equations of different tags).

So it shouldn’t be too hard with some systems to avoid roads and airports if that is a bit unhelpful complex and reliant on others work you could try a data appoch and treat the xml datafile in a spreadsheet or text editior to sort thourgh using find and replace. If you you have too much to do I not the odd course now and then and need something quicker for baulk work then try reasuching the likes of gawk/awk, grep, perl and other text pocessing systems oftern originating on unix machines but are now availble from some place for a lot of the other popular platforms like MS-Windows, Risc-OS and different types of the Mac-OS’s (pre & post X) etc.

Ihope this might be useful.

Comment from James Tait on 25 June 2015 at 22:08

Absolutely! And thinking about it further made me realise that if a road (or a runway!) passes through the course, that’s an important feature, so it should appear on the map. I’d still prefer not to have to pull in huge ways if possible, but I suppose some amount of clipping is inevitable.

As regards the hole moving, I’ve steered away from mapping the pin so far. I think they move often enough that mapping them is nonsensical - “if it’s nailed down, map it” certainly doesn’t apply.

And yes, of course we’re going to have some variation in the way people have mapped courses; that’s just the nature of the beast. My point was aimed more at the proposal for mapping, and improving that before it becomes a widely-adopted standard. The courses I visit, I can improve myself, having walked the holes and photographed features. I’m more than happy to do that work, if the result is better quality data.

Login to leave a comment