STAC API Version 1.0.0-beta.2 released!
The SpatioTemporal Asset Catalog (STAC) Community is pleased to announce the release of version 1.0.0-beta.2 of the STAC API specification! A big thanks to Phil Varner for leading this release, and to everyone else who pitched in.
What is STAC API?
As we are welcoming many new people to the STAC community with the core STAC 1.0.0 release it’s probably worth explaining what this ‘API’ release is all about. STAC originally started from a desire to make a common API to help interoperability between satellite data providers, but soon evolved to focusing on the core JSON language to enable more general geospatial interoperability. The STAC repository initially contained both the API specification along with the three ‘core’ specs (Item, Catalog & Collection). But it was clear that the API really depends on the core, and expands it with additional functionality, so after version 0.9.0 we decided to split STAC into two repositories.
The API specification is what enables ‘search’ of a STAC Catalog, and indeed is the functionality most people expect when they interact with one — selecting a geographic area and various criteria of the imagery or other assets that they’d like. So the core STAC Specifications just provide the core JSON objects to describe the data. The cool realization with ‘cloud native geospatial’ is that putting that JSON directly in a cloud storage location actually enables a ton of use cases. And in turn, many STAC API’s can easily ‘ingest’ cloud-backed STAC implementations, providing the search API on top. But the organization sharing the data does not need to be the same one providing the API and index of the data, lowering the barrier to entry to providing data into the ecosystem.
The STAC API extends and aligns with the OGC API — Features standard, so any client library that works with that standard will work with STAC. STAC API represents each collection of data as an OGC API Collection, but then additionally adds an ‘item-search’ endpoint to enable cross-collection search.
What’s in STAC API version 1.0.0-beta.2?
The STAC community made a conscious choice to prioritize the core specifications, to give a stable base for the whole ecosystem. STAC API 1.0.0-beta.1 was released a few months ago, to give a foundation for API’s that could be versioned separately from the main specifications. The release of STAC API 1.0.0-beta.2 aims to ramp up the push for STAC API 1.0.0.
The biggest change in the release is the new ‘Filter’ extension, which is designed to replace STAC’s ‘Query’ extension with a more standardized language for specifying which STAC Items to return based on the specified matching criteria. The Filter extension is based on OGC API — Features Part 3: Filtering and the Common Query Language, aligning STAC more closely with OGC API — Features. STAC’s Query language was custom-designed for STAC, and had a plugin structure to add more advanced queries, but it stayed as a pretty simple, core language for STAC. So the community felt it’d be better to align with a full-fledged standard that would handle more advanced queries and evolve on its own. CQL did not drop in quite as seamlessly as we hoped, as the STAC Query is much easier to implement, but the two communities are in active dialog to sort out the right subset of CQL to include in STAC. The exact path to include CQL in STAC and when the now deprecated Query extension will be fully removed is still up for discussion, but for the next STAC release, we will have a solid plan in place.
The other changes were more minimal, like recommending CORS be enabled and updating the STAC core specs to be 1.0.0. The full changelog is available for those who want to dig in.
What’s next for STAC API?
The main goal of the next STAC API release will be to get a validator in place so that we can ensure that the various implementations of STAC are all following the standard in the same way. This will help us find ambiguities in the specification. With that in place, the goal will be to get to STAC API 1.0.0 as soon as possible, so that we can have a stable specification to be able to submit to as an OGC Community standard. More features like collection-level search and further alignment with OGC API will come after that, and may well involve a STAC API 2.0, as we are following Semantic Versioning, so any breaking change requires a new major version.
