U.S. National Park Service API

Original Article ↗ Hacker News Discussion ↗

A public API from the U.S. National Park Service is being praised for opening up park data, while also drawing scrutiny over how it’s implemented and funded. Commenters debate whether a REST API on AWS with API keys is an appropriate way to serve largely static datasets, or if cheaper, more open approaches like CSV dumps or public BigQuery tables would better align with the mission of providing taxpayer-funded data. The thread also touches on broader issues of government tech capacity, underfunding of digital services, and the trade-offs between ease of access, abuse prevention, and long‑term maintenance.

Overall Reception & Existing Uses

  • Many commenters are enthusiastic that the National Park Service (NPS) exposes a public API and has a GitHub presence, despite some repos being outdated.
  • One person mirrored portions of the API into a public BigQuery dataset for easier SQL/Jupyter analysis and published docs/code.
  • People mention interesting secondary data sources (e.g., IRMA stats) and custom visualizations built on NPS visitation data.

Hosting, Cost, and Architecture Debate

  • Large subthread argues REST on AWS/EC2 is an expensive, overbuilt way to serve mostly static CSV/JSON.
  • Alternatives proposed:
    • BigQuery public datasets with “querier pays” model.
    • Static CSV or SQLite dumps on cheap storage (e.g., S3) plus mirrors.
  • Counterarguments:
    • REST APIs are mainstream, battle-tested, and easy to integrate.
    • Actual traffic may be low enough that costs are negligible relative to NPS’s overall budget.
    • Some data (alerts, events) is dynamic; underlying system reportedly uses Apache Solr.
  • Disagreement over whether savings are substantial; critics are pushed to provide concrete cost estimates.

Public Access, API Keys, and Rate Limiting

  • Debate over API keys for public data:
    • Critics see them as unnecessary friction and a tracking mechanism ill-suited to open government data.
    • Supporters say keys are the simplest tool for rate limiting, abuse control, and usage accounting when the agency pays per request.
  • Alternatives suggested: IP-based limits with optional registration for higher quotas; others argue IP-based controls alone are weak, especially under IPv6 or via popular apps.
  • Some worry about pushing users toward vendor-tied platforms (e.g., BigQuery) vs. tax-funded, vendor-neutral HTTP access.

Funding, Maintenance, and Digital Government Context

  • The API team is described as understaffed and effectively in maintenance mode; roadmap hasn’t been updated since 2017.
  • Discussion branches into broader federal digital initiatives (USDS, 18F), their dependence on political will, and compensation vs. private sector pay.

Data Coverage, Gaps, and Related APIs

  • Missing or desired features: bookings API (handled via recreation.gov), real-time campground availability, live telemetry (e.g., wildlife tracking), and visitor stats via the API.
  • Noted inaccuracies: park count discrepancies and combined listings (e.g., Sequoia/Kings Canyon).
  • Brief side questions about BLM land APIs and undocumented NPS endpoints discovered via site inspection.