19
Köppen zones under the base CV gate (tmax 19 pass, tmin 15)
The API's neighborhood-resolution correction is a quantile regression forest that adjusts grid-scale air temperature toward per-polygon values, trained on weather-station observations and gated by held-out cross-validation in every Köppen climate zone it serves. This page reports two facts about it. First, the zones where each serving band's correction is validated to beat the raw grid; the historical band, the near-term band, and all seven forecast lead days each carry their own independently published gate, so forecast and near-term data are corrected today, not only the historical record. Second, the worldwide set of 3,977 stations reporting on the METAR surface-observation network (3,377 of them four-letter ICAO airport stations, the rest coastal and marine observing platforms) that can contribute a station blend or a direct in-polygon observation. The model corrects air temperature only; humidity, wind, and solar radiation remain at grid scale, so heat index, UTCI, and WBGT improve only through their temperature term.
The raw ERA5-Land / Open-Meteo grid value, served whenever no validated correction applies. Always disclosed as such.
The QRF model correction, applied only where the zone, target, and band pass their cross-validation gate.
The model correction refined by a distance-weighted kriging blend against real nearby weather stations, under its own gate.
A real weather-station observation inside the polygon itself. Overrides every modeled value outright.
Four tiers, strictly ordered; a lower tier never overwrites a higher one, and every row carries a data_source stamp naming which tier produced it.
Zone colors show where the selected band's correction is validated; ink dots are the 3,977 METAR stations that can ever contribute a Tier 2.5 blend or a Tier 3 override. A gray zone is not an error: it means the gate did not pass there, so those polygons serve the raw grid value, disclosed as such. Client project locations are deliberately not drawn here; deployment is a separate fact, reported in the table further down.
Zones are drawn from the same Köppen–Geiger classification raster the pipeline assigns polygons against (Beck et al. 2018, the ~3 km raster bundled with kgcpy), aggregated to a 0.5° display grid for this page; cells that are mostly ocean are omitted, as are latitudes above 84°N and below 60°S (Antarctica's ice-cap zone carries no gate, and the 7 Antarctic research-station METARs below that edge are the only stations not drawn). The forecast view shows day 1 as the representative state; days 2–7 are in the chart and matrix below. In the near-term and forecast bands, a published gate lists only the zones that passed review, so the gray "evaluated, not passed" category appears only in the historical view, where the four tmin failures (Am, As, BWh, Cwa) are explicit.
Each forecast lead day is gated independently; a correction validated for tomorrow is never assumed to hold a week out. The solid lines count zones whose gate passes at each lead; the dashed lines count how many of those passes rest on per-polygon spatial skill rather than a flat per-zone bias adjustment.
On day-ahead forecasts, 11 zones pass for tmax and 9 for tmin. By day 7, tmax narrows to 5 passing zones and tmin holds at 8. The kind of improvement also changes with lead time: at day 1, 7 of the 11 passing tmax zones beat the grid through per-polygon spatial signal; by day 7 only Am does, and the other four passes rest on the flat bias adjustment, a real, validated improvement of a different kind, disclosed per zone in the matrix below. The near-term band (not shown here; it has no lead axis) passes 10 zones on tmax and 5 on tmin, every one of them with spatial skill.
One cell per zone, band, and target. Amber cells pass only through the flat per-zone bias adjustment; the distinction is disclosed rather than folded into a single "pass". Gray cells were evaluated and did not pass, so those polygon-days serve the raw grid value, the gate working as designed.
The ERA5 columns are the base cross-validation gate; the spatial-vs-bias distinction is published for the band gates only, so base-gate passes render solid. The BLEND columns are the Tier 2.5 station-blend gate (near-term band only today): 8 of the 22 evaluated zone labels pass on tmax and 8 on tmin. The blend gate additionally evaluated the tundra zone ET and two coarse latitude-band fallback labels (tropical, temperate); none of the three passed, and they are omitted from the rows above because no other gate covers them.
The map above answers where the model is validated; this table answers what the nine public flagship projects are actually served, counted over every polygon-day each project has ever stored. These are different facts, and a validated zone does not by itself put any specific project above Tier 1 on a given day.
| Project | Köppen zone | Polygons | Grid | Downscaled | Blended | Station | Above grid | Stations reg. |
|---|
All-time polygon-day counts by data_source tier, from the 2026-07-23 fleet snapshot. "Above grid" is the share of each project's polygon-days served from any tier above the raw grid. "Stations reg." is the count of METAR stations confirmed inside one of the project's polygons and reporting as of the last registry refresh; it can exceed a given window's actual Tier 3 row count because registration confirms a station exists and was live at refresh time, not that it reported data for every day since.
Tier 3 rows are rare by construction; a station must fall inside a polygon's own boundary, which is common for county-scale polygons (Phoenix) and rare for neighborhood-scale ones. The station-blend tier began serving on 2026-07-22, which is why it appears in one project's history so far. Shares differ across projects for structural reasons: each project's zone mix determines which gates apply to it, its polygon geometry determines whether a station can ever fall inside, and its onboarding date determines how much of its history was written before the near-term and forecast gates were published (2026-07-22).
The four-tier ladder at the top of this page is the rule; this map is the rule executing on real stored rows. Boston-Cambridge is the one public project where every tier has served so far, and its 591 census tracts are drawn here for two consecutive real days, each tract colored by the data_source stamp actually stored for that tract and day.
These two days are shown because together they exhibit all four tiers, and no single day can: precedence is an UPSERT guard, so when the station blend cleared its gate it replaced the model correction on the identical 467 tracts, a higher tier overwriting a lower one, never the reverse. The 122 raw-grid tracts and the two station-override tracts are unchanged across both days. The overrides are the tracts with a reporting METAR station physically inside their boundary: Logan International (KBOS) in Census Tract 9813, Suffolk, and Hanscom Field (KBED) in Census Tract 3593.01, Middlesex. Hover any tract for its stored values; blended tracts also report how many stations contributed, the nearest one's distance, and the station weight actually applied. Geometry is the project's own published tract boundaries; tier assignments are verbatim from the same 2026-07-23 snapshot as the table above.
The model predicts each polygon's temperature anomaly relative to its own grid cell, never the absolute temperature, from static covariates the API already holds: warm-season land-surface temperature, tree canopy, land-cover fractions, built-settlement fraction, population density, and terrain from a digital elevation model.
Folds hold out whole countries or admin regions, never random rows, because random splits leak through spatially correlated neighboring station-days. Per zone and per target, the correction must beat the raw grid on held-out error; a zone that fails ships the grid value instead.
Reported 95% intervals are split-conformal calibrated per Köppen zone on held-out stations, with empirical coverage checked against the 0.95 target during cross-validation rather than assumed from the forest's own quantiles.
Polygons whose covariates sit outside the training distribution are flagged (out_of_distribution) in the response rather than silently corrected, and the interval widens accordingly.
Effective resolution is roughly 100 to 300 meters where the LST, canopy, and WorldCover covariates are present, degrading toward roughly 1 kilometer where only coarse covariates exist. The floor is a model-card value that moves with the covariates, never a flat promise.
Each component (QRF, anomaly regression, spatial cross-validation, conformal calibration) is independently established in the literature, but no published study validates this exact combination. The closest precedent, comparing random-forest and kriging approaches in a tropical setting, reported mixed results; no decisive advantage over alternatives is claimed here, only the per-zone gates above.
Retraining follows a calendar backstop plus threshold triggers. The calendar half: the model is re-fit at least annually, folding in a year of new station-days to catch slow concept drift. The threshold half: the deployed version is re-scored against freshly pulled held-out station-days whenever a new region onboards (exactly when out-of-applicability rates are most likely to spike) or a zone's held-out error degrades meaningfully against its original gate. A covariate refresh alone runs as a stateless re-join against the existing model, without triggering a retrain.
Execution today is a manual training build on a temporary EC2 instance, with each new gate reviewed before it is published; there is no live, automated continuous-training pipeline, and this page does not claim one. The current model version, ds-2026.07-rf4, is stamped on every corrected row it serves.
A failed gate serves the raw grid value, labeled as such. The alternative, serving an unvalidated correction everywhere, would look better on a map and be worse in every decision that relies on it.
The product overview, live worked examples, and the coverage matrix for all fourteen data families are on the main product page. The full mechanism, response fields, and per-row provenance vocabulary are in the documentation's neighborhood-resolution section.