STAC 0.8.0 Release

Chris Holmes
Oct 16, 2019 · 7 min read

The SpatioTemporal Asset Catalog (STAC) Community is pleased to announce the latest stable release! The big story with the release is our move to maturity and stability. Though there were lots of changes (over 300 commits by 12+ people), they were mostly concentrated in extensions and the API. In the core constructs of the specification, there were remarkably few, which speaks to the fact that the core is stabilizing.

STAC Spec commit Activity

We will likely aim for a first 1.0 ‘beta’ version of the specification in the next few months, to get final feedback from a wide variety of implementors before locking it in. Our goal is to have over a billion publicly searchable records in SpatioTemporal Asset Catalogs before we finalize on 1.0.0, to be truly implementation-driven.

Core Changes

The one major addition is the new summaries option in the Catalog fields. The use case is to provide clients with more insight into the range of values that may appear in certain fields in the collection. This can be useful for computational operations, as well as enabling programmatic creation of useful GUIs. There was a substantial discussion on the issue, as it potentially overlaps with the ‘common fields’ in the collectionproperties as well as interacting with a full JSON schema definition. But we decided it is a very useful option to give providers, as it is far easier to implement than a full JSON schema definition and has lots of utility.

The other big thing that we wanted in place for this release was specifying the Asset Definition. This is starting as an extension, but it may quickly evolve into a core, as it fulfills a core need to provide details about the assets that may be contained in an Item. This serves two purposes — enabling humans to browse the assets available by looking at a collection level and enabling machines to determine what assets are available in the Items without having to inspect each one or make assumptions.

API Improvements

As the core has stabilized the API has been receiving a good bit of attention. This is all driven by real-world implementations, as new STAC compliant API’s come online, like Astraea’s Earth OnDemand and the NASA CMR implementation, and as existing implementations like Staccato and sat-API evolve to handle more use cases. The biggest set of changes has been aligning with the OGC API — Features specification, which just got to version 1.0. This is the new name for Web Feature Service 3.0, which STAC has aimed to align with from the beginning. There has been a great dialog between the two communities, and valid 0.8.0 STAC API’s should be valid against the core OGC API — Features 1.0.0. STAC needs more than just the core, and we are pleased to be sprinting with the OGC community directly in our next sprint.

The sprint will likely result in additional extensions that both STAC and OGC API — Features will make use of, indeed I’m excited by some capabilities that are on the horizon of standardization as they spread from one server to many. Transactions are at the top of the list, but things like aggregations and subscriptions get really interesting.

The API specification also just tightened up quite a bit for 0.8.0, as more implementors looking at it meant a number of little improvements and clarifications. These include things like reserving parameters to prevent overlap with extensions, updating bbox definition to optionally handle the third dimension, and changing the time API parameter to datetime. All the little changes point to the big benefit of focusing on software before specifying everything so that the final specification is unambiguous and clear.


The next focus of the STAC community is building an ecosystem of content extensions that are as well implemented and thought through as the core. We hope to get have solid extensions for all the most used types of geospatial information. The most exciting new extension to land was the Label extension, which started focused on training data, but now can be used by a number of different machine learning workflows. The key is that it can help the results of models interoperate, not just the inputs to the models. There are already a number of implementations of the specification, and projects like RasterFoundry and Annotate from Azavea are fully embracing it as the core of their workflows.

The other new extension is the Single File Catalog, which is a cool construct that lets you save all the Items and Collections of interest in a single file. This can be quite useful for output from STAC API’s, to save results from a search as a small portable catalog. The sat-search tool uses the Single File Catalog to save and load search results from any STAC API.

Landsat and STAC

Though independent of the release, I wanted to call attention to some recent updates from USGS. This is a really exciting piece of news, as this is the first government data provider to fully embrace STAC. It’s a huge testament to the work of the STAC community to build a rich ecosystem of tooling and education on top of a simple and useful specification, as that core makes it easy for all organizations to adopt. I had honestly thought it would be much longer before governments embraced it directly, and USGS should be applauded for embracing cloud-native geospatial and helping make their data more accessible to everyone.

The Path to 1.0

The STAC community has been discussing what is needed to finalize on a version 1.0. The core idea has been to keep the scope to a small core and triage all the major concerns, and then release a 1.0 ‘beta’ release to gather a final round of feedback. During the beta period, we will do more extensive outreach, trying to get as many data providers to try it out and give feedback, so we are sure that the model is flexible enough to handle most any data. We want 1.0 to be very stable, so it will be the last chance to change the core. Once there is a sufficient number of implementations (catalogs and software, ideally with lots of extensions), we will go to Release Candidate and 1.0 final.

This path is still our goal, so the key question is what we need to get to 1.0 beta. There is still substantial movement around the STAC API, indeed it’s going to be the major focus of our next sprint, held in collaboration with the OGC API community. But there is a growing consensus that it may make sense to separate out the core STAC constructs (Item, Catalog, and Collection) from the API. This will give the API a bit more time to mature after we hopefully get a final alignment with OGC API — Features and its coming extensions. And we’ll be able to put out the core STAC spec for 1.0 feedback sooner.

There is also interest in creating a set of ‘core extensions’, that aren’t just in an open community space, but are actually anointed as a part of the spec, but not something everyone needs to use. This would include a number of constructs that are used across the various domain extensions, like epsg codes, GSD, constellation, and the like. These potentially will drop their ‘prefix’, and be listed together in a single document.

I also want us to take a final look at the complexity of the specification, and determine if everything we’ve added to the core really is essential, or if some should move to extensions. A big selling point of STAC has been that it is simple to grok and implement, and we want to be sure we retain that, even as we add options that make it much more powerful. It will be much harder to take anything out of the core once we go 1.0, but it’s always easy to include more extensions. But we also want a way to indicate that some options and extensions are more important, and promote them to users. The ideal is we have lots of good reference data sets that make use of more than the core and encapsulate the best practices we want to spread. This is why creating lots of great compliant catalogs is the major goal after we go to 1.0-beta.

These final thoughts are just my opinion — we’ll see how the final discussion plays out, as the strength of STAC is our community bringing together multiple points of view and working out solutions that work for all. But I’m feeling really great about the community pushing forward to execute on the full potential of the specification and ecosystem of collaboration on sharing geospatial information.

Radiant Earth Insights

Helping the global development community navigate the Earth observation marketplace and geospatial technology innovations.

Chris Holmes

Written by

Product Architect @ Planet, Board Member @ Open Geospatial Consortium, Technical Fellow @ Radiant.Earth

Radiant Earth Insights

Helping the global development community navigate the Earth observation marketplace and geospatial technology innovations.

More From Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade