California Wildfire Risk API & Explorer
A production-grade geospatial service that turns 22,800+ CAL FIRE perimeters into a queryable spatial API and a live, client-side risk explorer — the full pipeline from raw geodata to a deployable REST endpoint.
Why this exists
I lived in Santa Monica during the January 2025 Los Angeles wildfires. This project is both a personal response to that experience and a portfolio piece built toward geospatial software-engineering work — it covers the entire pipeline, from raw CAL FIRE and NASA FIRMS geodata through spatial analysis notebooks to a deployable, tested spatial API.
The dataset spans 22,810 CAL FIRE wildfire perimeters back to 1878 plus NASA FIRMS VIIRS satellite fire detections from the 2025 LA fires. Everything is stored in its native EPSG:3310 (California Albers) projection for accurate metric math and transformed to EPSG:4326 (WGS84) on the way out, so GeoJSON responses render correctly on any standard web map.
Three small modules, one request path
The application is deliberately split into three thin modules so each has a single responsibility. Routes stay declarative, all SQL lives in one place, and database configuration is isolated behind environment variables.
A transparent 0–100 score
The /risk endpoint combines three spatial factors, each normalized to 0–100 and then weighted. It always returns the full factor breakdown alongside the headline score, so the result is inspectable rather than a black box.
An honest note on the weights. These are a heuristic, not trained values — they encode the domain assumption that recent, close fire activity is the strongest risk signal. The principled next step is to gather ground-truth burn outcomes and fit the weights with a logistic regression so the data determines them. Because the scoring logic is a pure function decoupled from the database queries, swapping in trained weights is a localized change — and it's unit-tested with no database required.
Queries, GeoJSON, and a routing gotcha
The API exposes 11 endpoints over the fire data: proximity search with ST_DWithin, per-year aggregates, name lookups, NASA FIRMS satellite detections near a point, and the risk score. Geometry-returning routes emit standards-compliant GeoJSON FeatureCollections in WGS84, ready to drop straight into Leaflet, Mapbox, QGIS, or geojson.io.
A two-layer suite, Dockerized and gated
The test suite is split by dependency. The risk-scoring tests exercise the pure-math scoring function and run with no PostGIS required — covering the high-risk case, the low-risk case, the factor-breakdown structure, and score-bounds clamping. The API-route tests run against FastAPI's TestClient.
CI runs on GitHub Actions: the workflow spins up a postgis/postgis service container, seeds it with fixture data, and runs pytest on every push and pull request. The whole stack — API plus PostGIS — is reproducible locally through a single docker-compose up.
Six analysis notebooks underneath
The API sits on top of a series of geospatial notebooks that build the underlying skills in order — from CRS transformations and buffer/intersection analysis to raster elevation and slope (including writing a Cloud-Optimized GeoTIFF), interactive Leafmap visualization of the 2025 LA fires, and the final PostGIS integration that loads the data and builds the spatial queries the API depends on.