Course name and state
Prairie Landing Golf Club — West Chicago, IL (Robert Trent Jones Jr., opened 1994).
What's wrong
The course appears twice, and the duplicate is placed in the wrong state:
| id |
name |
lat, lon |
state / city |
080bb5fb-0650-4b62-b49c-577547431174 |
Prairie Landing |
41.8867361, -88.2514947 |
IL / West Chicago ✅ |
0121adf3-c9e8-4aea-986d-43815e9c9c29 |
Prairie Landing Golf Club |
42.0634548170213, -86.6013129617021 |
MI / (city blank in CSV) ❌ |
Both carry the same phone (630.208.7600) and the same website (prairielanding.com), so
they are one course.
The stored coordinate on 0121adf3 does not match its own cited source. That row's
osm_id is 20151148, which is OSM relation 20151148 — correctly tagged
leisure=golf_course, name=Prairie Landing Golf Club, website=prairielanding.com. I
pulled that relation's full geometry: all 81 member nodes fall inside
lat 41.882820 .. 41.896340
lon -88.261950 .. -88.243369 centroid 41.8889779, -88.2540118
— entirely in West Chicago, IL. The dataset's stored point for that record is 137.8 km
away, out near St. Joseph, Michigan, and matches no part of the relation. So OSM is right
and the derived coordinate is wrong; the API then reverse-geocodes that bad point and
presents the record as a Michigan course.
Why it bites users: searching the club's actual name returns only the wrong record.
GET /v1/courses/search?q=Prairie%20Landing%20Golf%20Club
-> 1 hit: Prairie Landing Golf Club, St. Joseph, MI
GET /v1/courses/search?q=Prairie%20Landing
-> 2 hits: Prairie Landing (West Chicago, IL), then the MI copy
A player who types the name on the sign is shown one result, in the wrong state, and
reasonably concludes their course isn't in the database.
What the correct value should be
Merge the two into one record at the Illinois location:
- latitude / longitude:
41.8889779, -88.2540118 (centroid of OSM relation 20151148) —
or keep 080bb5fb's existing 41.8867361, -88.2514947; both are on the property
- state:
IL · city: West Chicago · postal_code: 60185
- address:
2325 Longest Dr, West Chicago, IL 60185, USA
- name:
Prairie Landing Golf Club (the club's full name, per the course website and
the OSM relation — currently only the misplaced record carries it)
The two rows hold complementary metadata, so a merge gains information rather than
losing it:
- only
0121adf3 has architect = Robert Trent Jones, Jr. and total_yardage = 6950
- only
080bb5fb has year_built = 1994, the street address and the postal code
Source
One smaller thing, same course
Both rows say holes = 14 and each is missing four per-hole par/hcp values —
0121adf3 lacks holes 3, 4, 12, 15 and 080bb5fb lacks holes 2, 3, 6, 8. Their union
covers everything except hole 3. (The live API returns a complete 18-hole card with pars
summing to 72 and a clean 1–18 handicap index for both ids, so this may only affect the
published CSV/GeoJSON snapshot rather than the served data — flagging it in case the two
are meant to agree.)
Found while building a golf betting tracker on the API. Thanks for keeping this open — the
data has been good to work against.
Course name and state
Prairie Landing Golf Club — West Chicago, IL (Robert Trent Jones Jr., opened 1994).
What's wrong
The course appears twice, and the duplicate is placed in the wrong state:
080bb5fb-0650-4b62-b49c-5775474311740121adf3-c9e8-4aea-986d-43815e9c9c29Both carry the same phone (
630.208.7600) and the same website (prairielanding.com), sothey are one course.
The stored coordinate on
0121adf3does not match its own cited source. That row'sosm_idis20151148, which is OSM relation 20151148 — correctly taggedleisure=golf_course,name=Prairie Landing Golf Club,website=prairielanding.com. Ipulled that relation's full geometry: all 81 member nodes fall inside
— entirely in West Chicago, IL. The dataset's stored point for that record is 137.8 km
away, out near St. Joseph, Michigan, and matches no part of the relation. So OSM is right
and the derived coordinate is wrong; the API then reverse-geocodes that bad point and
presents the record as a Michigan course.
Why it bites users: searching the club's actual name returns only the wrong record.
A player who types the name on the sign is shown one result, in the wrong state, and
reasonably concludes their course isn't in the database.
What the correct value should be
Merge the two into one record at the Illinois location:
41.8889779, -88.2540118(centroid of OSM relation 20151148) —or keep
080bb5fb's existing41.8867361, -88.2514947; both are on the propertyIL· city:West Chicago· postal_code:601852325 Longest Dr, West Chicago, IL 60185, USAPrairie Landing Golf Club(the club's full name, per the course website andthe OSM relation — currently only the misplaced record carries it)
The two rows hold complementary metadata, so a merge gains information rather than
losing it:
0121adf3hasarchitect = Robert Trent Jones, Jr.andtotal_yardage = 6950080bb5fbhasyear_built = 1994, the street address and the postal codeSource
osm_idalready cited by the record itself
080bb5fbrecordOne smaller thing, same course
Both rows say
holes = 14and each is missing four per-holepar/hcpvalues —0121adf3lacks holes 3, 4, 12, 15 and080bb5fblacks holes 2, 3, 6, 8. Their unioncovers everything except hole 3. (The live API returns a complete 18-hole card with pars
summing to 72 and a clean 1–18 handicap index for both ids, so this may only affect the
published CSV/GeoJSON snapshot rather than the served data — flagging it in case the two
are meant to agree.)
Found while building a golf betting tracker on the API. Thanks for keeping this open — the
data has been good to work against.