Space data platforms
DraftA satellite that collects data nobody can find, open or afford is not producing value. The infrastructure between downlink and use is unglamorous and is frequently the difference between a dataset that is used and one that is not.
The scale
| Source | Approximate volume |
|---|---|
| One high-resolution optical satellite | ~200 GB per day downlinked |
| A hundred-satellite constellation | ~20 TB per day |
| Sentinel programme | Petabytes per year, openly distributed |
| Rubin Observatory | ~20 TB per night |
| Landsat archive since 1972 | Petabytes, continuously reprocessed |
At these volumes the traditional model, in which a user downloads files and processes them locally, stops working. Moving a petabyte is slower and more expensive than moving the computation to it, which is the structural change that has reshaped the field.
Standards
Interoperability is what allows data from different providers to be used together, and it is achieved by a small number of standards.
| Standard | Layer | Purpose |
|---|---|---|
| CCSDS | Space link | Packet telemetry, file delivery, channel coding between spacecraft and ground |
| STAC | Catalogue | SpatioTemporal Asset Catalog: a common JSON description of geospatial assets |
| OGC WMS, WCS, WFS | Service | Standard web interfaces for map, coverage and feature access |
| netCDF and HDF5 | Format | Self-describing multidimensional array storage with metadata |
| GeoTIFF and COG | Format | Georeferenced raster; Cloud Optimized GeoTIFF adds internal tiling and overviews |
| Zarr | Format | Chunked array storage designed for object stores and parallel access |
| ISO 19115 | Metadata | Geographic metadata description |
STAC deserves particular note because it solved a real problem cheaply. Every provider previously published a different catalogue with a different API, so combining sources required custom integration per provider. STAC gives a common description of what an asset is, where and when it covers, and how to access it, which makes a multi-provider search a single query. Its adoption was rapid because it is simple and was designed by the people who needed it.
Cloud-native formats
The distinguishing property of a cloud-native format is that a client can read part of a file over HTTP without downloading the whole thing.
| Property | Traditional | Cloud-native |
|---|---|---|
| Access | Download the whole file | Range requests for the bytes needed |
| Layout | Sequential | Internally tiled, with overviews |
| Index | Read the file to find things | Header describes the layout |
| Parallelism | One reader per file | Many readers on disjoint chunks |
| Example | Plain GeoTIFF, HDF5 on a filesystem | COG, Zarr, HDF5 with cloud drivers |
A Cloud Optimized GeoTIFF is an ordinary GeoTIFF with its data arranged in internal tiles and reduced-resolution overviews, and its layout described in the header. A client wanting a small region at low resolution issues a couple of range requests and transfers a few hundred kilobytes from a file of many gigabytes.
This sounds like a minor optimisation and is architecturally decisive. It is what allows an application to display a global mosaic interactively without any preprocessing, and it removes the need for every user to maintain a copy of the archive.
Analysis-ready data
The processing chain in Satellite image processing produces correctly calibrated products, and a user still faces work before analysis: reprojecting to a common grid, applying cloud masks, harmonising between sensors, and stacking by time.
Analysis-ready data moves that work upstream. Products are delivered already corrected to surface reflectance, tiled to a fixed grid, cloud-masked, and consistent across acquisitions so that a time series can be differenced directly.
The value is that this work is done once by the provider rather than repeatedly and inconsistently by every user. The cost is loss of flexibility, since a user with different requirements must go back to the lower-level product, so well-designed platforms publish both.
Discovery
The branch at the bottom is the structural change of the past decade. Public cloud hosting of major archives, with the Sentinel and Landsat collections available in commercial object storage, means a user can run analysis adjacent to the data and transfer only results.
This has genuine democratising effects, since a researcher without institutional storage can process a continental time series. It also creates a dependency on commercial cloud providers for access to publicly funded data, and egress pricing means moving data out can cost more than the analysis, which is a lock-in mechanism worth naming.
Licensing and cost
Access policy determines use more than technical quality does.
| Model | Examples | Effect |
|---|---|---|
| Fully open | Landsat, Sentinel, MODIS | Maximum use; enables research and commercial products alike |
| Open with attribution | Many government datasets | Similar effect |
| Commercial per scene | High-resolution imagery | Restricts to funded applications |
| Commercial subscription | Analytics services | Predictable cost, limited redistribution |
| Restricted | Defence and intelligence | Access by clearance |
The Landsat open data policy is the clearest natural experiment in the field. Imagery that had been sold at hundreds of dollars per scene was made free in 2008, and use increased by orders of magnitude, producing scientific and commercial value far exceeding the forgone revenue. It is routinely cited in policy discussions, and the Copernicus programme’s open policy followed the same reasoning.
The general lesson is that for publicly funded observation, the value created downstream substantially exceeds anything recoverable by charging for access. That argument does not transfer automatically to commercial data, where the collection itself must be funded.
The archive as an obligation
Space data has a property most data does not: it cannot be recollected. An image of a place on a date is unique, and if it is lost the observation is gone.
This makes archiving a permanent obligation rather than a project task, and it implies requirements that outlive any programme.
| Requirement | Reason |
|---|---|
| Format migration | Storage media and formats become unreadable within decades |
| Calibration metadata preservation | Reprocessing with improved calibration requires the original coefficients and context |
| Reprocessing capability | Archives are reprocessed as understanding improves; the capability must be maintained |
| Provenance | Which algorithm version produced a product, so results remain reproducible |
| Institutional continuity | Someone must be funded to do this indefinitely |
The Landsat archive is the model, and its value comes precisely from being long and consistently calibrated. A fifty-year record of Earth’s surface is scientifically irreplaceable, and it exists because successive institutions kept funding curation between the interesting moments. See Ground segment.
References
- CCSDS recommended standards for space data systems, particularly the space link and file delivery protocols.
- STAC Specification, radiantearth.github.io/stac-spec.
- Open Geospatial Consortium standards for WMS, WCS and coverage access.
- Wulder, M. A. et al. “The global Landsat archive: Status, consolidation and direction”, Remote Sensing of Environment, 185:271, 2016.
- Gorelick, N. et al. “Google Earth Engine: Planetary-scale geospatial analysis for everyone”, Remote Sensing of Environment, 202:18, 2017.
- Abernathey, R. P. et al. “Cloud-Native Repositories for Big Scientific Data”, Computing in Science and Engineering, 23:26, 2021.