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.