What metadata standards should an Earth data platform use?

Use ISO 19115/19139 (or its OGC profile) for discovery metadata, STAC for catalogue and asset-level description of imagery and raster collections, and OGC API - Records to expose a searchable catalogue over HTTP. Most platforms run STAC for assets and an ISO export for formal catalogues.

What is STAC and when should I use it instead of ISO 19115?

STAC (SpatioTemporal Asset Catalog) is a lightweight JSON standard for indexing imagery and raster assets with geometry, datetime and band metadata. Use it for browsable, query-by-bbox-and-time collections; use ISO 19115 when a regulator, INSPIRE, or a formal catalogue requires it. They are complementary, not mutually exclusive.

How do I version geospatial datasets so users know what changed?

Give every dataset a semantic version, an immutable edition identifier, a published and revision date, and a changelog. Never overwrite a published edition in place; publish a new version and keep the old one resolvable so existing analyses remain reproducible.

What metadata fields are non-negotiable for a spatial dataset?

CRS (as an EPSG code), spatial and temporal extent, resolution or source scale, lineage/provenance, licence, and a stable identifier. Without these a dataset cannot be safely reprojected, joined, dated, attributed, or legally redistributed.

Metadata Strategy for Earth Data Platforms

Short answer

A metadata strategy for an Earth data platform is the set of rules that make every dataset self-describing enough to be found, trusted, reused, and reproduced years later. In practice that means committing to recognised standards — ISO 19115 for formal discovery metadata, STAC for imagery and raster catalogues, and OGC API - Records for HTTP-queryable search — and enforcing a small set of non-negotiable fields on every asset: CRS, extent, resolution, lineage, licence, and a stable versioned identifier. The strategy is what separates a maintained platform from a folder of files that only its author understands.

Three layers of metadata, three jobs

It helps to stop treating "metadata" as one thing. An Earth data platform needs three layers, each with a different consumer.

Discovery metadata answers "does this dataset exist and is it relevant?" This is the ISO 19115 / 19139 territory: title, abstract, keywords, spatial and temporal extent, point of contact, licence. Its consumer is a search engine or a catalogue user who has not yet opened the data.

Structural metadata answers "what is inside and how do I read it?" This is CRS, geometry type, band definitions, nodata values, units, attribute schema, and pixel resolution. Its consumer is the software that will open the file — GDAL, PostGIS, a tiling server — and the analyst writing the query.

Provenance metadata answers "where did this come from and can I trust it?" This is lineage: source datasets, processing steps, software versions, dates, and the responsible party. Its consumer is the person auditing a result or trying to reproduce it.

A weak platform documents only the first layer (a nice catalogue card) and lets the other two live in a forgotten README. The structural and provenance layers are the ones that prevent silent reprojection errors and unreproducible analyses.

Choosing standards: ISO 19115, STAC, OGC API - Records

These are not competitors; they sit at different points.

ISO 19115 / 19139 is the formal, comprehensive geographic metadata standard, encoded in XML, and the basis of INSPIRE and many national spatial data infrastructures. Use it when a regulator or a federated catalogue requires it. It is thorough but heavy, and not pleasant to author by hand — generate it from a database rather than maintaining XML manually.

STAC (SpatioTemporal Asset Catalog) is a JSON standard built for exactly the workload Earth platforms have: thousands of imagery scenes or raster tiles that users want to filter by bounding box, datetime, and properties such as cloud cover. A STAC Item describes one asset's geometry, datetime, and links; a Collection groups items and declares shared metadata and band definitions through the eo and raster extensions. STAC is what makes "give me all Sentinel-2 scenes over this AOI, in June, under 10 percent cloud" a single API call.

OGC API - Records is the modern, HTTP-and-JSON way to expose a searchable catalogue, the successor in spirit to CSW. It lets clients query your collection of metadata records with the same conventions as OGC API - Features.

A pragmatic platform runs STAC as the working catalogue for assets, exposes search through OGC API - Records, and produces an ISO 19115 export for any dataset that needs to appear in a formal SDI. The principle is one authoritative source of metadata (your database) with multiple serialisations generated from it.

The non-negotiable fields

Whatever standard you adopt, enforce these at ingestion. A dataset missing any of them should fail validation, not get published with a TODO.

CRS as an EPSG code, not a free-text string. EPSG:4326, EPSG:3857, or a projected UTM code like EPSG:32633. "WGS84" alone is ambiguous about axis order and whether a projection is involved.
Spatial extent as a bounding box in a stated CRS, plus the native footprint geometry where it matters.
Temporal extent — acquisition date for imagery, validity period for derived products.
Resolution or source scale — ground sample distance for rasters, original publication scale for digitised vectors. A 1:250,000 dataset and a 1:5,000 dataset must never be confused at the metadata level.
Lineage — at minimum the source dataset(s) and the key processing steps.
Licence — a machine-readable identifier (e.g. CC-BY-4.0) and the rights holder. Provenance without licence is a redistribution liability.
A stable, resolvable identifier that does not change when the data is re-tiled or re-hosted.

You can validate STAC items programmatically — stac-validator item.json checks an item against the spec and its declared extensions, which is the kind of gate that belongs in an ingestion pipeline.

Versioning so analyses stay reproducible

The failure mode that erodes platform trust most quietly is silent in-place updates. An analyst cites "the slope layer," the slope layer is regenerated next quarter with a better DEM, and the original analysis can no longer be reproduced.

A workable versioning policy:

Semantic-ish versions on datasets (v2.1), where a major bump signals a breaking change to schema, CRS, or methodology.
Immutable editions. A published version is never overwritten. A correction is a new version with a predecessor link.
Dates that mean something — separate published and updated timestamps, plus the source acquisition date, so a user can tell "edited yesterday" from "observed in 2019."
A changelog in plain language attached to each version: what changed, why, and whether downstream users need to re-run anything.
Resolvable old versions. If the identifier in last year's report still resolves to last year's data, the report is still reproducible.

In a PostGIS-backed platform this often means a dataset_versions table keyed by (dataset_id, version) with the metadata as columns plus a JSONB blob for the full record, and a view that always exposes the latest version for convenience while the historical rows stay queryable.

Worked example: ingesting a derived raster

Suppose the platform ingests a landslide-susceptibility raster derived from a 10 m DEM. The ingestion job should:

Read CRS and extent directly from the file: gdalinfo -json susceptibility.tif returns the CRS, geotransform, and corner coordinates, which you store rather than trust a human to type.
Record the GSD (10 m), the nodata value, and the value range/units.
Write lineage: source DEM identifier and version, the algorithm and its parameters, software version, and run date.
Assign v1.0, published = 2026-06-15, licence, and a stable identifier.
Emit a STAC Item (with the raster extension for band stats) and queue an ISO 19115 export.

Every field above came from the data or the pipeline, not from someone remembering to fill a form — which is the only way metadata stays correct at scale.

QA and validation

Validate on ingest, not on publish. Run stac-validator (or an ISO schema check) as a hard gate.
Reproject round-trip. Confirm the recorded EPSG actually round-trips: a feature transformed to another CRS and back should land within tolerance.
Resolve a random old identifier. Periodically pick an identifier from an old report and confirm it still returns the exact edition cited.
Check licence completeness. No asset should reach the public catalogue without a machine-readable licence and rights holder.

Common pitfalls and why they happen

"WGS84" with no EPSG code. Free-text CRS hides axis-order and datum ambiguity; downstream ST_Transform then misaligns data and no one knows why.
Metadata authored by hand. It drifts from the data immediately; derive it from the file and pipeline so it cannot lie.
Overwriting published editions. It breaks every analysis that cited the dataset; version instead of overwrite.
STAC for everything, including regulated datasets. STAC is great for assets but is not a substitute for ISO 19115 where a formal SDI is mandated.

Bathyl perspective

We design platforms so that the metadata is a by-product of the pipeline, never a manual afterthought. CRS, extent, lineage, and version are written by the ingestion job from the data itself, and every published edition stays resolvable. The payoff is reproducibility: an analysis built on the platform last year can still be rebuilt exactly today.