Leveraging STAC to support CONUS-scale wildfire modeling
2026-11-04 , Carr

Distributed wildfire modeling generates thousands of COGs per run. We needed them discoverable, viewable, and traceable with minimal custom tooling. This talk covers the STAC catalog we assembled from pgSTAC, stac-fastapi-pgstac, and titiler-pgstac, and what we learned.


At Timmons Group, we build wildfire modeling capabilities for state and local government agencies working on wildfire risk and mitigation. Fire scientists have historically run wildfire modeling software on their own workstations, one landscape at a time. Modeling at regional scale, let alone across an ensemble of weather conditions, is well beyond what that setup can handle. So we built a distributed pipeline aimed at CONUS-wide coverage: it tiles a region, runs a 216-member weather ensemble on each tile, spreads the work across cloud compute, and mosaics everything back into Cloud-Optimized GeoTIFFs (COGs).

It did what we needed, and then it handed us a new problem. We had thousands of COGs sitting in object storage and no good way to make sense of them. The scientists who kicked off the runs couldn't easily find their results or confirm the models had produced what they expected. We had fixed the compute bottleneck and created a discoverability one.

A STAC catalog closed that gap, and we assembled it from open components instead of writing our own. pgSTAC provides the catalog backend on PostgreSQL and PostGIS, stac-fastapi-pgstac gives us a spec-compliant API, and titiler-pgstac renders map tiles on demand from the COGs, with no pre-generated tile pyramids. This is the eoAPI reference architecture, and the talk covers what it took to run it against a production wildfire workload.

We kept ingestion fully decoupled from the pipeline. COGs land in storage, an event queue picks up the notification, and a lightweight indexer writes STAC items into pgSTAC without the pipeline ever knowing the catalog is there.

The data-modeling decisions are where I think most people will find something reusable. We derive collection membership at index time rather than from the storage path, and we attach custom queryable properties that tie each output back to the run that produced it. That traceability is what makes the catalog worth trusting. A scientist can pull up any raster and see the exact run and parameters behind it, instead of guessing whether it's the file they actually meant to grab.

We plan on showing a brief demo going from an API search to a tile rendering in a standard STAC client. I'll finish on the trade-offs that bit us (GDAL cold starts, connection limits, container image sizes) and the parts we're still working out. The catalog, API, tiling, and formats are all open, and the fire-behavior models themselves are freely available from the federal government.


Topics: Select 1–3 areas of interest that best describe your proposal.: Environment, Climate & Sustainability, Raster & Remote Sensing, Spatio-Temporal Asset Catalog

Kirk Davis is a Senior Data Engineer at Timmons Group with over 13 years of GIS experience, specializing in leveraging large geospatial datasets through APIs, automation, and analytics. He focuses on solutions at the intersection of geospatial software, wildfire, and forestry.

This speaker also appears in: