Global open datasets have quietly become good enough that a competent developer can build a defensible local flood-exposure map without a research budget. That is worth knowing, and so is the boundary where such a map stops being trustworthy. This piece covers both, in enough detail that you can decide whether the week is worth spending.
What is freely available
- Digital elevation models covering most of the world at usable resolution, typically tens of metres per pixel, with better products available for some areas.
- Open street and building footprint data, which is unusually good in many South Asian towns thanks to volunteer mapping after past disasters.
- Historical rainfall estimates and satellite-derived surface water observations going back decades.
- Census and settlement rasters that estimate where people live at a grid level, which is often more useful than administrative totals.
- Administrative boundaries down to ward level, which is the unit local decisions are actually made in.
The important caveat on elevation is what the model is measuring. Most freely available global elevation data is a surface model, meaning it includes buildings and tree canopy rather than bare ground. In a dense settlement or under forest, that inflates the apparent height of the ground and makes low-lying areas look safer than they are. There are corrected bare-earth products derived from these sources, and they are worth seeking out, because this single distinction accounts for a large share of the errors in amateur flood maps.
What you can legitimately produce
Combining elevation with settlement data gives a low-lying exposure map: which built-up areas sit in the parts of a floodplain that fill first. Overlaying observed historical inundation gives a second, independent view. Where the two agree, you have something worth showing to a ward office.
The most useful single derived measure is height above nearest drainage, which for each point is the vertical distance to the nearest stream channel rather than the elevation above sea level. It is a much better proxy for exposure than raw elevation, because it accounts for the fact that a point ten metres above a river is safer than a point at the same absolute altitude sitting in a side valley. It is computable from a DEM with standard open tools, and it produces maps that local residents recognise immediately, which is the practical test.
- A ranked list of wards or settlements by the share of built-up area in the lowest exposure band.
- An overlay of historical satellite-observed water extent, which shows where water has actually been rather than where terrain suggests it might go.
- A count of critical facilities, schools, health posts, water points, substations, that sit in the exposed band.
- A map of access rather than assets: which roads and bridges are the single link to a settlement, since losing one isolates everyone behind it.
That last one is frequently the most valuable output and the one nobody asks for. In Nepal's hill districts, the thing that turns a flood into a multi-week crisis is usually not the water reaching houses but a bridge going and a district losing its only road. Identifying those links is straightforward from open road data and takes an afternoon.
What you cannot honestly claim
This is exposure mapping, not hydraulic modelling. It does not tell you depth, velocity, timing, or the effect of an embankment built last year. Presenting a terrain-derived map as a flood forecast is the kind of overreach that discredits the whole approach, and it is easy to do accidentally by choosing a confident colour scheme.
Some specific things terrain analysis cannot see. It cannot see culverts, drains and pumps, so an urban area that floods because its drainage is blocked will look fine. It cannot see embankments and river training works, particularly recent ones, so the terrain may describe a river that no longer exists in that alignment. It cannot see debris flows, which in steep headwater valleys are the dominant hazard and behave nothing like water, a point covered in why the Bhote Koshi valleys keep flooding. And it cannot see sediment, which raises riverbeds year on year and quietly changes where the water goes.
Label the uncertainty on the map itself, because the map will outlive the caveats in your email.
How to do it in a week without misleading anyone
The workflow is short and the discipline is in the documentation. Clip a bare-earth DEM to your area of interest. Compute drainage and height above nearest drainage. Band the result into three or four exposure classes rather than a continuous gradient, because a gradient implies a precision you do not have. Intersect with building footprints and settlement raster to get exposed population and structures. Overlay historical observed water extent as a separate, independently sourced layer. Then look at where the two disagree, because that is where the interesting questions are.
- Use three or four discrete bands, not a smooth colour ramp, and name them in plain language rather than as probabilities.
- Keep every input layer separate and re-runnable, so a corrected DEM does not mean rebuilding the project.
- Record the date and source of every input on the map itself.
- Version the processing steps in a script, not in a sequence of manual clicks in a desktop GIS.
That last point is what makes the difference between an output and an asset. A scripted pipeline can be re-run when a better DEM appears or when a ward boundary changes, and it can be handed to somebody else. A map produced by forty manual operations is finished the day it is made. This is ordinary data engineering discipline applied to geospatial work, and it costs nothing extra if you do it from the start.
Ground truth changes everything
One afternoon walking a neighbourhood with residents who remember where the water reached will correct more errors than a week of processing. Local memory is data. Collect it structurally: photographs with coordinates, marked high-water lines, dates where people are confident.
Do it properly and it becomes a reusable dataset rather than a set of notes. Record the coordinate, the observed height above ground, the year, the confidence the person expresses, and who reported it. Photograph the mark with something of known height in frame. Note explicitly where accounts conflict rather than averaging them, because a disagreement between two residents about how far the water came usually means the two events were different, and that is information. A small collection of these points is enough to validate or reject the terrain-derived bands, which is the only external check most of these maps will ever get.
Publishing responsibly
Say what the map is derived from, when the inputs were captured, and who to contact about an error. Provide the underlying layers so someone better resourced can improve on it. A risk map that cannot be checked is an opinion with coordinates.
There is also a question of consequence worth thinking through before publishing. Exposure maps affect land values, insurance and municipal decisions, and a map that is wrong in either direction causes harm: too cautious and it devalues land unnecessarily, too relaxed and it reassures people who should be moving. That is an argument for the discrete bands, the plain-language labels and the visible caveats, not an argument against publishing. The same reasoning applies to any public dataset, and it is one of the reasons open crash reporting is harder than it looks, as discussed in Nepal's road crash data problem.
Finally, know what the map is for. It is a prioritisation tool for people making decisions with limited budgets, and it should be delivered alongside the warning question rather than confused with it. What terrain data cannot do is tell anyone when to move, which is the job of the sensing and dissemination chain described in how flood early-warning systems work. Keep the two clearly separate and both are more useful. Where the money for either one comes from, and why so many of these projects die in year three, is covered in climate tech in South Asia.
Abishek Bimali
Founder & Engineer
Abishek founded SiteCraft Innovation and leads its engineering. He writes about building web and mobile products that hold up in production, for teams in Nepal and abroad.



