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.
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.
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.
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.
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.
On November 5–7 around 40 people gathered in Arlington, VA, with another 20 or so participating online, for a joint sprint on the SpatioTemporal Asset Catalog (STAC) and OGC API — Features (OAFeat) specifications. It was our 5th STAC sprint, and the second one we’ve done with OAFeat (formerly WFS 3). I’m pleased to report it was a big success, and to me, it felt like the most productive one we’ve had yet. It was awesome to see everyone working away, on many diverse parts of the ecosystem. In this post, I’m going to attempt to do a brief overview of all that happened.
The SpatioTemporal Catalog (STAC) is an open standard for exchanging catalogs of raster and vector data. The goal of the standard is to increase “ the interoperability of searching for satellite imagery.” The potential applications of the analysis of satellite imagery are far-reaching. Yet, few are engaging with the multitude of data available.
A major impediment is the difficulty of searching and working with the data-the variety of formats and descriptions can flummox even the most experienced of users.
The past couple of years has seen some major steps forward on geospatial interoperability. The trend in OGC towards open collaboration, JSON + REST focus, and OpenAPI specs that started with WFS 3 is sweeping through most all the core specifications. They recently held a successful hackathon, which resulted in agreement on the core ‘building blocks’ that form the ‘OGC API,’ with WFS 3 evolving to become the ‘OGC API — Features’ specification. As the core pieces settle, there is still lots of interesting work happening with the spec, in extensions that enable implementors to match the functionality of previous WFS versions, like Filters, advanced Queries, reprojection, transactions and more.
Last month I had the opportunity to present the architecture behind tiles.rdnt.io: Customer Showcase: Exploiting Multi-Region Data Locality with Lambda@Edge — AWS Online Tech Talks.tiles.rdnt.io is interesting for a few reasons: 1) it dynamically renders map tiles for imagery sources anywhere on the internet, 2) it’s entirely serverless — the tiler itself is implemented as a Python Lambda function, and 3) it’s replicated worldwide to reduce latency when rendering and network egress costs for imagery providers.