SpatioTemporal Asset Catalog (STAC) 1.0.0-rc.1 Released


The Path to STAC 1.0.0

It’s almost time! The SpatioTemporal Asset Catalog (STAC) specification has been maturing for over 3 years, and already has a rich ecosystem of tools with hundreds of millions of assets cataloged. The core community has agreed that it’s time to put a pin on it and lock in a super stable specification that can be a core building block for years to come. We believe STAC will be the foundation of something truly special: A transformation to a ‘Cloud Native Geospatial’ world that will open up unimaginable innovation.

Our goal has been to build simple, flexible building blocks to expose geospatial data in order to enable others to build incredible value on top of that. This can only happen if there’s a stable base to rely upon. In the next couple of months, we hope to release 1.0.0. Our goal goes beyond just releasing the specification: We aim to make sure there is a ‘complete’ core ecosystem of tools to make it easy for people to create, use, and get value from STAC. See below for our plan, details on our sprint, and also ways that organizations can directly support STAC.


SpatioTemporal Asset Catalogs and the Open Geospatial Consortium


The first STAC API 1.0 release: 1.0.0-beta.1

I’m pleased to share that we’ve just released STAC API 1.0.0-beta.1. This is our first release of the API since we split the specification, with STAC now living in its own repository. You can see the latest specification in the stac-api-spec repository, and we link to browsable API representations of the major portions below.

What started out as a pretty modest release ended up snowballing into a major amount of work, but I think we’re all pretty proud of the end state. Our main goal was to have a version of the API that was released standalone, independent of the STAC Core releases. In previous versions, it was just assumed that a version number applied to both the STAC content and the API. So we wanted to enable services could be more explicit about which version of each they supported — one could upgrade the service to 1.0.0-beta.1 API, but have it still serve STAC 0.9.0 Items.


The Tools to Make Spatial Data More Open

How the STAC tool ecosystem is growing towards supporting truly open spatial data.

The STAC specification is transforming the way data providers and consumers are thinking about how to work with open spatial data. It provides a clear, common language for spatial data that is flexible and developed by an open community. But what is a language without the tools that speak it? The open-source STAC tooling ecosystem is a critical part of making spatial data open and accessible for use. In this post, I’ll talk about why access to that tooling provides is so important, and describe two instances of collaboration I experienced in the recent STAC and Cloud Native Geospatial sprints that, to me, exemplifies the growth of STAC tooling.

Machine Learning, Standards

Cloud Native Geospatial Outreach Day Recap

Chris Holmes, Technology Fellow at Radiant Earth gives a recap of the Cloud Native Geospatial Outreach Day and shares some of his favorite parts.

It’s been just over three weeks since the Cloud Native Geospatial Outreach Day. Everyone I’ve talked to felt it was an incredible event, and I definitely concur. Thankfully we managed to record almost all of it, so if you missed it you can still catch the content on youtube!

We opened with a welcome from Bruno Sánchez-Andrade Nuño and me, representing the Microsoft and Planet, the convening sponsors. Then Hamed, the new Executive Director of Radiant Earth, introduced the Data Labeling Contest (which was a great success).


Welcoming New Collaborators to the Cloud Native Geospatial Ecosystem

I wanted to share some background and more details about the Cloud Native Geospatial Outreach Day and Sprint (1 week away! September 8th — signup here), which has grown out of the SpatioTemporal Asset Catalog (STAC) community sprints. One of our goals for STAC has been to make it a truly collaborative community, and one that is welcoming as possible. We believe that the best standards are forged from diverse use cases and perspectives coming together and collaborating. We started with a gathering of 25 people from 14 organizations and have always sought to bring more people into the fold.


Join the ‘Cloud Native Geospatial’ Outreach Day and Sprint

On September 8th we will be continuing SpatioTemporal Asset Catalog (STAC) Sprint #6, but we decided to expand its scope to include more of the ‘Cloud Native Geospatial’ ecosystem. The core idea of Cloud Native Geospatial is articulated in this ‘blog series’, with the first post positing the question: ‘what would the geospatial world look like if we built everything from the ground up on the cloud?’. The second post introduced the Cloud Optimized GeoTIFF (COG), and it has since emerged as a default format for anyone doing geospatial on the cloud.


Join us for STAC Sprint #6 — our first fully remote event

With the SpatioTemporal Asset Catalog (STAC) spec recently reaching 1.0.0-beta, we figured it’s time for one final sprint before we push out 1.0.0 final. The goal with STAC has always been to ensure that the specification meets real-world needs, by always iterating its improvements in conjunction with actual implementations. One early goal was to reach 1 billion records in STAC before we go to 1.0.0, but we achieved that much earlier than expected. But the various catalogs have not necessarily upgraded to the latest STAC version right when it comes out. So our main goal for the sprint is going to be to upgrade all the STAC software and catalogs to the latest 1.0.0 beta specification and ideally add several new catalogs and data types. The goal will be to ensure that STAC is flexible enough to handle anything, so when we reach 1.0.0 the core will not need to change.

News, Standards

STAC 1.0-beta.1 Released!

The SpatioTemporal Asset Catalog community is incredibly proud to announce the release of STAC 1.0! If you want to get technical it’s 1.0-beta.1, which means that everything is not yet completely locked in. And it’s just the core specs, as we’ve split off the STAC API into its own repository, and its 1.0-beta.1 release will follow. But this is a huge milestone, as it symbolizes that the community has worked through every known issue and desired improvement. It is the beginning of the final stabilization steps, to ensure STAC will be a stable core that people can build on for years and even decades to come.

The reason we are calling it a ‘beta’ release is so that the specification is not so set that we can’t take additional feedback as we push to get it much more widely adopted. The goal between beta.1 and 1.0.0 is to update every piece of software that has implemented STAC, as well as upgrade all the existing STAC Catalogs to the latest, so we are sure our changes work for everyone.