STAC 0.9.0 Release — our final major release before 1.0-beta
I am pleased to announce that the incredible STAC community has just released version 0.9.0! This work on the release began in earnest during the 5th STAC Sprint that took place in early November. Having everyone in person enabled us to discuss all the major issues remaining, and we managed to get to decisions on all of them and got to at least draft pull requests of each. The last couple of months have been spent refining those and getting all the little details right, including two ‘release candidates’ — drafts that the community could give feedback on. You can see the full list of improvements in the changelog, and I’ll detail the highlights below.
The diversity of contributors is quite impressive, it is easily the largest number of people who made a successful pull request that was incorporated in the release. Thanks to Matthias Mohr from OpenEO, Matt Hanson of Element84, Alexandra Kirk and Alireza Jazayeri from Climate, Josh Fix from Planet, Phil Varner of Astraea, James Banting of SparkGeo, Michael Smith and Tim Ruthersby from L3Harris, David Raleigh from Near Space Labs, Rob Emanuele and James Santucci of Azavea, Volker Mische of Protocol Labs, and Fabian Schindler from EOX. And thanks to everyone who has been implementing STAC and giving feedback to the core specification.
Extension Reorganization and Promotion
The most visible change to the specification is an overhaul of a number of the most used extensions. This was done for two major reasons. The first is to better share common fields — for example, we had sar:constellation and sar:platform in the SAR extension, and eo:constellation and eo:platform in the EO extension. These mean the same thing but have different prefixes and thus less interoperability. The second reason is to help highlight the most used fields by putting them in the same folder as the item specification, as a new part of the specification called Common Metadata.
The SAR and EO extensions have slimmed down, using ‘instrument’ in common metadata, and then also sharing the View extension (various angles of sensors and other radiance angles that affect the view of resulting data) and often the Satellite extension. The view extension came about from a great discussion about capture angles in aerial imagery, after the first release candidate. Catching this type of thing is the goal of a release candidate — to be able to address potential issues before we finalize the release.
This has reset the maturity of a number of the extensions to ‘proposal’, but it felt like a good move overall, and we hope to quickly get a number of implementations of each. We also decided at the sprint to get more serious about tracking the actual implementations of the extensions, so we can update their status and clearly communicate to users ones that are more mature.
New Extensions
We’ve also added a few new extensions:
The Asset Definition Extension provides meta-information at the collection level as to what can be found in the assets of items in the collection. Think of it as a rough schema, to enable clients to understand what assets they may get, without having to inspect individual items.
The Projection Extension specifies various options to include projection information. The most common is an epsg code, which was previously in the EO extension, but clearly has much wider applicability. We also added a number of options for people who want to include more projection information in their STAC record or are working with data that does not have defined EPSG codes. These include a WKT2 string, a PROJ4 or even the new PROJJSON object. The extension also adds the ability to include a bounding box or centroid in the native projection of the object, in addition to the WGS-84 definition that GeoJSON requires.
The Version Extension provides a consistent mechanism to version STAC records. The core specification is quite simple, with just two fields: ‘version’ and ‘deprecated’. It then uses RFC 5829 for ‘latest-version’, ‘predecessor-version’ and ‘successor-version’ relation types. The extension does not specify the versioning practices, so it can be used in almost any scheme, but there is a new section on Versioning for Catalogs in the best practices document. Also added for 0.9.0 is a complementary Items and Collections API Version Extension, which provides the REST endpoints to request particular versions, or all versions, along with the link relations between them.
We also cleaned up the extensions folder, with a much nicer readme that clearly shows the maturity and prefix to use in a table. Though most extensions are marked as pretty immature the sprint brought a commitment to track use in the ‘implementation’ section that has been added to each extension and to update the maturity status based on those.
API Improvements
The STAC API spec had the most improvements of the mini-suite of STAC specs. It was the first time we had a real critical mass of people who had built STAC API’s at a sprint, so there were a lot of good exchanges resulting in concrete progress. A lot of thinking went into all the mechanics of our Query, and since we were sprinting with the OGC Features API (OAFeat) community we worked to align with their standard.
Alignment with OAFeat endpoints — Previous versions of STAC had endpoints at /stac and /stac/search, and we moved them to just share the same root / endpoint with Features API. Our hope is that Features API uses the same /search the endpoint we use for cross-collection search, and we’ll work to align with them on it.
Paging Updates — Pagination in STAC API is now using hypermedia links exclusively to align with OAFeat, removing the next parameter from the API. And since OAFeat does not yet support POST for search, STAC 0.9.0 also provided a mechanism that enables paging with POST searches. See the Paging section for more information.
Search API Extension -> Context — The ‘meta’ information returned with a search (number of items matched and returned, plus the limit) has evolved to be called ‘context’. It does not exactly align with OAFeat right now, as they put just numberReturned and numberMatched at the root level of the JSON object. We hope to propose changing those to align with the context object that can hopefully be reused as a common component with other OGC specifications.
Sorting — Another improvement was in the parameters to sort search results, in the API Short Extension. We added a GET version of sort, and aligned the semantics with the ‘sortby’ term that has been commonly used in OGC standards. The new OGC API has not yet specified their sort protocol, but we talked extensively with the core contributors of Features and Records, and hope they can adopt our proposal.
Next steps to 1.0
As discussed in my previous post, STAC has reached a point of maturity where it makes a lot of sense to push for a stable 1.0 that everyone can rely on for years. So the next release will be 1.0-beta, which means that we are pretty sure that what we have is ready to go 1.0, but we want to do one more round of feedback where we have the license to change things. Our goal after the beta release is to get as many organizations to adopt STAC as possible, getting to numerous software tools, lots of datasets and hopefully billions of STAC items. And hopefully from diverse domains as well, pushing our extensions in different directions to ensure that the core is flexible enough to adapt. We’ll be setting some clear, measurable targets for adoption and will go to 1.0.0 final after we reach them.
So we’ll soon be splitting the repository, with stac-spec continuing to hold the item, catalog and collection specifications, and creating a new stac-api repo to hold the API specification. We’ll have to re-orient the specifications and indeed the website as well for this, but it should help provide more clarity. It will hopefully be a major community effort. And we still are welcome new collaborators all the time, stop by our gitter chat and say hi, and start using STAC to catalog all your assets! And a big thanks to everyone who got us this far, we could not have done it without the incredible community of contributors.
