From STAC Discovery to a Trustworthy Map: Verifying COG Data, Provenance and Delivery

STAC makes geospatial assets discoverable. A Cloud Optimized GeoTIFF makes a raster addressable through HTTP byte ranges. Neither statement guarantees that the pixels reaching a map are the intended pixels, that the renderer chose the right overview, or that a user can still identify the source after clicking “Preview”. Those are system properties. They have to be designed and tested across catalog, data access, rendering and interface boundaries.

I used Tellurion, my independent Rust geospatial project, to examine that full path. The test case was a real ESA WorldCover 2021 tile covering part of Italy. This was a bounded engineering validation, not a claim of production service, general STAC conformance, or support for every COG profile. The useful result is the method: make each boundary explicit, compare the raster output with an independent oracle, and report delivery behaviour exactly as observed.

Discovery should not cause execution

The STAC search returned items and their assets without registering or fetching those assets. That separation matters. Catalog metadata comes from another trust domain, and merely browsing results should not create server-side resources or trigger large downloads. Tellurion offered Preview only for a finite set of recognized candidates, then revalidated the selected descriptor at the transition into a temporary source.

One explicit action registered one temporary source. While that source was active, another preview could not silently replace it. The interface carried the collection, item, asset, media type, roles, source item link and catalog-supplied description into the inspection and map steps. It also kept catalog description separate from server attribution. This is provenance as product behaviour: the map does not detach from the record that led to it.

Inspect the object before interpreting it

The source was a 36,000 × 36,000 pixel, single-band palette raster in EPSG:4326. Its internal tiles were 1,024 × 1,024 pixels, nodata was class 0, and the embedded palette contained 256 entries. Six overviews sat below the main image, creating seven levels from 36,000 pixels square down to 562 pixels square. For this object, Tellurion exposed one compatible rendering choice: its embedded palette. That fact belongs to this file and implementation; it should not be generalized into a broad profile claim.

This inspection step gives the renderer constraints it can defend. Coordinate reference system, extent, nodata, palette and overview structure all affect the final RGBA tile. If any of them are assumed rather than read, a plausible map can still be wrong.

Use an independent pixel oracle

The strongest check did not compare screenshots. It compared five 256 × 256 RGBA tiles, spanning the main image, two overview levels and two source edges. That is 327,680 pixels in total. Every RGBA value matched, including every alpha value.

The oracle was deliberately independent. GDAL explicitly extracted the same image file directory selected by Tellurion: the main IFD for the high-zoom tile, overview ordinal 3 at 2,250 × 2,250, and overview ordinal 5 at 562 × 562. A separate script mapped each destination pixel centre through inverse Web Mercator, floored the source coordinate, read the class value and applied the source palette and nodata alpha. It did not call GDAL’s generic warp sampler or reuse Tellurion’s rendering code.

That detail resolved a valuable discrepancy. A whole-dataset GDAL warp was exact at high zoom but differed by hundreds of pixels at lower zoom. That comparison exercised a different sampling operation. The exact match was established only after fixing the selected IFD and pixel-centre/floor contract explicitly. An oracle is useful only when its sampling contract is explicit.

Measure delivery without inventing a cache story

COG efficiency is often summarized as “reads only what it needs.” The actual observations were more precise. After source registration, driver metadata inspection returned 65,536 bytes in one range request. The registration probe was excluded from the driver counters, so this is not an end-to-end cold HTTP request count. One representative z10 tile required four range reads totalling 349,694 bytes. Repeating that tile produced the same four reads and the same 349,694 bytes.

The measured repeat showed no reduction in range requests or returned bytes on this path. It is not evidence of a warm-cache improvement.

This distinction matters to platform leaders because a format capability is not an operational outcome. Object layout, network latency, request coalescing, application caching and CDN policy all shape cost and responsiveness. A trustworthy report records the layer where a measurement was made and avoids turning one local observation into a production capacity claim.

The architecture lesson

A credible geospatial platform makes evidence travel with data. Discovery stays read-only. Execution requires an explicit transition. Inspection produces constraints for rendering. Pixel correctness is checked outside the implementation. Delivery telemetry describes real I/O. Provenance survives into the map rather than disappearing behind a layer title.

The boundaries also create useful ownership. A catalog team can define what makes an asset eligible for preview without deciding how raster samples are produced. A rendering team can document its selection and sampling rules without rewriting the discovery client. Platform engineers can observe requests and bytes at the gateway without treating a browser screenshot as a performance test. The interface then gives users enough context to challenge the output. Clear contracts make failures easier to locate: an incorrect asset identity, a misunderstood COG structure, a pixel mismatch and an inefficient delivery path are different problems with different evidence.

This is also how I approach architecture work more broadly. Interfaces should expose the decisions operators and users need to evaluate, while tests cross implementation boundaries instead of merely repeating internal logic. In Tellurion, the case is intentionally narrow: one real WorldCover object, one compatible palette path, five exact tiles, and a browser workflow exercised against a real backend. The limits are part of the result.