v0.12.3: one interface module per step

No method changes: results are identical to 0.12.2.

Changed

• The interface code is split into one file per step (#5). js/main.js (2,089 lines) is now a short entry point, and each step's interface is in its own module in js/ui/ (for example area.js for step 1 and flood.js for step 5), next to shared modules for state, formatting and the map. The code was moved, not rewritten. A full run of steps 1 to 8 on a test area produced an identical export package before and after (all 68 files, including maps and charts), and the interactive features (drawing, probe, layers, 3D, GLOF marks, exports, search) were checked for errors.

v0.12.2: correct colours in exported maps

No method changes: results are identical to 0.12.1.

Fixed

• Exported maps with wrong colours in some browsers. In Firefox on Linux, the map image in the PNG layouts could come out with red and blue swapped (blue flood depths and waterways shown orange, orange roads shown blue), while the legend stayed correct. Spotted in the Hebden Bridge test export (#1). The map is now read from the graphics card in a fixed colour order, so exports look the same in every browser.

v0.12.1: licence changed to AGPL-3.0

No method changes: results are identical to 0.12.0.

Changed

• Licence changed from MIT to the GNU Affero General Public License v3.0 (AGPL-3.0-only). OpenHVRA stays free to use, copy, modify and share, including for commercial work, but anyone who shares a changed version, or runs one on a website or server for other people, must make its source code available under the same licence. Versions up to 0.12.0 remain available under MIT. Data licences (OpenStreetMap ODbL, GEM CC BY-NC-SA 4.0, Copernicus DEM) are unchanged.

v0.12.0: Copernicus DEM GLO-30 elevation

Method change: elevation data (flood, exposure and multi-hazard results differ from 0.11.x)

• Copernicus DEM GLO-30 is now the default elevation source (#9). It is one consistent 30 m global model, read straight from its files on Microsoft Planetary Computer; only the parts covering the area are downloaded. Previously the AWS Terrain Tiles were used, which are SRTM (from 2000) in most of the world and national data in some countries.
• Choose the elevation source in step 1: Copernicus DEM GLO-30 or AWS Terrain Tiles. With Terrain Tiles, results are identical to 0.11.2.
• If Copernicus can't be downloaded, the app uses the Terrain Tiles automatically and says so.
• The search for the river bed next to each waterway and the slope calculation now use one data cell (about 30 m) on Copernicus, matching its native spacing. GLOF outflow tracing and lake elevations use Copernicus at about 60 m over the wider area around glacial lakes.
• Every export records the elevation source, grid spacing and files used (parameters.csv), and the credits include the Copernicus attribution.
• Validation: in a narrow, wooded valley town where the Terrain Tiles are built on national LiDAR, Copernicus found 71% of the buildings in the official 1-in-100-year flood zone at the default 3 m water level, against 90% with the Terrain Tiles. See #9 and the README section Elevation data.

OpenHVRA v0.11.2 (beta): faster OpenStreetMap downloads

No method changes: results are identical to 0.11.1.

Changed

• Faster, more reliable OpenStreetMap downloads. Previously the app waited up to 120 seconds on an unresponsive Overpass server before trying the next, so a load could take about 3 minutes when a server was overloaded. Now each request starts on the server that has worked best recently (remembered in the browser), asks the next server as well if there is no answer within 30 seconds or straight away if one fails, and uses the first complete answer, cancelling the rest. When a server reports it is busy, the app reads when the next free slot is and waits that long before retrying. In tests on two 21 km² areas, loading took 38–39 s instead of 167–176 s.

---

Live app: https://gomalhunzai.github.io/openhvra/
Full history: CHANGELOG.md

🤖 Generated with Claude Code

OpenHVRA v0.11.1 (beta): population total source, year and guidance

No method changes: results are identical to 0.11.0.

Added

• Source and year of the known population in step 2 (census, WorldPop, GHSL, local survey or other), recorded in parameters.csv, the summary and the calibration note (#8).
• "Where to find a population total" guide in step 2: national census, WorldPop Global2 (2015–2030) and GHSL GHS-POP, with how to sum a gridded estimate inside the area in QGIS. An automatic WorldPop lookup was not added: WorldPop's statistics service only covers 2000–2020 and, like its newer files, cannot be read from a web page (no CORS).
• The full package now always includes layers/area.geojson; when the map view was used as the area, it is the view's rectangle.

---

Live app: https://gomalhunzai.github.io/openhvra/
Full history: CHANGELOG.md

🤖 Generated with Claude Code

OpenHVRA v0.11.0 (beta): building costs by country and region

Method change: building costs (flood losses differ from 0.10.x)

• Building costs are now set for your area instead of one global placeholder (previously 250 per m² for homes, labelled US dollars, with 30% contents, for every country). Including contents, that single value was about 3 times too high in some of the poorest countries (for example Afghanistan and Bhutan) and 7–10 times too low in Western Europe and North America. Choose the source in step 5:
  • GEM Global Exposure Model 2026 (default): replacement cost per m² for the country and, where available, the province or state (215 countries, 3,557 regions), by residential, commercial and industrial use, with GEM's contents values. Homes with a mapped building:material are adjusted by GEM's cost for that construction type (earth/adobe/stone, brick or block, reinforced masonry, concrete, steel, wood). Data licence CC BY-NC-SA 4.0.
  • JRC formula with the latest World Bank GDP per capita: the JRC flood damage study's construction-cost regressions (Huizinga et al. 2017), applied to current GDP per capita and brought to current US dollars; contents 50/100/150% as in that study.
  • Your own values, in any currency.
• Contents are set per building class instead of one percentage.
• Every export records the cost source, region, construction-type factors and citation; buildings.csv adds each building's construction type.

---

Live app: https://gomalhunzai.github.io/openhvra/
Full history: CHANGELOG.md

🤖 Generated with Claude Code

OpenHVRA v0.10.2 (beta): automated tests, CI, self-hosted font and map library

No method changes: results are identical to 0.10.1.

Added

• Automated tests of the core calculations (node --test, nothing to install): damage curves, building loss, average annual loss, loss at any return period, risk-finance layers, multi-hazard index, combined risk, risk matrix, social vulnerability classes and geometry, checked against hand-worked values (#2).
• Tests run automatically on every push and pull request with GitHub Actions, with a syntax check of every script (#3).

Changed

• The Inter font and MapLibre 4.7.1 are now served from this site instead of Google Fonts and jsDelivr: visitors' IP addresses are no longer sent to Google when the app opens, and the app no longer depends on an outside server to load. Files were checked against the npm registry's integrity hashes (#4).

---

Live app: https://gomalhunzai.github.io/openhvra/
Full history: CHANGELOG.md

🤖 Generated with Claude Code

OpenHVRA v0.10.1 (beta): 3D view

No method changes: results are identical to 0.10.0.

Added

• 3D view (button on the map): 3D terrain from the open elevation tiles with hillshade and an exaggeration slider (1–3×, true scale by default); buildings extruded to their real height (storeys × 3 m; Light-mode points as blocks sized from their estimated footprint), coloured by the active layer (multi-hazard/risk, social vulnerability, flood depth or exposure); all other layers drape over the terrain. Exported maps stay flat and north-up.

---

Live app: https://gomalhunzai.github.io/openhvra/
Full history: CHANGELOG.md

🤖 Generated with Claude Code

OpenHVRA v0.10.0 (beta): GLOF by traced outflow paths

Method change: GLOF (results differ from 0.9.x)

• Lakes now count only if their water can reach the area. Each glacial lake's outflow is traced downstream: along OSM waterways (which are drawn in the direction of flow), joining at confluences and bridging gaps up to 60 m; by steepest descent on regional elevation where no stream is mapped; or along a path drawn by the user. Only lakes whose path passes through the analysed area are used. Previously any lake within 30 km and 100 m higher counted, which produced false positives from neighbouring valleys.
• Homes are scored along the path, not by distance to the lake: flood height (default 20 m at the lake, falling to 5 m at 30 km; both adjustable) minus the home's height above the path, within 600 m of the path.

Added

• Glacier outlines, glacial lakes and traced outflow paths on the map (new "Glaciers, lakes & GLOF paths" layer), a lake table in step 7 (area, elevation, how the path was traced, whether it reaches the area) and lake tooltips.
• Mark lake (point or outline), Mark glacier (also searches OSM for lakes near it) and Draw path for any lake, with delete and download of your marks as GeoJSON.
• GLOF map export shows glaciers, lakes and paths; the ZIP adds layers/glaciers.geojson, layers/glof_outflow_paths.geojson and lake reach details.

---

Live app: https://gomalhunzai.github.io/openhvra/
Full history: CHANGELOG.md

🤖 Generated with Claude Code