Imagery Pipelines

Lesson 0009 stopped at "here is how a picture gets coordinates". Under fit-for-purpose, imagery is the measuring instrument for every boundary you hold — so this is how it is produced, stored, catalogued and served at national scale without bankrupting the project.

From photographs to a basemap

A drone or aerial mission has four phases — flight planning, capture, processing, delivery — and the processing stage is a fixed sequence: feature detection and matching, sparse reconstruction by structure-from-motion, dense point cloud by multi-view stereo, mesh, then DTM/DSM and orthomosaic export.¹

Overlapping capture The drone flies a grid, firing at intervals, producing 70–90% forward and 60–80% side overlap.¹ Overlap is not padding — it is what makes reconstruction possible at all.
Structure from Motion Overlapping images from different angles let the algorithm reconstruct the 3D structure of the scene, recovering camera positions and a sparse cloud together.
Dense cloud and surface Multi-view stereo thickens the cloud; from it come the elevation products.
DSM and DTM A DSM includes surface objects — trees, buildings. A DTM is the bare terrain with those removed.¹ Orthorectify against a DSM and building tops sit correctly but their bases shift; against a DTM the ground is right. For cadastral tracing you want the ground right.
Orthomosaic The deliverable: a single, terrain-corrected, seamless image you can trace boundaries from.

The accuracy equation

Accuracy is the product of three interacting variables: ground sampling distance, image overlap, and ground control points.² GSD is how much ground one pixel covers — resolution. GCPs are what tie the whole reconstruction to the earth. A flight with superb GSD and no ground control produces an internally exquisite model in the wrong place, which is lesson 0009's warning arriving with a bill attached.

Storage: the problem nobody budgets for

Three districts of 30 cm orthoimagery is terabytes. The naive approach — one enormous GeoTIFF per district on a file share — fails in every direction at once: nothing can open it, every client downloads all of it, and the storage bill recurs forever.

The current answer is the Cloud Optimized GeoTIFF. A COG is a regular GeoTIFF aimed at being hosted on an HTTP file server, with an internal organisation enabling more efficient cloud workflows.³ Two mechanisms do the work: internal tiling and overview layers structuring the data hierarchically, plus HTTP GET range requests letting clients ask for just the parts of a file they need.³

ordinary GeoTIFF   client wants 1 km²  →  downloads the whole 40 GB file
COG                client wants 1 km²  →  reads the header, then range-requests
                                          the few tiles it needs

+ overviews: zoomed-out views read a small pyramid level, not full resolution
+ legacy-safe: ordinary GIS software still opens it as a plain GeoTIFF

The payoff beyond speed: COG-aware software streams the portion it needs, improving processing times and enabling real-time workflows that were not previously possible — and it removes the copying and caching, because many applications read one online file.³ One authoritative copy is also a governance win: no district silently working from last year's imagery.

Cataloguing: STAC

Once imagery is many files across years, districts and suppliers, the question stops being "where is the file" and becomes "what covers this parcel, from when, at what accuracy". STAC — the SpatioTemporal Asset Catalog — is the standard answer, addressing fragmentation in imagery archives with a common structure.⁴

Concept	Is
Item	A GeoJSON feature — the atomic unit of data plus metadata, with temporal information, thumbnails and asset links⁴
Asset	The actual file an item points at — usually a COG
Catalog	JSON listing items, with child catalogs for browsing
Collection	A catalog with added metadata: spatial and temporal extent, licence, providers, keywords

Because a STAC catalog can be plain static JSON on the same storage as the imagery, this is achievable on a small budget — which matters for the sustainability argument in lesson 0006. Licence and provider metadata on collections is not decoration either: donor-funded imagery often carries redistribution terms that outlive the people who negotiated them.

Serving it

Tracing clients need tiles, not files. Pre-cut pyramids are served as WMTS, or its modern sibling OGC API — Tiles from lesson 0005; dynamic tilers read COGs directly and render on demand, trading a little latency for no pre-generation and no duplicate storage. GDAL underlies essentially all of this — conversion, overview building, reprojection, mosaicking — and is the one dependency worth being genuinely fluent in whichever stack you choose.

Provenance, one more time

Every parcel traced from imagery inherits that imagery's accuracy — so the spatial_unit row from lesson 0007 should reference the STAC item it was traced from, not the string "imagery". Then "which parcels came from the 2024 flight that we now know was 2 m off?" is a query, and re-verification is a work list rather than a crisis. This is lesson 0015's typed observation information, made operational: LA_SpatialSource pointing at a catalogued asset.

Drill 1 — Which product or standard?

Drill 2 — Recall

Your primary source

cogeo.org — the Cloud Optimized GeoTIFF site: what the format is, how range requests and overviews work, and how to produce one with GDAL:
cogeo.org

Then the STAC specification overview for items, catalogs and collections. Together they are the two-hour read that changes how you cost and architect an imagery programme.

Ask your teacher. Where this goes next: "write the GDAL commands to produce a COG with overviews", "design the STAC collection structure for a three-district programme", "what should the imagery clause in the procurement spec say?", "dynamic tiler or pre-generated pyramids for our load?"