Earlier this month we ran the 4th STAPI sprint in Broomfield, CO, hosted by NV5 Geospatial. This sprint welcomed new participants while also bringing back key contributors such as Umbra and Orbital Sidekick. Since we started this effort in 2022, the API has evolved from a loosely defined idea of satellite “tasking” to the discovery and ordering of geospatial data from the future.

Evolution

The main goal of STAPI is to make it easier for end users to order future satellite imagery by developing an API specification and driving adoption of it among satellite data providers. Lowering the barrier to entry to purchase commercial imagery would help develop a more active marketplace. 

Through these collaborative sprints we have discovered that ordering future satellite imagery is really ordering a product derived from satellite data collections. Most users are not interested in the raw pixels from the satellite. The data always undergoes some amount of processing, into a Level-1 or higher level product, and running a model on the data to generate some other product is no different.

In this simple example, a user interacts with a STAPI endpoint to order data to be collected from a satellite. That data is downlinked and added to a data catalog, the user is notified through the STAPI, and they can access the data through the data catalog (a STAC API).

A slight addition to the diagram shows a more complete picture. As data is added to the data catalog it triggers processing workflows, sometimes chained together, to create one or more derived products. One of these products is ultimately what is delivered to the user.

This means that STAPI can support companies that don’t own their own satellites but require processed satellite data for tasks like object recognition, monitoring, or generating analytical reports. STAPI now enables these companies to order such data, ideally with another STAPI, and seamlessly integrate it into their workflows. Because this behaves like an OGC Processes API, we are able to use the OGC APIs as building blocks. STAPI may end up as a compliant OGC Processes API with additional conformance classes. This is similar to how STAC is an OGC Features API with schema extensions to define the responses more precisely.

Products

Users who are interested in answering specific questions or gaining insights from satellite data have 3 main requirements: a specific product, a region of interest (ROI), and a time of interest (TOI). The product could be an image, a few images covering the ROI, a time series of images over the TOI, polygons indicating change over a TOI, or a set of points indicating specific objects.

Products could represent data that already exists. A user may want recent data of a ROI, and if it doesn’t exist they will want it to be collected. In this sprint, Umbra demonstrated a STAPI implementation that supports TOI’s in the past or the future, so the user can evaluate existing as well as future data collection opportunities.

This clearly places a lot of emphasis on the definition of products, and we run the risk of a proliferation of vendor specific products. Further sprints will explore defining standard Product templates that can be extended for vendor specific differences, perhaps by extending the concept of STAC profiles.

Open-Source Ecosystem

Part of the STAPI effort is to create tooling to enable the creation and use of STAPI implementations. During this sprint we made some improvements to the existing libraries and started on some new ones.

• Validation Library: stapi-validator validates endpoints and API responses using the open API documentation.
• STAPI Client Library: stapi-client is designed to make interactions with STAPI endpoints simpler and more efficient, much like the pystac-client does for STAC APIs. This library will enable users to query opportunities and place orders via a CLI or Python interface.
• STAPI API Refactor: The FastAPI tooling was refactored to account for endpoint changes, specifically around product-specific opportunities and orders.
• TLE Backend: Updates to the TLE backend were made to account for the STAPI refactor. The TLE backend allows for opportunities to be calculated for any satellite with a TLE file containing orbital data.

End-to-End demonstrations

At the end of the second day we gathered for updates and demonstrations.  Open Cosmos and Umbra both demonstrated a STAPI endpoint that proxied their existing tasking APIs. Using the /opportunities endpoint we could explore options for future data from each of their constellations.

The biggest surprise of the sprint came from the Umbra team. Andy and Jon took this work to the next level by placing an order for a SAR image of Broomfield for the next day! Their order demonstrated the entire workflow: users are able to request a list of opportunities and subsequently select and place their order. This demonstration was an exciting validation of a STAPI workflow and a significant milestone for the project.

What is Next?

The near-time focus is to resolve open issues and completing pull requests in the STAPI spec repository. We will also expand the example products to illustrate and examine major product archetypes to cover a wide range of sensors (e.g., optical, radar, lidar, RF, hyperspectral) as well as derived products (e.g., mosaics, maps) and analytic products (e.g. object detection). In addition, we want to stand up a publicly available demo using Landsat, which has predictable revisit cycles that can be exposed as future Opportunities.

The STAPI sprints have been positively received by participants, and the face-to-face collaboration has proven invaluable. We want to continue the momentum by having two sprints next year – held in Europe in the spring, and in the US in the fall. By the end of 2025 we’d like to have a stable specification, but it will depend on how mature the real-world implementations are at that time.

This sprint was a solid step forward for the project, delivering some key decisions in the scope and goal of STAPI as well as advancing the open-source tooling we will use to leverage its functionality. With future sprints planned and a clear roadmap ahead, we hope to further drive interest and attract engaged stakeholders. If you are interested in sponsoring or hosting the next STAPI sprint please reach out.