California Wildfire Risk — Scoring & Validation

A risk score is easy to produce and easy to believe. The hard part — and the part that decides whether anyone should act on it — is whether the number survives contact with what happened next. Everything on this page is machinery for answering that one sentence honestly.

Two numbers answer it. Precision: of the places I flagged high-risk, what fraction actually burned. Recall: of the places that actually burned, what fraction I caught. They trade against each other, and which one you favour depends on whether a miss means a missed fire or a false alarm means a wasted inspection.

I lived in Santa Monica during the January 2025 Los Angeles wildfires. This project started as a personal response to that and became the analysis I most wanted to be able to defend: take a hazard dataset the state publishes openly, turn it into a decision-shaped number, then be rigorous about what that number is and is not worth.

The work sits in the same shape as what hazard and catastrophe risk teams do — score locations, hand the score to someone who has to decide something, and be able to say out loud how confident you are and where the model breaks.

Two sources. CAL FIRE historical fire perimeters — 22,810 polygons spanning 1878 to 2024, the authoritative state record of where fire has been. And NASA FIRMS VIIRS thermal detections from the January 2025 LA fires, which are satellite hotspot points rather than mapped perimeters, and which carry their own confidence field precisely because not every detection is a wildfire.

Everything is stored and measured in EPSG:3310 (California Albers), an equal-area projection, and transformed to EPSG:4326 only on the way out. That is not a formality. Distances and areas computed in raw latitude/longitude are wrong — a degree of longitude is about 111 km at the equator but roughly 88 km at California's latitude — so a 20 km buffer drawn in degrees is not 20 km, and is not even the same distance north to south. Every proximity and density number here depends on that choice being made at ingest rather than patched later.

The score combines three spatial factors, each normalized to 0–100 and then weighted. It always returns the full factor breakdown alongside the headline number, so anyone reading a score can see which signal drove it instead of taking it on trust.

The weights are a heuristic, and it is worth being precise about what that means. Nobody fit 0.5 / 0.3 / 0.2 to data. They encode a domain assumption — that recent, close fire activity is the strongest available signal — and they are stated plainly rather than buried, because a number a reviewer cannot interrogate is not worth much. The principled next step is to fit them against ground-truth burn outcomes with a logistic regression and let the data decide. Because the scoring logic is a pure function decoupled from the queries, swapping trained weights in is a contained change.

The heuristic was built with every perimeter in front of it. Testing it against that same data would guarantee a flattering answer, so the honest version is a temporal split: pretend I only knew about fires through 2023, then check the score against what actually burned in 2024–25. Not a random split — a time split, because in this problem you are always predicting forward.

Stated up front rather than in a footnote, because these are the things that would lead someone to act on the number wrongly.

Six notebooks sit under the scoring logic, each answering one question about the data before it was trusted — whether reprojection was quietly changing distances, how perimeters intersect populated places, whether terrain could be brought in as a factor at all.

The analysis is served through a FastAPI application over PostgreSQL/PostGIS, with the scoring logic isolated as a pure function and unit-tested without a database. The whole stack comes up locally with one docker-compose up, and GitHub Actions runs the suite against a seeded PostGIS service container on every push. The public explorer is a static site that recomputes the same formula client-side against a bundled GeoJSON snapshot, so the map answers instantly with no server round-trip.