Catalog NEX-GDDP-CMIP6 timeseries_mean_month aggregates (A + new trends B) in STAC / CDH

[peetmate]

@bjyberg — two domain=climate/.../processing=timeseries_mean_month/timeframe=3months/ parquet aggregates are now live on S3 but not in the STAC catalog (the catalog currently holds the per-year processing=analysis-ready .tif rasters under climate/nex-gddp-cmip6-hazards, not these admin-aggregated parquets). Flagging for cataloging + a steer on the CDH path.

A — ensemble_season_timeseries (republished 2026-06-12, CR-119)

• Keys: …/period={1995-2014,2021-2040,2041-2060,2061-2080,2081-2100}/baseline=1995-2014/variable=ensemble_season_timeseries.parquet
• Pruned to the notebook read-set + iso3-first sorted/prunable; restored CR-060 q17/q83(_anomaly) + n_models.
• Schema: iso3, admin0_name, admin1_name, scenario, timeframe, year, hazard, season, baseline_name, mean, sd, q17, q83, n_models, mean_anomaly, sd_anomaly, q17_anomaly, q83_anomaly
• Prior objects backed up to .preFix-20260612-125412.bak.

B — ensemble_season_trends (new, 2026-06-12, CR-117)

• Keys: …/period={2021-2040,2041-2060,2061-2080,2081-2100}/baseline=1995-2014/variable=ensemble_season_trends.parquet (~8 MB each)
• Schema: iso3, admin0_name, admin1_name, scenario, timeframe, season, hazard, stat, mean, sd, stat ∈ {value_slope, value_decade}
• Per-GCM Theil–Sen then ensembled (mean/sd). Significance deferred (AR6 agreement metric, CR-117).

CDH metadata

Drafted a CDH v0.0.1 record for B against your standard: metadata/cdh/ensemble_season_trends.cdh.yaml (TODOs: license, citation, confirm Africa bbox). Can do a parallel one for A.

Questions

1. Right path to catalog these — author CDH YAML → your stac/ build, or a direct collection under climate/? New collection (e.g. nex-gddp-cmip6-hazard-timeseries) vs items under the existing nex-gddp-cmip6-hazards?
2. Item granularity — one item per period? per period×variable? (non-geo admin tables → continental Africa bbox, parquet asset.)
3. Does the CDH record format/fields look right for v0.0.1, or adjust before I template the rest?
4. License + citation to use (the YAML TODOs)?

Filed from hazards_prototype (CR-119 / CR-117).

[peetmate]

FYI on two adjacent STAC freshness gaps (NOT asking for action yet — both sit downstream of producer state you/others already own):

1. exposure_catalog version-stale — cataloged collections are mapspam2017 + GLW3_livestock, but the live canonical domain=exposure is spam2020v1r2 + glw4 (published late-2025). Pending the exposure-producer-drift triage (atlas_notebooks/.../2026-05-26_exposure-producer-drift.md).
2. hazard_risk_vop_* collections are empty stubs (0 items) despite VoP data on S3. The current domain=hazard_exposure/source=nex-gddp-cmip6 canonical is minimal (3 files, 2026-05/06) with CR-068 findings still open.

Logging here so the cataloging gap is visible; will follow up once those producer issues close.

[peetmate]

Third aggregate now live (CR-120) — same timeseries_mean_month/timeframe=3months tree, please include in the cataloging steer:

C — ensemble_season_variability (2026-06-15) — per-GCM interannual variability, ensembled.

• Keys: …/period={1995-2014,2021-2040,2041-2060,2061-2080,2081-2100}/baseline=1995-2014/variable=ensemble_season_variability.parquet
• Schema: iso3, admin0_name, admin1_name, scenario, timeframe, season, hazard, stat, mean, sd, pct_gcms_increase, stat ∈ {iav_sd, iav_delta}.
• iso3-first sorted + prunable (null-stat=0). Baseline file carries absolute iav_sd only; futures add iav_delta + pct_gcms_increase (NDD hazard has no historical baseline → its Δ/agreement are null by design).

So the cataloging question now spans three variables under that tree: ensemble_season_timeseries (A), ensemble_season_trends (B), ensemble_season_variability (C).

[peetmate]

@bjyberg — a third dataset of the same class (admin-aggregate parquet, region=africa, not in STAC) is now live, same questions as A/B above.

C — hazard_change (new, 2026-06-24, CR-093)

Whole-period change + inter-model spread products from R/2.2_haz_change.R, published to canonical CDH-style keys:

• s3://digital-atlas/domain=climate/type=hazard-indices/source=nex-gddp-cmip6/region=africa/processing=hazard-change/timeframe=annual/variable=<name>.parquet
• 10 objects (by-model + ensemble) covering: PTOT % area change + Δmm (ptot_change, ptot_diff), THI livestock heat % area (thi_perc_area), NTx crop heat % area (ntx_perc_area), NDWS/NDWL0 drought/wet frequency (haz_freq).
• Keyed iso3, admin0_name, admin1_name, admin2_name, scenario, timeframe, … + payload (mean/min/max/sd on ensembles). iso3-first sorted/prunable; non-finite → NULL; validated 10/10; prior objects backed up before republish.
• Methods note (2026-06-24): PTOT relative %-change is masked where the 20-yr historic baseline PTOT < 100 mm/yr (hyper-arid denominator → spurious %); absolute Δmm reported everywhere. Rationale + sources captured in the hazard_change record in metadata/data.json (hazards_prototype@develop).

Same Qs 1-4 as above apply to C — new collection vs items under existing, granularity, CDH v0.0.1 fields, license/citation. Happy to template CDH YAML for A + C once you steer the path.

Filed from hazards_prototype (CR-093).

[peetmate]

Related — refreshed hazard_exposure parquets will need cataloging too

Flagging alongside the timeseries_mean_month gap here: a full refresh of domain=hazard_exposure is about to republish (constant-I$ VoP fix + de-saturated historic NDWS + GLW4-2020 + CR-068 none subtype). Same pattern as this issue — the admin-aggregated interaction.parquets live on S3 but aren't in the STAC catalog.

Layout being (re)published:

domain=hazard_exposure/source=atlas_cmip6/region=ssa/processing=hazard-risk-exposure/
  variable={vop_intld15,vop_usd15}/period={annual,jagermeyr}/
  model={historic,ENSEMBLE}/severity={severe,extreme,...}/interaction.parquet

• model=historic = de-saturated NDWS, constant-I$ (supersedes 2025-06-25).
• model=ENSEMBLE = future scenarios, same corrected I$ basis.

Steer wanted @bjyberg: fold hazard_exposure cataloging into this issue, or a separate collection? And same CDH-path question as for the timeseries aggregates. Details + the currency-fix background in AdaptationAtlas/atlas_notebooks#27.

[peetmate]

Two new observational raster tiers published — per-pixel monthly + per-year seasonal CHIRPS PTOT COGs (not yet in STAC/CDH)

Logging two domain=climate datasets now live on digital-atlas but not catalogued, per the running list here. Both differ from the A/B/C entries above — they're raster COG tiers, not admin-aggregate parquets, so they're closer to the STAC's existing per-year processing=analysis-ready raster items than to the parquet gap.

Source: observational CHIRPS v3 / CHIRTS-ERA5 branch. Variable: PTOT (precipitation). Consumer: the Kenya ENSO Explorer notebook (browser, geotiff.js window-read to county).

Tier A — per-pixel monthly

s3://digital-atlas/domain=climate/type=observational/source=chirps-chirts-era5/region=africa/
  processing=monthly/variable=PTOT/PTOT-{YYYY}-{MM}.tif

• 544 COGs, 1981-01 → 2026-04, ~5 km (0.05°), EPSG:4326, Africa extent, 512×512 tiled DEFLATE, nodata=nan, no overviews. Public-read + CORS * + range (206).

Tier B — per-year seasonal (tri-month) sum

s3://digital-atlas/domain=climate/type=observational/source=chirps-chirts-era5/region=africa/
  processing=seasonal/variable=PTOT/season={SEASON}/PTOT_{SEASON}_{YYYY}_sum.tif

• 541 COGs. {SEASON} = the 12 tri-month windows (JFM…DJF); NDJ/DJF attribute December to the previous year. Per-pixel seasonal rainfall total per year. Same grid/extent as Tier A; overviews ON.
• Derived from Tier A (equivalence-checked: seasonal COG == sum of the 3 monthly COGs, max abs diff ~1e-4).

Why both: the notebook A/B-tests fetch-1-seasonal-COG vs fetch-3-monthly-COGs-and-sum-client-side. Published the monthly tier because CHC's raw monthly tifs are unusable in-browser (no CORS) and the Atlas monthly COGs were previously node-local only.

Relation to existing catalogue: current observational tiers on S3 are admin-monthly + admin-periods (parquet, zonal) and climatology (COGs, per-season statistics over a baseline window). These two add the single-month and single-year-seasonal per-pixel rasters.

Possible future tier (deferred): phase-composite seasonal COGs (processing=phase-composite, per ENSO/IOD/Western-V phase) — only if the A/B shows client-side compositing is too heavy.

Questions for you:

1. How would you like these two raster tiers catalogued — folded into the existing nex-gddp-cmip6-hazards-style raster item pattern, a new observational collection, or left out of STAC as known-key notebook dependencies (like the parquets)?
2. Happy to author CDH full-standard.yaml records for them (and/or the climatology tier) against v0.0.1 — documents the datasets and exercises the schema. Want that?

Minor FYI: the monthly COGs carry a STATISTICS_MEAN=-9999 sentinel (no compute_cog_stats pass on that store) and no overviews; the seasonal COGs have real stats + overviews. Can backfill the monthly stats/overviews if a client view needs them.

[peetmate]

Three new raster tiers live — NDVI (type=vegetation) + two flood products (type=flood) — new type conventions to confirm

More domain=climate datasets live on digital-atlas, not yet catalogued — flagging per the running list. These introduce two new type= values under domain=climate (previous entries were type=observational / type=hazard-indices), so they're convention calls for you. All are per-pixel COGs with overviews, CORS *, range, EPSG:4326 — same conventions as the rainfall tiers. Consumer = the Kenya ENSO Explorer notebook.

1. type=vegetation — MODIS NDVI (rangeland/forage)

domain=climate/type=vegetation/source=modis-mod13q1/region=east-africa/
  processing=seasonal/variable=NDVI/season={OND|MAM}/NDVI_{SEASON}_{YYYY}_mean.tif

MOD13Q1 v061, 250 m, seasonal OND/MAM mean, 2000–2025 (52 COGs), reliability-masked. Non-GEE ingest (LP DAAC via earthaccess).

2. type=flood / source=jrc-glofas — return-period flood hazard (static)

domain=climate/type=flood/source=jrc-glofas/region=east-africa/
  processing=return-period/variable=flood-depth/rp={10..500}/flood-depth_rp{RP}.tif

JRC CEMS GloFAS Flood Hazard v2.1 (CC-BY-4.0), 90 m, flood depth (m), 7 return periods (7 COGs). Non-GEE (source.coop mirror).

3. type=flood / source=global-flood-db — observed flood occurrence (per year)

domain=climate/type=flood/source=global-flood-db/region=east-africa/
  processing=annual/variable=flooded/flooded_{YYYY}.tif

Global Flood Database v1.4 (Tellman et al 2021), 250 m, per-year 0/1 flooded union, 15 years in 2000–2018 (years with no Kenya event omitted). Non-GEE (public GCS gfd_v1_4).

Questions:

1. type=vegetation and type=flood — OK as new types under domain=climate, or slot elsewhere / own domain? First non-climate-index rasters we've published — your convention call.
2. Two distinct flood source=s (jrc-glofas static hazard + global-flood-db observed events) under one type=flood — happy with that split?
3. Catalogue these in STAC (raster-item pattern), or leave as known-key notebook deps like the other observational tiers?
4. Standing offer: happy to author CDH full-standard.yaml records for these + the rainfall/SPEI tiers against v0.0.1.

Context: these join the monthly/seasonal PTOT + SPEI-03/12 tiers flagged earlier on this issue — the full KE-ENSO Explorer layer set. region=east-africa = the Kenya-covering footprint, expandable.

[bjyberg]

Nice, thanks Pete. When you get back we should discuss the usefulness of some of these for the CDH and expand their regional coverage where possible/easy. For example, I can see the jrc-glofas data being used in the hub and given that it is already on source.coop we can federate it and maybe use a gdal vrt or kerchunk/icechunk to point at the individual tiles making them easier to load and do spatial queries on

[peetmate]

Fourth new type — WRSI (type=agriculture) — completes the KE-ENSO layer set

One more domain=climate tier live on digital-atlas, not yet catalogued — introduces a new type=agriculture (alongside the type=vegetation + type=flood flagged just above). Convention call for you.

Dataset: FEWS NET / USGS CHIRPS-ETos WRSI (Water Requirement Satisfaction Index) — crop & pasture water balance, CHIRPS v3.0-driven (same backbone as our observational rainfall/SPEI).

domain=climate/type=agriculture/source=fews-wrsi/region=east-africa/
  processing=seasonal/variable=wrsi/crop={cropland|rangeland}/season={MAM|OND}/wrsi_{crop}_{SEASON}_{YYYY}.tif

• Two crop variants — cropland (maize/grain calendar) + rangeland (pastoral/ASAL pasture calendar) — because maize WRSI is meaningless over rangeland. 93 COGs total (cropland 47 + rangeland 46), 2004–2025, seasonal end-of-season.
• 10 km (0.1°), EPSG:4326, WRSI % (0–100), CC-BY-ish USGS public. Non-GEE ingest (USGS wrsi-chirps-etos archive). Small tiles (80×102) → no overviews (sub-tile, renders fine).

Questions (in addition to the type=vegetation/type=flood ones above):

1. type=agriculture OK as a new type under domain=climate? That makes four new types from this KE-ENSO work: vegetation, flood, agriculture (+ existing observational/hazard-indices). Happy to consolidate if you'd prefer a different taxonomy.
2. source=fews-wrsi + crop={cropland|rangeland} partition — reasonable?

This completes the KE-ENSO Explorer layer set (rainfall, SPEI drought, NDVI, flood ×2, WRSI ×2). All CHIRPS v3.0-consistent where precip-driven. Standing CDH full-standard.yaml offer covers this too.