Short answer

A spatial data catalog is the difference between a team that finds the authoritative DEM, parcel layer, or geology map in seconds and a team that re-downloads, re-clips, and re-projects the same data every project because nobody can tell which copy is current. A catalog is a searchable index of datasets carrying structured metadata — spatial extent, CRS, temporal coverage, lineage, licence, and a stable access link — not a folder of files. For technical teams the two practical standards are ISO 19115 for formal geospatial metadata and STAC for indexing time-stamped raster and vector assets, often exposed through an OGC API.

Why a shared folder is not a catalog

A network drive or cloud bucket stores files; it does not answer questions. Given boundary_v3_final_REAL.shp and boundary_2024.gpkg, a folder cannot tell you which is authoritative, what CRS each is in, when they were last updated, or whether you are allowed to redistribute them. A catalog adds the layer that makes data usable by people who did not create it:

  • Findability — search by area, theme, date, and keyword instead of remembering filenames.
  • Identity — each dataset has a stable identifier and a single authoritative location, so "the" parcel layer is unambiguous.
  • Trust — metadata records source, processing lineage, accuracy, and currency, so a user can judge fitness for purpose before loading the layer.
  • Access — a documented method (download, API endpoint, tile service) rather than tribal knowledge about where files live.

For geology and terrain teams this matters because the cost of an undiscovered or stale layer is not abstract: a buffer computed against last year's boundary, or a slope analysis on a superseded DEM, looks fine and is quietly wrong.

The two metadata standards worth knowing

ISO 19115 / 19139 is the long-standing international standard for describing geographic information. It defines a rich element set — identification, extent, reference system, data quality and lineage, distribution, constraints — and is what national Spatial Data Infrastructures and INSPIRE-compliant catalogs are built on. It is thorough but heavyweight; the XML encoding (19139) is verbose.

STAC (SpatioTemporal Asset Catalog) is a lightweight, JSON-native specification designed for indexing geospatial assets — typically imagery, DEMs, and other time-stamped rasters, but increasingly any spatial collection. A STAC Item is a GeoJSON Feature with a geometry, a datetime, a properties block, and assets (links to the actual files, e.g. a Cloud-Optimized GeoTIFF). Items group into Collections, and Collections into a Catalog. STAC is searchable through the STAC API, which supports queries by bounding box, time range, and arbitrary properties.

A pragmatic position for most project teams: run STAC operationally because it is easy to author and serve, and map the required fields to ISO 19115 when you need to publish into a formal SDI or satisfy a procurement requirement. They are not mutually exclusive.

A minimal STAC Item

A STAC Item for a single DEM tile shows the model concretely:

{
  "type": "Feature",
  "stac_version": "1.0.0",
  "id": "dem-glo30-N41E013",
  "bbox": [13.0, 41.0, 14.0, 42.0],
  "geometry": { "type": "Polygon", "coordinates": [[[13,41],[14,41],[14,42],[13,42],[13,41]]] },
  "properties": {
    "datetime": "2021-04-22T00:00:00Z",
    "proj:epsg": 4326,
    "gsd": 30
  },
  "assets": {
    "data": {
      "href": "s3://bucket/dem/glo30_N41E013.tif",
      "type": "image/tiff; application=geotiff; profile=cloud-optimized",
      "roles": ["data"]
    }
  },
  "links": [ { "rel": "collection", "href": "./collection.json" } ]
}

This single record is searchable by extent (bbox), time (datetime), resolution (gsd), and CRS (proj:epsg), and it points to a Cloud-Optimized GeoTIFF that clients can read in partial-range requests without downloading the whole file. That is the core of a usable catalog.

Required metadata: the non-negotiable fields

Whatever standard you adopt, enforce a minimum set per dataset. Make these required at ingestion, not optional:

  • Identifier — stable, unique, never reused.
  • Spatial extent and CRS — bounding box plus the authoritative EPSG code.
  • Temporal coverage / currency — acquisition or validity date, and last-updated.
  • Lineage — source, processing steps, and parameters (e.g. "resampled to 10 m bilinear, reprojected EPSG:32631→3035").
  • Quality — accuracy figures or known limitations.
  • Licence and constraints — redistribution rights, attribution, sensitivity.
  • Access link — the single authoritative location or endpoint.

A dataset missing licence or lineage is a liability: you cannot legally redistribute the first, and you cannot defend an analysis built on the second.

Versioning and authority

A catalog must answer "which version is current?" deterministically. Use explicit, immutable version identifiers (date-stamped or semantic) rather than _final, _v2_real. Keep superseded versions discoverable but clearly flagged as deprecated, and point a stable "latest" alias at the current one. Tie this to your data store: PostGIS for vector with table-level versioning, object storage with versioned keys for rasters. The catalog records the lineage between versions so a user can see what changed and why.

Serving the catalog: OGC APIs

Once data is catalogued, expose it through standard web APIs so it is consumable without bespoke clients:

  • OGC API – Features for vector: query collections of features by bbox and attribute over HTTP, returning GeoJSON.
  • OGC API – Records for the catalog itself: a modern, web-friendly way to search dataset metadata (the successor pattern to CSW).
  • STAC API for raster/imagery search by space, time, and properties.

These let a QGIS user, a notebook, or a dashboard pull the authoritative layer directly from the catalog, which is what finally breaks the re-download cycle.

Validation and QA

  • Validate metadata against the schema — STAC has stac-validator; ISO 19139 has XSD validation. Reject records that miss required fields at ingestion.
  • Check the access link resolves and the asset opens in the declared CRS (gdalinfo on the COG, ogrinfo on the feature service).
  • Confirm extent matches the data — a bbox that disagrees with the actual footprint breaks spatial search.
  • Audit licences periodically so redistribution stays compliant as sources change terms.

Common mistakes and why they happen

  • Calling a folder a catalog. No search, no enforced metadata, no authority. People keep re-creating layers because they cannot find or trust the existing one. Fix: index with structured metadata.
  • Optional metadata. If lineage and licence are optional, they will be empty exactly when you need them. Fix: enforce a required minimum at ingestion.
  • Mutable version names. _final_v2 tells you nothing about order or currency. Fix: immutable identifiers plus a "latest" alias.
  • Designing the API before the users. An endpoint nobody queries the way you built it. Fix: define the recurring questions (which layer, where, when) first, then choose Features/Records/STAC accordingly.
  • Ignoring CRS in metadata. A catalogued layer without a declared CRS forces every consumer to guess. Fix: make EPSG a required field.

Bathyl perspective

We treat the catalog as the product, not a byproduct of it. A geological survey, a terrain model, or a processed imagery stack only compounds in value when the next project can discover it, read its lineage, and trust its currency without phoning the person who made it. Structured metadata and a standard access API are what turn one-off deliverables into an asset the team keeps drawing on.

Related reading

Sources