The U.S. Recreation Information Database (RIDB) API has been substantially upgraded, providing programmatic access to an authoritative information source on the U.S. government’s parklands, historic sites and recreational attractions.
While the RIDB aims to be a single point of information access spanning data managed by multiple federal agencies, including the Department of the Interior, the National Park Service and the Smithsonian Institution, the underlying data set and API are both still in development, so some data may not yet be current or may be missing attributes.
The idea is that through wide distribution, an ecosystem can grow up around the API, both contributing more accurate information and demonstrating demand for the Resource.
RIDB API Overview
Data endpoints available through the RIDB include:
- Organizations: The government agencies that contributed data to the RIDB.
- Recreation areas: All recreation areas managed by the U.S. government. There are also endpoints for media, links, addresses, activities and events held at each of the recreation areas (also for facilities and campsites).
- Facilities: Facilities at each of the recreation areas.
- Campsites: Data on campsites attached to each of the facilities.
- Permit entrances: Permit entrance information associated with each of the facilities.
An entity relationship diagram is included in the API docs to visually represent how all the data items are connected.
API calls are free, and while there is no license, Documentation clearly stipulates that the data can be used and published in any manner without informing any government agency, although users are encouraged to acknowledge the RIDB API as the source of the data.
Those who are looking for a reliable data source for their commercial products or for citizen advocacy and use cases may still be disappointed by any commitment to a service-level-type agreement in making the data available. The API is covered by public laws governing federal data quality that note that while the data set is meant to be a general reference and will be updated whenever possible, it does not make any commitments to the data’s reliability, accuracy or timeliness.
Challenges in Creating an API Built on Aggregated Government Data
The RIDB API is fairly unusual among U.S. government APIs, as it relies on data sets owned and shared by more than 30 agencies. It is also an essential aggregated data set for many nonprofits and third-sector organizations working in partnership with government agencies to maintain and manage national parklands.
Dan Parker, one of the architects at software company Nsite responsible for managing the updated version of the API, explains the collaborative approach across government sectors:
We met with RIDB stakeholders during the requirements process to better understand their data input and export needs. This included both data consumers and data providers. We also opened our development server to the public for beta testing and feedback. Based on this feedback, we were able to make several improvements to the API before its initial release.
Because the RIDB API had been released as a SOAP API in version 1, the revamped version did not have to revisit issues like the data entity nomenclature being used to define agencies across government. There are maintained lists of all government agencies with APIs and developer portals, and Project Open Data also manages a list of all government agencies and their progress toward opening their data. But what is less clear is whether all data sets and APIs across government define and describe their own government agencies in the data sets in the same way. So it is uncertain whether other aggregated data set API projects similar to the RIDB would have problems matching data entities around something as seemingly simple as how government agencies refer to themselves.