More and more organizations benefit from the STAC specification and publish their geospatial data with STAC metadata. Having the data published in a standardized way in JSON is paving the way to wider adoption of geospatial data so that humans can find and make good use of the data. There is no doubt having JSON files is nice for developers, but it is equally important to spread the data to professionals in other sectors. Those users often need an easily accessible and searchable graphical user interface for the data. That is where STAC Browser comes into play.

As stactools approaches its one-year birthday we (Chris Holmes and Rob Emanuele, your co-authors for this blog post) figured it’s time to give it a proper introduction. It’s grown to be a key part of the SpatioTemporal Asset Catalog (STAC) ecosystem, but somehow there’s never been a blog post announcing it or explaining what it does. So we figured it’s time to share a bit about what it is, how it got started, and where it’s going.

It’s been almost 3 months since my last blog post on SpatioTemporal Asset Catalogs (STAC), which is one of the longest stretches I’ve gone in the past few years. There’s been lots of progress and growing momentum in the community, so it seemed like a good time to pull together all the happenings in one blog post.

STAC Funding Initiatives – The first topic to share is the state of funding for the STAC ecosystem. In the previous post, I shared about our open requests for proposals. I’m pleased to announce that we’ve selected Element84 to make the new STAC website and Jonathan Healy for the STAC validation enhancements. We’ve also decided that Radiant Earth will lead the open RFP’s for the tutorial work, which will take up most of the final funding from the STAC 1.0.0 Funding effort. Once we finish up all the contracts for that initiative I’ll do a final summary blog post.

Following up on our SpatioTemporal Asset Catalog 1.0.0 announcement, this post will finish our mini–series diving into the STAC specification and the ecosystem around it. This one is really about the future, where we see STAC heading in the next six months and beyond. And after this I hope to start an in-depth series of STAC posts that dives deeper into individual projects, highlighting all the great software and data in the STAC ecosystem.
The ‘STAC Ecosystem 1.0’ Vision
One of the core tenents of the STAC Community is that we focus on the process of building an interoperable ecosystem, with the specification serving as a record of the current state of collaboration. With the release of 1.0.0, it is our hope that the core of that collaboration now has an incredibly solid foundation. But there is much, much more to do in order to realize the vision of STAC: we won’t be ‘done’ until every single ‘geospatial asset’ has an associated STAC record.

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).