Hi @Greg_Rundlett (and thread) — I run Planet DiscGolf, an OSM-based map showing all ~16,000 disc golf courses worldwide. We render from a PMTiles extract of OSM data with Overpass API fallback, and we’ve been following the disc golf mapping discussion since the 2023 thread.
Your proposal for type=disc_golf_layout in post #20 matches what we’ve independently arrived at and implemented. I want to share our experience because we’ve built the full pipeline — tagging, data extraction, and rendering — and have a real-world test case live in OSM.
What we implemented
We mapped DiscGolfPark Běchovice (Prague, Czech Republic) as the first multi-layout course using type=disc_golf_layout relations. Three layouts, all sharing the same course node:
| Layout |
Relation |
Holes |
Notes |
| Main 18 - long tees (Gold) |
14137393 |
18 |
Converted from legacy type=disc_golf_course |
| Main 18 - short tees |
20272962 |
18 |
Shares 10 hole ways with Gold |
| Short 9 |
20272963 |
9 |
Reuses ways from both 18-hole layouts |
You can see it rendering live at next.planetdg.com — navigate to Běchovice and click the course. The layout selector shows all 3 configurations with hole counts.
Key design decisions we made (and why)
1. Hole numbering by relation member position, not ref on ways
This is the core insight. The same hole way can be hole 5 in the Gold layout and hole 3 in the Short 9. Putting ref=5 on the way is wrong for the Short 9. We derive hole numbers by filtering the relation’s member list to role=hole entries and numbering sequentially — first role=hole member is hole 1, second is hole 2, etc. Non-hole members (the course node, any future extensions) are skipped and don’t affect numbering.
This follows the same pattern as type=route relations for bus/hiking routes, where member order defines the sequence. @PerlDreamer’s concern about weekly layout changes is addressed by this — you’d just have separate layout relations per basket position configuration, and only one is “current.”
2. Physical → Paths → Layouts separation
We think of it as three layers:
- Physical features (tees, baskets) — things you can see and verify on the ground
- Playing paths (hole ways, tee→basket) — carry
par, dist, and tee color. No ref.
- Layouts (relations) — order the paths into a playable sequence with a name and difficulty
This keeps each element simple. A tee node doesn’t know which layout it’s in. A hole way doesn’t know its number. The relation provides the context.
3. type=disc_golf_layout not type=disc_golf_course
Exactly your point in post #20 — we originally used type=disc_golf_course for the legacy Běchovice relation (913917-style), then switched to type=disc_golf_layout when adding multi-layout support. The separate type avoids confusion with leisure=disc_golf_course on the node and lets data consumers immediately know the relation’s structure without checking secondary tags.
@SimonPoole raised valid concerns about editor support for new relation types. In practice, the iD editor handled creating type=disc_golf_layout relations without issues — it treats them as generic relations with ordered members. JOSM similarly has no problems. The editing workflow is: create the hole ways, create a relation, add members in order, tag it. No special editor support needed.
4. Course node as the anchor
Every layout relation has the course node as a member with role=course. This means discovering layouts for a course is a single Overpass query:
node["leisure"="disc_golf_course"]["name"~"Běchovice"];
rel(bn)["type"="disc_golf_layout"];
out body;
No grouping relation needed. The shared course node provides the linkage.
On the node vs. area question
@phodgkin and @SomeoneElse raised the area mapping question. From a data consumer perspective: we render ~16,000 courses and strongly prefer nodes. Our PMTiles pipeline, sidebar, route planner, and course detection all work on point coordinates. We can handle ways (we centroid them), but areas add complexity without adding useful information for discovery and navigation. The course node at the sign or first tee is the natural “here is the course” marker.
That said, we wouldn’t advocate deprecating area mappings. Some courses have well-defined boundaries and mappers should map what they see. Our approach: we consume nodes and way-centroids, and if an area exists, we show its centroid in the sidebar. Works fine either way.
On rendering in OSM Carto
@SomeoneElse is right that this is a separate discussion from the tagging proposal. For what it’s worth, we render our own map specifically because disc golf isn’t shown in standard renderers. Our approach: course nodes as POI icons at zoom 6+, hole fairways as colored lines at zoom 14+, tees and baskets as small icons at zoom 15+. Layout coloring is optional — we color fairways by disc_golf:layout value when available, default gray otherwise.
Our tagging writeup
We wrote a detailed tagging specification covering multi-layout scenarios (tee position variation, basket rotation, different hole counts, divergent routing). It covers edge cases, backward compatibility, QA validation rules, and Overpass query examples. If useful for the proposal, I can share it as a wiki page or link it here — didn’t want to dump 800 lines into a forum post.
The annotated OSM changefile for Běchovice is also available if anyone wants to see exactly what elements were created and how the relations are structured.
What we’d like to see standardized
type=disc_golf_layout as the relation type (not type=disc_golf_course)- Hole numbering by member position in the relation
disc_golf:layout for the layout color/identifierdisc_golf:difficulty with values aligned to PDGA tee colors (professional/advanced/intermediate/recreational/beginner)- Course node as mandatory member with
role=course
Happy to help test any tagging changes against real rendering — that’s what Planet DiscGolf is for.