Eight Satellite Imagery Platforms, One Metadata Standard

A shared vocabulary makes systems findable, but it leaves them as far from interchangeable as they were before, and the gap between those two is where most integration budgets disappear.

What a common schema buys

Satellite imagery catalogs converged on a single description format over the past few years. A recent comparison of eight satellite imagery platforms, this platform comparison on observationdata.com, scores them on procurement criteria, and the developer-facing platforms among them expose a catalog that one client can query without special-casing. The advisory brokers in the same list run human-assisted search instead, which is a different product shape.

That format is the SpatioTemporal Asset Catalog. Its data model is deliberately small: an Item is a GeoJSON Feature carrying a geometry, a datetime, and an assets dictionary of links; Items group into Collections, Collections into Catalogs, and an API conformance class defines the search endpoint. The specification reached core version 1.1.0 and API version 1.0.0, and an OGC Community Standard ratification followed in 2025.

The practical result is genuine. A single script can search a commercial archive, a national archive, and an agency archive in one pass, filter on cloud cover, and get comparable metadata back. For a domain that spent two decades on incompatible catalog interfaces, that is a real gain, and a familiar shape to anyone who worked on the structured metadata projects hosted here, where a shared schema solved description and left everything transactional untouched.

Where the shared vocabulary ends

The specification covers discovery. Ordering, authentication, and delivery sit outside it, and each platform implements them in its own way.

The five layers of an imagery integration and how much of each the metadata standard actually reaches. Source: own diagram, following the specification scope published by OGC.

For archive purchases the practical consequence is moderate: an order endpoint has to be written per platform. For tasking it is larger, because a new collection follows an asynchronous sequence of feasibility check, quotation, activation, status polling, and delivery, and every stage of it is vendor-defined. A client that understands search will get exactly as far as the first step.

Three of those five layers have no common ground, and two of the three carry the commercial risk.

Fields that look identical and are not

The subtler problem is semantic rather than structural. Two catalogs can both return a well-formed cloud cover value that means slightly different things, because the upstream provider computes it against its own scene mask before the catalog ever sees it.

Extension coverage varies the same way, and the problem is closer to vocabulary alignment in semantic indexing than to a parsing bug. The electro-optical extension is widely implemented, others less so, and a query that relies on a field one catalog populates and another omits will silently return a narrower result set rather than an error. Collection identifiers are free text, so the same sensor may appear under different names on different platforms, and nothing in the schema prevents that.

Scale introduces its own quirks. Large public endpoints impose collection-level result limits, which is why archive-wide queries against national catalogs are usually partitioned by time rather than issued as one request.

Delivery is standardized by format, not by platform

Cloud-optimized GeoTIFF has done for the pixel layer roughly what the catalog standard did for metadata. Overview pyramids sit at the front of the file and pixel data is tiled internally, so a range request can pull a single tile over HTTP without transferring the scene. A GDAL virtual filesystem path reads directly from object storage, and the saving is substantial for anyone sampling many scenes lightly.

What the format does not settle is where the file lives, what the directory layout around it looks like, or who pays for egress. Reading from the same cloud region as the bucket costs nothing; reading across regions is billed, and that line item surprises teams regularly because it appears nowhere in the imagery price.

The layer nobody models

An aggregator cannot grant rights it does not hold. Its terms of service form a ceiling rather than a floor, and the most restrictive applicable upstream agreement governs what may be done with a scene, regardless of the tier name shown at checkout.

Tier names do not transfer between platforms, and neither necessarily matches the naming used by the provider that collected the imagery. Anything intended for redistribution, publication, or delivery to a third party has to be checked against the provider agreement itself, a document the platform typically references rather than reproduces.

Before treating two catalogs as interchangeable

Five checks separate a catalog that can be swapped in from one that merely looks like it can.

• Confirm which extensions each catalog populates, since a missing field narrows results without warning
• Check how the cloud cover figure is derived, because the number is produced upstream, not centrally
• Compare collection identifiers for the same sensor, which are free text by specification
• Establish where assets are hosted and who is billed for egresswhen they are read
• Read the upstream license rather than the platform tier, as only the former is binding

None of these questions is difficult once asked, and all of them cost more when they surface after the integration is written.

Each answer holds for a platform until its terms change, so the list is worth revisiting whenever a supplier is added.

The honest summary

Interoperability arrived at the discovery layer and stopped there, which is the normal shape for standards that succeed. A common schema is easy to agree on because it commits nobody to anything commercial. Ordering, authentication, and licensing are where platforms differentiate, so those are precisely the layers that resist standardization.

Choosing between imagery platforms is therefore not a question of which catalog is easiest to search. All of them are now roughly equal on that. It is a question of what the remaining integration costs, and that answer differs sharply from one platform to the next.