I wish to see mapping of Disc Golf Courses fully supported in OSM and related editors.
I propose to do this through ensuring that features are rendered.
I further propose that the wiki documentation be expanded, improved and clarified to enable mapping.
I propose that identifying the presence or lack of support in related tools (editors) will not only reveal best practices and bring the community into harmony, but will further enable users and mappers alike.
Thatās a conversation that youāll have to have with each renderer. The relevant one for OSM Carto (one of the 6 maps that you see on the osm.org page) is 3766, which it looks like youāve already found.
Project support for tags can be seen in taginfo; it looks like iD and Vespucci already have some.
Thanks, thatās exactly what Iām trying to do: define what a disc golf course is (agreement on the tagging of data) so the implementation by various projects can follow and be consistent. E.g. Vespucci supports tagging a āteeā, but allows it to be an area when it should only ever be a node.
Given that disc golf course layouts can change every week (due to having multiple basket locations on the course) does it make sense to try and do mapping at that level?
In the courses I play, this is typically referred to as āAāsā and āBāsā - so someone will say that baskets for holes 6, 7 and 8 have been put in their B positions. The way I see the tagging work is that you map all the holes (ways) with each way having origin (disc_golf=tee) and end nodes (disc_golf=basket). Then create one relation to group all the holes with baskets in the āA positionsā (name=A positions) and the other relations with all the holes having baskets in the āB positionsā (name=B positions). I tried to convey this in the proposal in the Tag Schema (giving the example of āfront 9ā and āback 9ā).
Thereās a local course by me that only has 9 baskets, but 18 tee pads - hence the example of āfront 9ā and āback 9ā.
With regard to the tagging, given that basically no-one has commented, I doubt that people are going to object - youāve tried to accommodate existing data consumers, and added more information which fits well with āany tags you likeā.
Iām personally not convinced that rendering, iconography, clutter, etc. has any place on an OSM tag page (unless itās giving an example of how an existing common tag is rendered on an existing general purpose map). There are a few reasons for this:
It is extremely unlikely that OSM Carto (described as āOSMās standard map styleā) will ever render this tag**.
Showing a āsuggested renderingā on this page will confuse and disappoint people expecting to see these features on general purpose maps
iconography requirements and rules vary hugely with rendering technology (of which there are many)
dealing with clutter also various hugely by technology, and also many modern (and not so modern) maps support relatively large zoom levels, at which clutter is less of an issue.
finally (and most important) the cartography used for disc golf features will have to fit in with the cartography of the map thatās choosing to show those features
** Thereās a lot of history here, and it wouldnāt make sense to rake over all of that here, but just as one example OSM Cartoās lack of support for highway=busway (27k worldwide) is just embarrassing. Itās on that basis that I doubt that OSM Carto would ever support disc golf (but Iād be delighted to be proved wrong)
I second that. The rendering section is not really appropriate beyond guidance any how rendering could be implemented. In that spirit it would be helpful to clarify whether the proposal is deprecating mapping leisure=golf_disc_golf_course and how to handle existing cases where it is mapped as an area. What fraction of courses currently are mapped in line with the proposal of ānode at information signā?
Indeed. Insisting that the symbol is the recognizable shape of a ātargetā may not fly. In particular, OSM Carto has no legend, and so the sport symbols have to be recognisable by the general viewer, and need to be consistent with other sport symbols, which show a person playing a sport.
(offtopic from tagging, but just to give a rendering example)
Here are the sport icons in the map legend for a map style of mine. The equestrian one is probably the most complicated, but itās just a (very stylised) 16x16 or so horse and rider. It has to be stylised because when a map user first sees it on a map itās necessarily very small, and any more detail simply wouldnāt be visible.
Each sport icon has to look different to the other 20-odd for other sports. I havenāt added disc golf yet. It was about the 24th most popular leisure key in the area that I was interested in when I added the others, and I was a bit stuck how to show it in a way that is both characteristic but also āobviously some sort of sports pitch like the othersā.
At a higher zoom level it might be possible to show more detail (a golf example is ball_washer). Once youāre on a course/pitch for a certain sport, the idea is that features for that sport donāt have to be characteristic of the sport, since youāre already in the environment of the sport.
That said, Iām not quite sure what you want to achieve, as things are going you are just going to p*** off all the people on whose goodwill you depend upon. A more positive approach would be for example to produce basic SVG icons for the relevant objects (CC0 pls).
Thatās a little unfair - the very first line in the first post in this thread says āI wish to see mapping of Disc Golf Courses fully supported in OSM and related editorsā.
Itās entirely reasonable that someone would see that the OSM wiki has a proposal process, and would therefore that is the way forward to get renderers to show them and editors to support the addition of them using agreed tags. You and I know of the general issues with āgetting XYZ feature rendered on a general purpose mapā and the specific story around OSM Carto, but if youāre relatively new to the project thereās no way that you could know that.
The detail about āshould a disc golf tee be a node or an areaā is very much detail that we can worry about later - people donāt rigidly follow the wiki and if someone thinks a disc golf tee should be an area Iām sure theyāll map it as one. Peopleās viewās differ, but with a renderer hat on Iām more than happy to āwhere itās possible to work it out, try and show what the person adding something to OSM meantā even if the wiki says that they got something wrong.
Itās not just about rendering. For example the proposal adds a new relation type that potentially needs special casing in editors, or just consider splitting and merging the ways with role hole and what needs to be done with the start/end nodes.
I include this content in the proposal because I am attempting to summarize the historical, current and desired status of disc golf course mapping for discussion. Iām new to OSM, so Iām finding more subtlety, intricacy and layers of the onion the more I dig in
Mapping leisure=disc_golf_courseas an area is deprecated under this proposal.
āNode at information signā is new guidance under this proposal. So itās completely unknown how many existing courses might have been tagged in this way by coincidence - even if it is common sense and becomes adopted best practice.
The problem with using the tag on a relation is that you can not navigate to a relation. This is one consideration that guides me to suggest tagging a node, and using relation (type=disc_golf_course) for course layouts
Taginfo shows that the tag is used mostly (about 2/3) on nodes, but honestly any currently tagged disc golf courses should be reviewed and improved/corrected when/if this proposal is agreed upon.
Until 2023, the wiki page said to mark a node; but now says the tag should be used on a relation. Relations account for only 6% of the current usage.
People map things pretty much as they see them, and I fully expect that they will continue to map disc golf courses as (multi)polygons regardless of whatever someone wrote in the wiki. The wiki is supposed to reflect how people map things, not āwhat the person that wrote that page would like to seeā.
If thereās a really good reason why something should only ever be mapped as a node not as an area, then youāll need to make that case on the wiki page. An example of something similar is on the place=seapage - it says āā¦ because most seas do not have verifiable boundaries with the open ocean or other seasā.
Thatās fine. It is mapping as a relation that would make life tricky for renderers. The proposal is just refining what exactly mapping leisure=disc_gof_course as a node means.
It would be more of a problem if the majority of leisure=disc_golf_course were mapped as a relation of ways.
It wouldnāt be an issue supporting courses mapped as ways. OSM Carto, for example, uses the PostGIS function ST_PointOnSurface to find a sensible position for a marker node.
Thanks for the example of seas being mapped as nodes.
The rationale for disc golf courses being mapped as nodes is exactly the same: they lack clear verifiable boudaries. In fact, the tag page for leisure=disc_golf_course already starts off āhow to tagā with
Disc golf courses often donāt have a well-defined area.
That rationale could be made even more explicit in any text revision to the wiki page.
The verifiable truth on the ground for disc golf courses is that the only ones with verifiable boundaries on a hole-by-hole basis are professional courses being marked and used during tournament play. For all other intents and purposes, a disc golf hole is some indeterminate line between tee pad and basket. The larger course boundary is just as indeterminate.
If in the past people mapped disc golf courses as polygons, itās likely drawing (pardon the pun) from the pre-existing examples of golf courses and the absence of clear āhow toā for disc golf.
Iām hoping the proposal adequately addresses the collection of elements that would normally and routinely be mapped for a disc golf course. And, that the suggestions correspond to the current practice of renderers and GIS software capabilities.
To be clear:
There is a ācourseā - the place where you go to play the game. That single node is the destination and carries multiple tags about the course:
leisure=disc_golf_course
sport=disc_golf
name=Weare-Merriman Park Disc Golf Course
disc_golf:course=18_hole
disc_golf:par=54
disc_golf:length=5527 ft
At a course, you will find a collection of holes with tees and baskets that makeup a layout. There is normally more than a single layout per course; perhaps 2-4 layouts per course is the norm. Each layout can be tagged/grouped with a relation.
In the current draft, it is suggested that the relation type be ādisc_golf_courseā but I can see how that might be easily confused with the leisure=disc_golf_course tag. Would it be better if the relation type were named ādisc_golf_layoutā like in the snippet below?
; a relation to associate holes 01-09 plus miscellaneous features and ways with the course node
relation01
type=disc_golf_layout
name=front 9
; a separate relation to associate holes 10-18 with the course node into a 'layout'
relation02
type=disc_golf_layout
name=back 9
As proposed, these relations do not need to be rendered. But if they were, it would serve to distinguish a group of holes (unclosed ways) from a similar set. This screenshot shows how the UDisc app renders a disc golf course with a weird Layout. The course has only 9 baskets, but 18 tee pads which are then grouped into two layouts: āFront 9ā and āBack 9ā.
