// the find
geopython/pygeoapi
pygeoapi is a Python server implementation of the OGC API suite of standards. The project emerged as part of the next generation OGC API efforts in 2018 and provides the capability for organizations to deploy a RESTful OGC API endpoint using OpenAPI, GeoJSON, and HTML. pygeoapi is open source and released under an MIT license.
pygeoapi is a Python server that implements the OGC API family of standards (Features, Tiles, Maps, Coverages, Processes, EDR, Records, STAC) behind a single config file. You point it at a data source — PostGIS, GeoJSON, xarray, Elasticsearch, ESRI, and a dozen others — and it exposes standards-compliant REST endpoints with OpenAPI docs and an HTML UI. The target audience is government agencies and GIS teams that need OGC compliance without writing a server from scratch.
The provider plugin system is genuinely well-designed: swapping from GeoJSON to PostGIS to xarray is a config change, not a code change, and the provider interface is clean enough that writing a custom one is straightforward. The breadth of supported backends (Oracle, MongoDB, Elasticsearch, Azure Blob, SensorThings, ERDDAP, Socrata) is legitimately impressive for a ~600-star project. Django, Flask, and Starlette are all supported as WSGI/ASGI backends, so you're not locked into one framework. The OGC compliance test suite (CITE) is included as a test target, which is the right way to verify standards conformance.
The requirements story is a mess: there are eight separate requirements-*.txt files and no unified optional-extras in pyproject.toml, so figuring out what you actually need to install for your use case requires reading multiple files and guessing. Async support is inconsistent — Starlette is listed but most providers are synchronous, so you get async routing with blocking I/O underneath. The process manager implementations (TinyDB, MongoDB, PostgreSQL) each have different persistence semantics and the docs don't clearly explain when you'd choose which. Documentation is thorough in breadth but thin on operational concerns: there's almost nothing on running this at scale, caching strategies, or what breaks first under load.