Update Wildfires Data

Wildfires update (weekly, in season)

climate/<version>/weekly_wildfires is the one climate dataset updated on its own schedule: weekly from May to the end of September, when most of the world is in fire season, and with the monthly climate batch the rest of the year. The reminder that triggers it is owid-issues/.github/workflows/update-climate-wildfires.yml.

This is a full runbook, safe to follow without prior experience of this dataset. Run the steps in order. If a check fails, stop and ask rather than working around it: every check here exists because the failure it catches is invisible in the charts.

Related: /update-climate-data for the monthly batch of all climate datasets, /update-dataset for the generic update flow.

What you are updating

Four grapher datasets, feeding 14 charts and 2 narrative charts. wildfires_by_week_average reads wildfires_by_week rather than the garden table, so it has to run after it.

Run it

Throughout, <old> is the current version folder (e.g. 2026-07-27) and <new> is today's date.

1. Branch and draft PR

.venv/bin/etl pr "📊 Update weekly wildfires data" data

2. Bump the version

.venv/bin/etl update snapshot://climate/<old>/weekly_wildfires.csv --include-usages

This copies the step files into <new> folders and appends new entries to the end of dag/climate.yml, leaving the old ones in place. One manual fix is needed:

• Move the new dag entries into the wildfires block, right below the old entries, with the same nesting as the old block (the appended entries lose it). Then delete the appended block at the end of the file.

Keep the old version (its dag entries, step files and snapshot folder) until the review is done. It is removed in step 9. The old snapshot is needed anyway: the snapshot script compares row counts against the most recent earlier version, so step 3 dies with .dvc file is missing 'outs' field. Have you run the snapshot? if it is gone.

3. Fetch the snapshot

.venv/bin/etls climate/<new>/weekly_wildfires

Around 6 minutes (sometimes over 10), and it prints no progress until it finishes.

4. Build the rest of the chain

.venv/bin/etlr climate/<new>

Runs meadow, garden and all four grapher steps (plus any stale upstream deps). The garden step's asserts run here; if one fires, see Checks below.

5. Check the data

Run the three checks in Checks. Do not skip the per-country coverage one: it is the only thing standing between a partial fetch and understated regional aggregates.

6. Commit and push

git add dag/climate.yml etl/steps/data/{meadow,garden,grapher}/climate/<new> snapshots/climate/<new>
git commit -m "📊 Update weekly wildfires data to <new>"   # the pre-commit hook runs make check
git push -u origin <branch>

7. Remap the charts on staging (do not skip this)

The version bump mints new variable IDs. Until they are mapped, every wildfire chart still points at the old ones, so the site keeps showing the old data and Chart Diff shows nothing at all. An empty Chart Diff after a wildfires update almost always means this step was skipped, not that nothing changed.

First wait for the staging server to rebuild and upsert the new datasets (roughly five minutes after the push). Then find the dataset IDs:

from etl.config import OWIDEnv
env = OWIDEnv.from_staging("<branch>")
print(env.read_sql(
    "SELECT id, catalogPath, updatedAt FROM datasets WHERE catalogPath LIKE %(p)s ORDER BY catalogPath",
    params={"p": "climate/%wildfires%"},
).to_string())

Two things that will trip you up here: datasets.catalogPath has no grapher/ prefix (climate/2026-08-01/weekly_wildfires), and read_sql uses pymysql's %(name)s placeholders, not :name. If the four <new> rows are missing, staging has not finished; wait rather than proceeding.

Then match each old dataset to its new counterpart and apply. Four pairs, matching short names in the same order (weekly_wildfires, wildfires_by_year, wildfires_by_week, wildfires_by_week_average):

STAGING=1 .venv/bin/etl indicator-upgrade match -old <old_id> -new <new_id> --perfect-match-only
# ... once per pair, then:
STAGING=1 .venv/bin/etl indicator-upgrade upgrade --dry-run
STAGING=1 .venv/bin/etl indicator-upgrade upgrade

Expected output: names are identical across versions, so every old indicator gets a perfect match (68 mappings in total for the 2026-08-01 run, across 14 charts and 2 narrative charts). Two normal-looking warnings that are not problems:

• "N unmatched variables in new dataset" — match only considers old variables that at least one chart uses, so new indicators nothing charts yet are correctly left alone.
• "All variables in the old dataset have been matched" is the line you actually want to see. If instead some old variables are unmatched, stop: a short name changed and the mapping needs a human.

etl indicator-upgrade auto reports "No dataset migrations detected" for this dataset and does nothing. Use the explicit per-pair match above. To reverse a bad remap: STAGING=1 .venv/bin/etl indicator-upgrade undo.

Confirm it took, by checking that no chart is left on the old datasets:

print(env.read_sql("""
  SELECT d.catalogPath AS dataset, COUNT(DISTINCT cd.chartId) AS n_charts
  FROM datasets d JOIN variables v ON v.datasetId = d.id
  LEFT JOIN chart_dimensions cd ON cd.variableId = v.id
  WHERE d.catalogPath LIKE %(p)s GROUP BY d.catalogPath ORDER BY d.catalogPath
""", params={"p": "climate/%wildfires%"}).to_string())

The <old> rows must all read 0 and the <new> rows must carry the charts (2 / 7 / 5 / 2 for weekly_wildfires / by_year / by_week / by_week_average).

8. Verify on staging

curl -s "http://staging-site-<branch>/grapher/weekly-area-burnt-by-wildfires.csv" | awk -F, 'NR>1{print $3}' | sort -u | tail -1

The last value is an ISO week label (e.g. 2026-W39). On staging it should be the new bin's week, and on production (https://ourworldindata.org/grapher/...) still the previous one. Then open Chart Diff, enable "Show all charts", and read it with the next section in mind.

No separate announcement. Wildfire refreshes ride on the monthly climate announcement; one post per weekly refresh would flood #data-updates-comms.

9. After review: retire the old version, then merge

Once the review is done, remove the <old> version and archive it:

# Delete the six <old> wildfires entries from dag/climate.yml, then:
git rm -r etl/steps/data/{meadow,garden,grapher}/climate/<old> snapshots/climate/<old>
git add dag/climate.yml && git commit -m "🔨 Remove the superseded <old> wildfires steps"
.venv/bin/etl archive-dag        # reads COMMITTED history, so commit first
git add dag/archive/climate.yml && git commit -m "🔨 Archive the superseded <old> wildfires steps"
git push

archive-dag should add exactly the six <old> wildfires steps. If it sweeps in unrelated steps somebody else left un-archived, git checkout those lines to keep the PR scoped, and never hand-edit the archive file. Then merge.

How to read what changed

Two things always change, and only one of them is new data:

1. A new weekly bin appears. That is the update.
2. The previous last point moves up. That is the source settling, and it is expected. What would not be expected, and is worth stopping for: an older point moving, or any point moving down.