The short answer

A client dashboard for Earth data is the visible tip of a data product, not the product itself. It works only when a structured source of truth sits underneath: a versioned data model, automated derivation of the layers shown, explicit metadata, and a refresh process that does not depend on someone re-exporting files by hand. Build the dashboard last. If the layer beneath it is a folder of one-off shapefiles, the dashboard will rot the first time the data updates.

Scope the dashboard to the handful of decisions the client makes repeatedly. A dashboard that tries to show everything you produced becomes a layer switcher nobody uses; one that answers "is this corridor exposed to landslide risk, and as of when" earns its place in a workflow.

Architecture: five tiers, kept separate

The reliable pattern separates concerns so each tier can change without breaking the others.

  1. Source ingestion. Raw inputs land in an unmodified staging area: imagery scenes, DEMs, vendor vector data, field collections. Keep originals and record where each came from.
  2. Normalised storage. A canonical store — almost always PostGIS — holds clean, CRS-consistent, validated data. This is the source of truth. Everything downstream derives from it.
  3. Derived analysis layers. Slope classes, change masks, risk scores: products of repeatable processing, regenerated on a schedule, never hand-edited in place.
  4. Publishing formats. The shapes the dashboard consumes: vector tiles (MVT) or Cloud Optimized GeoTIFFs for fast display, an OGC API – Features endpoint for query and download.
  5. Interface. The dashboard itself — MapLibre GL or Leaflet plus a thin UI — reading only from tier 4. It contains no analysis logic.

The discipline is the boundary between tier 2 and tier 5: the interface must never become a hiding place for data fixes. If a value is wrong on the dashboard, the fix belongs in PostGIS and flows back out through the pipeline.

Choosing the delivery mechanism

The serving choice follows from how the data is used, not from fashion.

Vector tiles suit large, mostly static layers that need only to draw fast at any zoom: administrative boundaries, geological units, hazard zones. Pre-render them once and serve from object storage. A typical pipeline tiles a PostGIS table with ogr2ogr or tippecanoe, then styles in MapLibre. Tiles are cheap to host and scale effortlessly because they are just static files.

An OGC API – Features endpoint suits data the client must filter, query, or pull into their own systems. Standing up pygeoapi over PostGIS gives a standards-compliant REST/JSON interface where the client can request, say, all monitoring points with displacement above a threshold:

GET /collections/monitoring/items?displacement_mm=gt:10&datetime=2026-01-01/..

Because it is an OGC standard, the same endpoint plugs straight into QGIS or another GIS without bespoke glue.

COGs handle continuous raster layers — a DEM, an NDVI composite — letting the browser fetch only the tiles and overviews it needs through HTTP range requests, with no full download.

Most real dashboards mix these: vector tiles for context, an API for the interactive working layer, a COG or two for raster backdrops.

Metadata and update logic, designed in from day one

Two things separate a durable data product from a screenshot with buttons.

Metadata travels with every layer. Each layer should carry, at minimum: source, CRS (as an EPSG code), the date or temporal range, processing lineage, and allowed use / licensing. Surface the date prominently in the UI — "Sentinel-2 composite, 2026-05, cloud-masked" tells the client far more than an undated polygon. Without it, a polished overlay implies a confidence the data does not support.

Updates improve the asset, not recreate the deliverable. Schedule the refresh: a job re-runs the derivations from PostGIS, re-tiles, re-validates geometry and attribute ranges, and swaps the published artifacts. The dashboard reads the newest version by convention (a versioned path or a pointer the pipeline updates). The test of a real data product is that the second update is cheaper than the first, not a from-scratch rebuild.

A worked example

A client monitoring slope stability along a rail corridor wants a quarterly view.

  • InSAR-derived displacement points and a corridor DEM land in staging.
  • A pipeline cleans and loads displacement into PostGIS, validating geometry with ST_IsValid and reprojecting to the corridor's UTM zone with ST_Transform.
  • A scheduled job classifies displacement into severity bands and recomputes a corridor-segment risk score, writing results back as derived tables.
  • Severity points publish through pygeoapi; the corridor DEM publishes as a COG; geological context publishes as vector tiles.
  • A MapLibre dashboard shows the corridor, lets the client click a segment to see its displacement history, and labels the data window ("InSAR stack through 2026-Q1").

When the next quarter's data arrives, only the pipeline runs. The dashboard updates with no manual touch, and the metadata date moves forward automatically.

Common mistakes and why they happen

  • Calling a folder of files a data product. Without metadata and update logic, it is a one-off export; the "product" framing hides the fact that the next update will be a full rebuild.
  • Designing the API before the user. An endpoint with no defined consumer accumulates parameters nobody calls. Start from the questions the client actually asks.
  • Putting analysis in the front-end. When a layer is computed in JavaScript at render time, the logic is invisible, untestable, and lost the moment the page changes. Compute upstream, serve results.
  • Ignoring provenance and licensing. Redistributing imagery or vendor data through a client dashboard can breach terms; track rights per layer before publishing.
  • Building a dashboard when they wanted data. A UI is a maintenance liability. If the client lives in their own GIS, ship the OGC API or the dataset and let them style it.

Validation before delivery

Before a dashboard goes live, confirm that every layer's CRS, date, and source are present and visible; that a known control value reads correctly through the full pipeline (PostGIS → tile/API → browser); and that running the refresh job twice produces the same output. Check edge tiles and the corridor margins, not just the centre, because clipping and reprojection errors hide at the boundaries. A dashboard you cannot re-derive on demand is a snapshot, not a product.

Bathyl perspective

We treat the dashboard as the thinnest possible layer over a maintained spatial system. The value is not the map widget; it is that the science underneath stays traceable while the output becomes reusable. If the client can ask the same question next quarter and trust the new answer without us rebuilding anything, the product is doing its job.

Related reading

Sources