Why this project exists
Flood Atlas Nepal began after the 26 August 2026 Bhote Koshi-Trishuli flash flood. The information people needed was available, but it was distributed across ministry bulletins, emergency-service pages, hydrology systems, news reporting, community channels, and place names that required local context.
From the United States, I kept answering the same questions for friends: What is the latest official update? Is this screenshot current? Where is this place? Which number should someone call? I wanted one link that could answer those questions without requiring another explanation from me.
The product problem was not a lack of information. It was the work required to find, verify, date, and understand that information together.
One page for the first decisions
I reorganized the experience around the reader's questions instead of the structure of the publishing agencies. The first sequence shows warning availability, rescue and flood-information numbers, place search, and a dated government briefing. Relevant reporting and deeper evidence follow after those immediate paths.
This ordering is especially important on a phone. A person should not need to load a map or interpret a dashboard before finding an official action or understanding when an update was published.
Keeping different evidence honest
Bringing information into one page does not mean flattening it into one status. Government briefings remain official publications. News remains reporting. Forecast guidance remains separate from observed rainfall. Terrain and satellite imagery provide context, not a warning or a safe-route recommendation.
The interface keeps the publisher, original source, publication or observation time, retrieval time, and evidence state close to each claim. Missing information stays unavailable. An empty feed or absent warning never becomes proof that a place is safe.
Engineering for unreliable upstream systems
I built the public pages to read from validated local records instead of waiting for government or news services during a visitor request. Scheduled collectors support government bulletins, relevant English and Nepali reporting, and rainfall forecast snapshots. Reviewed source contracts preserve publisher identity, original URLs, timestamps, place context, and validity windows.
When collection fails, the last valid snapshot remains available with a delayed state. Preview and production snapshots are isolated, partial scheduled refreshes fail visibly, and stale data can recover through a request-time fallback. Essential warnings, contacts, source links, and summaries render on the server before optional maps or client JavaScript.
What is live, and what is not
The live product brings a dated government briefing, urgent official contacts, reviewed place search, relevant reporting, source health, and supporting evidence into one starting point. English and Nepali routes make that starting point useful across local and diaspora contexts, but localization supports the larger goal rather than defining it.
Some categories remain intentionally incomplete. A reviewed station-level river-gauge parser and road-notice parser are not connected. Those pages keep the gap visible and link to the responsible official source. The terrain view explains geography, but it is not a flood simulation, risk map, or route-safety tool.
What the work changed
The main product decision was restraint. An earlier concept made the river corridor the dominant first-screen visual. The final experience gives urgent text, official actions, and dated context priority, then lets readers move into geography and evidence when they need more depth.
The result is not a claim to be the official source. It is an independent, source-traceable layer that reduces the work of moving between scattered systems while making the authority and limits of each piece of information easier to inspect.
