Element 84 Logo
MENU

The Sensor Tasking API (STAPI) project continues to evolve, and Sprint #5 in Lisbon marked a significant step forward in its development. Convened by Element 84, sponsored by AWS, and hosted by Development Seed, this sprint brought together a diverse group of companies including Orbital Sidekick (OSK), BlackSky, LiveEO, EUSI, Open-Cosmos, and Planet. Everyone present made substantial contributions to refining the STAPI specification and its associated open-source software, moving us closer to our goal: the transformation of satellite data ordering.

Photo of sprint attendees standing in a large circle around small text being projected on the wall.

What is STAPI?

STAPI (Sensor Tasking API) is designed to streamline the process of ordering Earth Observation data, focusing on making it easier for users to request future data for a specific location. STAPI has evolved since its inception, shifting from an initial focus on tasking to a more generalized data ordering API. Unlike direct tasking systems, STAPI provides a way for users to understand available options and place requests with vendors without needing to know about the underlying satellite tasking details.

Relationship to STAC and OGC APIs

The STAPI spec is closely aligned with the SpatioTemporal Asset Catalog (STAC), which structures metadata for Earth observation data and allows users to search and discover existing data. STAPI takes this a step further by allowing users to make data orders for data to be collected or generated from the future based on user requirements. The intent is that orders fulfilled through STAPI will ultimately be delivered via STAC Items, thus STAPI aligns with the overall structure and field naming conventions of STAC.

Like STAC, STAPI is also built using OGC API building blocks, most notably OGC API – Commons. Using OGC conformance classes for advertising capabilities, STAPI APIs can be leveraged by existing tooling and standards and provides a familiar interface to users.

Progress in Sprint #5

During Sprint #5 in Lisbon, the STAPI specification reached a significant milestone with the release of version 0.1. This release incorporates a range of updates that enhance the specification’s stability and usability. While the spec is still very nascent and will change in the future, versioned releases will provide structure and methods to migrate and keep pace with the current spec.

Three tasking sprinters working on laptops sitting at a table.

Open-Source Ecosystem

A key highlight of Sprint #5 was the role of Pystapi as a reference implementation. Serving as a practical example of how the STAPI specification can be applied, Pystapi offers the OpenAPI documentation for the entire STAPI spec. It acts as a critical tool for developers, providing clear guidance on how to interact with the API and integrate it into systems. This implementation includes several important components:

  • stapi-pydantic: Pydantic models used to define the STAPI data structures, ensuring consistent data validation and serving as the foundation for generating the OpenAPI documentation.
  • stapi-fastapi: A backend-agnostic FastAPI application that enables developers to build their own STAPI endpoints, making it easier to deploy STAPI-compatible services.
  • pystapi-client: A Python API and CLI tool that allows users to interact with STAPI servers directly from their applications.
  • pystapi-validator: A work-in-progress tool designed to validate STAPI implementations and ensure conformance to the specification.

In addition to Pystapi, the Sprint saw continued development of other important open-source tools, including the STAPI UI. This user interface simplifies the data ordering process, making STAPI more accessible to a wider audience and providing an intuitive way for users to place satellite data orders and visualize opportunities.

stapi-passover-pred, another tool developed during Sprint #5, helps predict the feasibility of data collection opportunities. It uses a Two-Line Element (TLE) file fetched from CelesTrak to determine satellite position and then calculate opportunities for a desired location and time. This allows a simple STAPI endpoint to be stood up for any satellite, only requiring the satellite ID in the CelesTrak catalog.

Real-World Implementations

Sprint #5 also featured real-world implementations of STAPI, where three organizations—EUSI, Planet, and Open-Cosmos—successfully placed data orders through their STAPI implementations. These implementations showcase STAPI’s practical value in the field:

  • EUSI is using STAPI for their latest tasking API and was able to place an order using it the first day of the sprint.
  • Planet has been involved with STAPI for some time, and with their existing stable tasking API Planet has used STAPI to create a proxy, providing a compliant API on top of their existing API.
  • Open-Cosmos used the STAPI UI to allow users to place and visualize data orders, emphasizing the user-friendly nature of the interface and the flexibility of STAPI in various use cases.
An impact of Open-Cosmos using the STAPI UI.

These real-world applications highlight how STAPI is being adopted by satellite data providers and how it can be used to create seamless, efficient systems for satellite data ordering and management.

Looking Ahead: The Future of STAPI

STAPI will continue its evolution with Sprint #6, scheduled to take place in Philadelphia this October. The STAPI community is actively seeking contributors and sponsors to help further develop the specification and the associated tools. As the project grows we are looking for more vendor implementations and to help and encourage consumers to use these for automatic integration into their own catalogs as data is ordered and ingested.

For more information on how to participate or sponsor STAPI, visit the STAPI GitHub page.

Matt Hanson

Director, Aerospace