Leisure Facilities Data Providers: Site Inventories, Live Sessions and Demand Economics · Head-to-head
OpenStreetMap Key:leisure vs OpenActive Open Opportunity Data
Which leisure facilities data providers: site inventories, live sessions and demand economics data fits your job: OpenStreetMap Key:leisure, or OpenActive Open Opportunity Data. API, files, or your warehouse. Daily, weekly, or hourly.
OpenStreetMap Key:leisure
OpenActive Open Opportunity Data
Where the fields line up
1 shared field — join on these.
| Field | OpenStreetMap Key:leisure | OpenActive Open Opportunity Data |
|---|---|---|
name | Name of the leisure feature as mapped - the human-readable label volunteers gave the place. | Human-readable name of the session, series or facility as the operator titles it. |
Coverage, side by side
| OpenStreetMap Key:leisure | OpenActive Open Opportunity Data | |
|---|---|---|
| Geographic | Global wherever mapped; density varies sharply by country and urbanisation | United Kingdom through participating operators; strongest in England |
| Temporal | Current state of each feature; no historical archive | Rolling forward window of upcoming sessions plus recurring series |
What each contains
Pick by fit, not by loyalty.
| OpenStreetMap Key:leisure | OpenActive Open Opportunity Data | |
|---|---|---|
| Publisher | OpenStreetMap mapping community, documented on its wiki | OpenActive, developed through its W3C Community Group with Sport England support |
| Subject lens | Tagging vocabulary and mapped features: what leisure places exist, classified and located | Operator-published opportunity records: what activities happen, when, at what price |
| Field dictionary | 8 documented fields, verified during research | 15 documented fields, verified during research |
| Geographic coverage | Global wherever mapped; density varies sharply by country and urbanisation | United Kingdom through participating operators; strongest in England |
| Temporal coverage | Current state of each feature; no historical archive | Rolling forward window of upcoming sessions plus recurring series |
| Detail level | One record per feature: node point or way/relation boundary polygon | One record per session or slot, linked to venue, organiser and offer |
| Identity signal | `name` plus `brand` for chains; companion `sport=*` for activity | `@id` canonical identifier; organiser organisation and venue Place objects |
| Demand signal | None - no capacity, booking or attendance fields exist | `maximumAttendeeCapacity` against `remainingAttendeeCapacity`, plus `offers` pricing |
| Best for | Global place inventories, chain estates, catchment and adjacency work | UK programme intelligence: timetables, price points, spare capacity, inclusion |
What each does better
OpenStreetMap Key:leisure
Footprint first: a global inventory of places. Millions of leisure-tagged elements span every mapped country, each carrying one of roughly 100 values - park and nature_reserve for green space; sports_centre, pitch, track, stadium, golf_course, fitness_centre for sport; swimming_pool, water_park, marina for water; playground, trampoline_park, dog_park, escape_game for family recreation; sauna, resort, bandstand, picnic_table for the rest. Geometry runs deeper than pins: nodes mark points while ways and multipolygon relations carry whole-site boundaries, so catchment and adjacency questions stay answerable. Chain identity comes attached - one live row reads fitness_centre, name Virgin Active, brand Virgin Active, sport fitness, with phone and website recorded; a sibling node reads Fitness First with wheelchair set to no.
OpenActive Open Opportunity Data
Time and money, on the record. Every opportunity carries startDate and ISO 8601 duration, with eventStatus separating scheduled from rescheduled, postponed and cancelled - the field that keeps ghost classes out of downstream apps. One live row: Hot Yoga, a scheduled session series in the Bodypump family, a 20:15 start, PT1H duration, 15 of 15 places remaining, ages 16 and up, no gender restriction, at Middlesbrough Sports Village with postcode and coordinates, organised by Better. A second row flags visual-impairment support and a Beginner level. Accept its frame: United Kingdom, strongest in England; a rolling forward window of upcoming sessions rather than an archive; and, by specification, no commercially sensitive information, customer data or attendance figures.
Where they're equivalent
More than their vocabularies suggest. Both put a stable human-readable name on every record. Both fix position - node coordinates on one side, venue GeoCoordinates on the other - closely enough to align at building resolution. Both encode accessibility, however differently: a mapped wheelchair yes/no versus structured support concepts. Both describe the present rather than the past: the map holds the current state of each feature, the activity corpus holds upcoming sessions, and neither ships a historical archive. And both are definitions you can build against rather than reverse-engineer - one a wiki-documented tagging scheme applied consistently worldwide, the other a published specification with model definitions and worked examples.
The verdict
Verdict: sample both, pick by fit - they are instruments pointed at different layers of the same buildings.
Take OpenStreetMap Key:leisure if your question names places. Footprint counts by town or category, gym-chain locations off brand, park and playground provision, site boundaries for catchment work - anything answered by counting and locating what exists.
Accept its frame: UK only, forward-looking only, sessions rather than sites.
Sample both, pick by fit. See OpenStreetMap Key:leisure · See OpenActive Open Opportunity Data
Or take both in one feed
Yes - stacked, they form a facility-to-programme panel neither completes alone. Map the estate first: which gyms, pools and sports halls exist, under whose brand, with what boundaries. Three alignments decide whether the merge holds. First, identity: the map side keys on name and brand strings while the activity side keys on venue Place objects and organiser organisations, so alignment runs through normalized venue and operator names. Second, geometry: node coordinates meet venue GeoCoordinates at building resolution, but polygon boundaries have no counterpart on the programme side. Third, shape: flat tag-and-value rows against typed records need a small normalization layer before they share a table - see opportunity data for the semantics being aligned. We handle all three in the merge, delivered daily, weekly, or hourly - your call. Or take both in one feed.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Is OpenStreetMap Key:leisure better than OpenActive Open Opportunity Data?
Better at different jobs. Key:leisure owns the where: millions of features worldwide across roughly 100 values, with site polygons, brand identities and contact details per place. Scored 10 against 9 on Datadory's rubric, but the point gap measures polish, not purpose - most leisure projects need both layers.
Do the two datasets cover the same ground?
Three concepts deep: name, coordinates and an accessibility signal exist on both sides. Fields like `sport`, `brand`, `phone` and `website` have no OpenActive counterpart, while `startDate`, `offers`, capacity and restriction fields have no map counterpart.
Which dataset covers more of the world?
The map, by an order of magnitude. Key:leisure features exist anywhere volunteers map, from megacities to villages, with density varying by country and urbanisation. OpenActive is intentionally national: participating UK operators, strongest in England. Outside the UK the comparison is not close - the realistic stack is the map vocabulary plus whatever local sources Datadory catalogs alongside it.
Which should a new leisure-data project sample first?
Sample by question, not by dataset size. If the deliverable counts, locates or territories places - market sizing, competitor estates, park access - start with Key:leisure. If it tracks programmes, pricing or demand - timetables, occupancy, inclusion - start with OpenActive. Datadory cuts both samples to your geography and operators first, so the fit test runs on your own rows.
Can Datadory deliver both datasets together?
Yes - alone or merged onto one venue list, delivered daily, weekly, or hourly, your call. Each arrives normalized to its documented dictionary (eight fields on the map side, fifteen on the activity side) with sample rows first, so you confirm the fit before committing. The merged cut aligns venues by name and coordinates across both.