This post continues the STAC 1.0.0 announcement and updates on the community and spec, with an in-depth dive into one part of what we call the ‘STAC Ecosystem’. This is the ever-growing set of libraries, clients, and servers that rely on the STAC specification to build towards our goal of interoperability. The advanced state of this ecosystem is one of the things I’m most proud of with STAC, as one of the earliest goals was to have as much real-world validation as possible. And the coolest thing is that it feels like the momentum is just starting to really hit an inflection point, with more and more tools supporting STAC.

So this post will give an overview of the current state of STAC-related software, and where our ‘STAC 1.0.0 Initiative’ sponsor money has enabled us to accelerate. And in the next post, I’ll share what else we’re planning to fund, towards a vision of ‘STAC Ecosystem 1.0.0’. That’s the point when there are complete tools, with all the appropriate tutorials and documentation, so that anyone can easily create or consume STAC. Our goal is that most people will be able to do so without having to ever read the specification. It will just be the foundation that enables a network of interoperable data.

While we just announced STAC 1.0.0, the initial post did not contain any of the typical information we normally include in a STAC release announcement. So in this post, we’ll dive into the details of what changed in the specification, including extensions, as well as some of the community highlights. And this will just be one of several posts diving deeper into STAC topics, including the wider ecosystem of tools.

Spec Changes — As always, the most definitive list of what has changed between versions of STAC is the CHANGELOG, but it’s always good to draw attention to the highlights. So I’ll summarize here the major changes, building on the changes summarized in the 1.0.0-rc.1 release, including rc.2, rc.3, and rc.4.

The SpatioTemporal Asset Catalog (STAC) community is pleased to announce the release of version 1.0.0. It’s safe to say we’re all quite proud of the release, as it’s been a large community effort for over three years. For those who haven’t heard of STAC, it provides a common language to describe a range of geospatial information, so it can more easily be indexed and discovered. You can learn more at the stacspec.org website, which we aim to update in the coming months to be an even better learning resource.
A Stable Foundation –I’m not going to go into all the details of the release for this post, but I’m aiming to do a series of blog posts to highlight all that has happened, share what’s next, and highlight all the amazing tools in the community. The one thing I do want to share is what a 1.0.0 release means for us. Our goal for the core STAC specification is to provide a foundational layer for the emerging ‘Cloud Native Geospatial’ ecosystem. We believe that the future of geospatial information is fully online and in the cloud, and STAC aims to help connect diverse data into a network of information about our planet (and even other planets).

Last week the STAC community came together and sprinted to release version 1.0.0-rc.1, the most critical step on our path to STAC spec 1.0.0. This is a ‘release candidate’, meaning we believe the specification is completely set for 1.0.0, but we want to put it in the hands of implementors and gather feedback and reviews before the final release.

So if you have implemented STAC in the past please take the time to upgrade your software or catalog to the latest specification (see the change summary below for what’s changed). Our aim is to sprint for the next few weeks to upgrade as many implementations as possible to validate for the final release. The nature of a ‘release candidate’ means that if any implementations find problems in the specification we will make another ‘release candidate’ and give it a couple of weeks for feedback, doing so until we iron out all the issues. The newly formed Project Steering Committee has aligned on targeting the end of April for 1.0.0 final release, aiming to do any needed additional release candidates before then.

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.

As SpatioTemporal Asset Catalog (STAC) specification matures one of the more frequent questions we get asked is the relationship between STAC and the Open Geospatial Consortium (OGC). I wanted to write this post to help clarify, at both a technical and an organizational level.

The tl;dr version is:

‘STAC API implements and extends the OGC API — Features standard, and our shared goal is for STAC API to become a full OGC standard’

The longer version has a lot more detail, but if you’re interested then read on!

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.