Course detection (when there are more than 18 hole ref’s) needs a lot of work, it’s the next ‘big’ item on my list to do.
The A/B/C/D is auto-generated, you can edit the name which will drop it in. Have taken note to read through that discussion, might back away from this feature for the time being and just show all holes in one list for the time being.
Tee box neutrality - this is actually locked behind the scorecard import - will be available once we move a little further forward with the alpha, the scorecard import basically takes a screenshot of the scorecard, interrogates it, then creates tee boxes as needed (with heavy emphasis on colour orientation rather than male/female - although a lot of course still have the latter)
The editor will be tagged in uploads to openstreetmap once available (will be enabling the uploads to the dev OSM later this week just before I go on holiday … to play golf!)
Distance in M/Y - also largely linked to the scorecard import, it picks what it thinks is correct based on what it can read, but it can be overridden (I’ve taken a note to auto-calculate the opposite metric)
Interesting … the search is populated from a per-country overpass query which stores into a postgres database looking for leisure=golf_course .. there is some deduplication logic in there so it may have been caught by that - which is a flaw in the way my search population works. I’ll loop back around and consider what needs to change to improve that - in this example, both should definitely have been find-able.
Ah … yes … definitely - I’ve now enabled a secondary nominatim search - up til this point I’ve only allowed searching against the DB I mentioned in the previous point. I agree this is too narrow, hopefully you can find stuff easier now!
@anyone else reading - improvements since my last post (this is version 0.5):
Fix: Multipolygon course boundaries now merge all outer rings correctly, and inner rings are correctly handled (courses like Golf-und-Land-Club Berlin-Wannsee and Buffalo Run Golf Course, as examples)
New: Non-golf specific features (i.e. anything else returned in the overpass query) are now rendered on the map to avoid confusion. Currently uneditable but considering making them editable … keen not to become an id clone though so .. more pondering required.
Update: Nearby club labels now show within a 50-mile radius once a course is selected
New: You can now ‘open in’ from the profile menu (top right corner) - allowing you to launch the course in iD, Mapbox and Apple Maps.
Update: Bunker tagging switched to using surface=sand instead of natural=sand
New: Course boundaries are now editable up to a 50M variance - allowing for corrections of boundary inaccuracies inline rather than needing to switch to another editor
Fix: Issues with unsaved changes warning appearing after successful save now resolved
Update: Improvements to hover-state (feature selection when you move your mouse over)
New: Creation of multipolygon relations via merging now supported (Shift+Click two features, C to merge or press button in the UI)
New: Knife tool - create holes in the center of existing polygons, useful for ponds/lakes/features in middle of fairways that are not directly connected to fairways etc.
New: Version added to user profile dropdown (we are at version 0.5)
New: Search bar now supports Nominatim so looking for cities/places will bring you to the map, and the available courses in the area will present themselves.
New: Coordinates in the top left hand corner of the UI when a course is selected can now be launched to openstreetmap.org
New: Number of Golf features per course now shown when you zoom out from currently selected course (or if you use the new city/region search)
Update: Improvements to the ‘Needs Mapping’ button now driven from number of golf features per course.
We need to be carefull to not create “lollipops” as stated on the Tag:leisure=golf_course. Golf_Course_Lollipop_Example.png (444×455). I struggled alot before I realized that everything just can be multipolygons with inner and outer relations if features are inside of the fairway for example, see the wiki on the golf page. So the knife tool may not be needed.
EDIT: Also I think Tag:landuse=forest instead of natural=wood is better because it is managed - it is implied becuase it is in the bounds of the golf course. See the wiki.
The knife tool is creating a multipolygon, it creates the outer and inner ring as per the bottom correct image. It’s just doing it in a slightly more intuitive way for a beginner user.
FairwayMapper, Fairway feature, with knife tool applied to create center space:
You save your drafts in FairwayMapper, then Publish to OSM Dev - you’ll get a popup with your changeset id linked so you can inspect the detail.
New: ChangeSets you’ve created from FairwayMapper are now available under your profile name
Update: Nearby course suggestions when zoomed out now show golf feature counts with a green/amber/grey colour scheme to help identify courses requiring love
New: Planet wide course selection - straight from the map, no searching required, when you zoom to a low enough level, you get course names and feature counts.
Update: Report Issue button has moved into the profile menu
New: Course URL’s are now shareable - when you open a course, you’ll get a perma-ish-linked course URL slug
Update: Courses without boundarys - the popup that lets you know will now suggest alternative courses nearby where you can get involved
New: Compass added to bottom left corner of the map, now you know which way to Santa Claus
Update: Prompt/warning for Save Drafts can now be hidden after first view
Update: created_by tag in changesets now marked as FairwayMapper.com (changed from FM)
Note: Whilst uploads to OSM Dev are live, the overpass server in the background still points to live data - so reloading the course you won’t then see your changes in FairwayMapper somewhat confusingly. This is a known issue.
Great, I have now used the route=golf relation to represent a course in the database. See Relation: Björketorpsbanan (20630890) | OpenStreetMap. With some proper documentaiton on this on this wiki I see that as the best way forward for multiple courses on a facility.
I also noticed that FairwayMapper now flags my course as not having a boundary when I changed the Tag:leisure=golf_course from a multipolygon relation (which was unecesary) into a polygon - I suspect that the data need to be refreshed in the backend to fetch this? It is now a Way instead of a Relation. EDIT 2: It is now working, so I just needed it some time to refresh. All great!
Great catch @HuggeK … it wasn’t actually working until I ran a process in the background … which isn’t ideal for users so I’ve built that update process into the app itself now.
You should find if you carry out a similar change going forward, within about 60 seconds (as much time as my overpass mirror needs to update) it should auto-fix itself.
Found another case: I was looking around and found a golf course which was split into two separate closed ways with a road inbetween them. I edited it in iD and changed it into a proper multipolygon.
EDIT: @habi It seems that people are using the tag Tag:leisure=golf_course - OpenStreetMap Wiki for individual courses instead of tagging the whole club with it, the word facility is used on the key Key:leisure - OpenStreetMap Wiki and the definition of the tag is “A golf course is the grounds where the game of golf is played.” - not only a course. So a multipolygon with this club and some solution like Tag:route=golf - OpenStreetMap Wiki could work better. EDIT 2: I will document this case on the wiki page becuase it seems like a common occurance with a road in the middle of the course, for people not hovering over the no relation button in the pane on the wiki that says it is allowed on type=multipolygon relations.
Great! Happy golfing! I was just noticing that multipolygons is not imported - I just fear a situation where some tree´s are tagged as a multipolygon, (for example Way: 1020902305 | OpenStreetMap) and people start drawing trees over already existing elements using FairwayMappey which would be bad.
)
