尚未检测到更新。GitHub 发布版本后会显示在这里。
个人 GitHub 账号下公开仓库的所有者可以登录并验证所有权,自行管理介绍,无需管理员批准。
登录并生成验证文件,在 30 分钟内将其提交到此仓库的默认分支。其他分支或分叉仓库中的文件无效。然后在下方检查文件,即可无需管理员批准直接管理项目。请保留文件以维持管理权限。
如需登录,将前往登录页面。登录后请回到此处,再次点击所选的验证按钮。
在项目文件夹中运行 /nomorevibe verify,即可验证所有权并自行管理介绍。
一分钟完成验证Energy Disruption Monitor: an open-source, admin-region-level dashboard of publicly reported energy-infrastructure degradation in Belarus, western Russia, Siberia and Crimea (2022-present). Static Vite+MapLibre frontend, stdlib-only Python ETL, daily refresh.
翻译准备中
取自仓库 README
正在加载完整 README。 以下为已保存的摘录。
Energy Disruption Monitor — Western Russia, Siberia & Belarus
An open-source-only dashboard tracking publicly reported degradation of energy
infrastructure across Belarus, western Russia and the Siberian Federal District,
aggregated to administrative region (80 monitored units, Crimea included), from 2022 to the present.
Every number traces to a public source. Where the data does not support a number, the
dashboard says so rather than estimating one. Observed facts, external estimates and
modelled assumptions are kept visibly distinct throughout.查看完整 README ↗An open-source-only dashboard tracking publicly reported degradation of energy infrastructure across Belarus, western Russia and the Siberian Federal District, aggregated to administrative region (80 monitored units, Crimea included), from 2022 to the present.
Every number traces to a public source. Where the data does not support a number, the dashboard says so rather than estimating one. Observed facts, external estimates and modelled assumptions are kept visibly distinct throughout.
Crimea is shown as a separately identified occupied unit — internationally recognised as Ukraine, under Russian occupation, distinct styling and status. Since iteration 4 it contributes to the headline Monitored-Area index (through the sectors where it has qualifying events and a compatible denominator) while never being labelled a Russian region. Surrounding countries and the Black Sea are drawn as display-only context.
Status: iterations 1–12 shipped. For every live figure — as-of date, headline index, sector exposures, coverage ratio, event and recovery counts — see docs/CURRENT_STATE.md, which is regenerated by the build and checked by a test. This README deliberately quotes none of them: it used to, and the numbers here went two iterations stale while the claim "this README quotes no live number" sat a few lines below them.
The newest write-up is the highest-numbered
docs/ITERATION_N_REVIEW.md; a test fails the build if the pointers in this file,CLAUDE.mdanddocs/HANDOFF.mdfall behind it.
Live site: https://russian-energy-dashboard.vercel.app · Deployment: static
Vite + MapLibre on Vercel, rebuilt daily by a GitHub Action; push-to-main auto-deploys.
Zero external runtime requests. See docs/DEPLOYMENT.md. Run locally:
.venv\Scripts\python.exe -m pipeline.run then cd web && ..\scripts\npm.cmd run dev.
The headline figure is the Energy System Disruption Exposure Index (ESDI). It answers one question:
What share of the tracked installed base sits at facilities disrupted recently enough to still be plausibly impaired, weighted by evidence strength, cause, and time elapsed?
It is not a measurement of lost throughput or lost generation. Open reporting almost never states how much capacity a given event removed. Of the 175 region-assigned events currently in the dataset, zero carry a quantified capacity effect — and the dashboard shows that ratio in its top ribbon rather than burying it. An exposure measure is what this data can honestly support; a "capacity offline" figure is not.
This is a damage-assessment and monitoring tool. It models publicly reported disruption to energy infrastructure, aggregated to administrative region. It contains no current unit positions, no readiness state, no vulnerability or defensive-gap assessment, and no ranking of undamaged assets.
One upstream source (the Wikipedia strike table) publishes a "distance from
Ukrainian-controlled territory" column for each facility. The parser deliberately does
not read it. It describes reach rather than damage, contributes nothing to a
degradation assessment, and is the one field in that table with obvious
operational-planning value. tests/test_pipeline.py fails the build if any
range-to-target field ever appears in emitted data.
data/curated/*.csv ──┐
Natural Earth ───────┤
WRI Power Plant DB ──┼──► pipeline/ (Python 3.13, stdlib only) ──► data/processed/*.json
OpenStreetMap ───────┤ │
Wikipedia ───────────┘ │
web/public/data/ (mirrored)
│
web/ (Vite + React + TS + MapLibre)
│
Vercel (static)
Three deliberate choices:
No database. The dataset is ~1,980 assets (plus a curated infrastructure supplement) and ~175 events. Static JSON regenerated by a scheduled job is the backend. A Postgres instance here would be infrastructure to maintain in exchange for nothing.
No basemap. The map renders our own GeoJSON on a flat dark ground. Every tile provider worth using needs an API key, a billing relationship, or an attribution banner, and streets and terrain add nothing underneath an administrative choropleth. The deployed page therefore makes zero external network requests and works offline.
Stdlib-only ETL. No pandas, geopandas, shapely or requests. Point-in-polygon, Douglas–Peucker simplification and Wikitext parsing are each a few dozen readable lines. The GitHub Action needs no build toolchain and cannot break on a wheel that stops publishing for Python 3.13.
Requires Python 3.13 and Node 24. Node is vendored under tools/node/ (gitignored) and
reached through scripts/node.cmd / scripts/npm.cmd, so nothing touches PATH.
python -m venv .venv
.venv\Scripts\python.exe -m pip install pytest
Build the dataset — this downloads from Natural Earth, WRI, Overpass and Wikipedia, and
caches everything under data/raw/ (gitignored):
.venv\Scripts\python.exe -m pipeline.run
Run the dashboard:
cd web && ..\scripts\npm.cmd install && ..\scripts\npm.cmd run dev
Run the tests:
.venv\Scripts\python.exe -m pytest
| Stage | Location | Committed? |
|---|---|---|
| Raw downloads | data/raw/ | No — large, regenerable, third-party licensed |
| Analyst-curated events | data/curated/incidents.csv | Yes — this is source truth |
| Scoring parameters | methodology/scoring.json | Yes |
| Processed output | data/processed/ | Yes — so Vercel can serve it without running Python |
| Frontend copy | web/public/data/ | Yes — mirrored by the pipeline |
data/processed/ is a build artifact that is nonetheless committed, because Vercel
builds only the frontend. A clean rebuild is deterministic given the same upstream
sources. Never hand-edit processed JSON; fix the curated source and rebuild.
| Layer | Source | Licence |
|---|---|---|
| Administrative boundaries | Natural Earth 10m admin-1 | Public domain |
| Generation (MW, fuel, location) | WRI Global Power Plant Database v1.3 | CC BY 4.0 |
| Substations, transmission, pipelines | OpenStreetMap via Overpass | ODbL |
| Strike events, refinery capacities | English Wikipedia | CC BY-SA 4.0 |
| Everything else | data/curated/incidents.csv | Per-row source URLs |
Full detail and per-source caveats: docs/SOURCES.md.
Repair is no longer a flat half-life. Each disrupted facility's decay is driven by the strongest available evidence, and the kind travels with every number:
Confirmed reconstitution collapses a facility's contribution. Recovery evidence lives in
data/curated/recovery.csv (source required per row). The dashboard's Recovery tab
shows unresolved counts, median observed restoration (with sample size), impairment age,
and the observed/estimated/modelled mix.
The four analytic concepts — exposure, assessed degradation (quantified only), recovery, and confidence/coverage — are kept structurally distinct in the data and across the seven-tab analytical panel (Overview · Rankings · Recent · Recovery · Effects · Repair burden · Sources).
Live counts (coverage %, episodes, ESDI, tests) are generated into docs/CURRENT_STATE.md every build and drift-guarded by a test — this README quotes no live number.
methodology/scoring.json.These are expanded in docs/ITERATION_1_REVIEW.md.