Nepal's mountain highways, mixed traffic and long night-bus routes make road safety a standing national concern. Anyone who has followed the coverage knows the rhythm: an incident on a hill road, a round of statements, a committee, and then quiet until the next one. What rarely appears in that cycle is a shared, current dataset that everyone is arguing from.
This matters more than it sounds. Without a common record, every road safety argument becomes a contest of anecdotes, and the interventions that get funded are the ones with the most recent headline behind them rather than the ones with the most crashes behind them. A district engineer deciding where to spend a limited barrier budget is doing it on memory and local knowledge. Sometimes that is right. There is no way to check.
Why the numbers are hard to use
Crash information in Nepal is produced by several bodies at once. Traffic police record incidents, hospitals record injuries, road authorities record the state of the road, and insurers record claims. Each collects what it needs for its own job, on its own schedule, in its own format. None of that is unusual, and none of it is malicious. It simply means no single record describes a crash completely.
- Location is often written as a place name rather than a coordinate, so the same bend appears under several spellings.
- Severity is classified differently by police and by hospitals, so counts diverge.
- Follow-up outcomes are rarely linked back to the original record, so a serious injury that becomes a death weeks later may never update the original entry.
- Publication lags mean the freshest usable figures can be a year or more old.
- Records are frequently held as scanned paper or as spreadsheets that were never designed to be joined to anything else.
The location problem is worth dwelling on, because it defeats almost every analysis anyone wants to run. A crash reported at a village name, a chainage marker, a bridge and a local landmark are four different strings describing the same 200 metres of road. Nepali place names transliterate into Latin script inconsistently, the same name occurs in multiple districts, and highway chainage is renumbered when alignments change. Until a crash carries a coordinate, you cannot ask the one question that matters most, which is whether this bend has done this before.
What a usable dataset actually looks like
The goal is not a dashboard. The goal is a record clean enough that a district engineer can ask which kilometre of which road keeps producing the same kind of crash, and get an answer in an afternoon. That requires a small number of unglamorous things: a stable identifier per incident, coordinates instead of place names, a fixed severity vocabulary shared across agencies, and a documented schema that does not change silently between years.
- A stable incident ID that every agency quotes, so records can be joined later even if they are captured separately.
- Latitude and longitude captured at the scene, with an accuracy figure attached rather than implied.
- A controlled vocabulary for severity, vehicle type, road condition, light and weather, published as a codebook.
- Timestamps for both the incident and the record's creation, because the gap between them is itself useful information.
- A defined correction path, so an agency can amend a record without destroying the original.
A dataset that only its owner can read is a filing cabinet with extra steps.
The codebook is the piece most projects skip and most projects need. If police severity codes and hospital triage categories are never mapped to each other, nobody can reconcile the two sources, and the reconciliation is where the useful findings live. Writing that mapping down is a week of careful work by people who understand both sides. It is also the artefact that survives staff turnover, which is the real reason to produce it.
The engineering is the easy part
Technically this is a modest system: a form that works offline on a phone at a checkpoint, a queue that syncs when there is signal, a validation layer that rejects impossible entries, and an export that anyone can download. Teams in Nepal build harder things routinely. The hard part is the agreement between agencies about who owns which field and who is allowed to correct a record.
The field constraints are real but familiar. The capture device will be a mid-range Android phone, possibly shared between officers on a shift. Data connectivity at a highway post is intermittent, so every entry must be written locally first and synced opportunistically, with conflict handling that does not silently discard the older copy. GPS in a gorge takes time to settle, so the form should record the fix accuracy and allow a later correction rather than blocking submission. Battery is finite, so the app should not hold a GPS lock while the form is open. These are ordinary mobile engineering problems with well-understood answers, which is exactly why the failure is never technical.
Who has to agree before any of this works
Data governance sounds like a bureaucratic word for a technical problem. It is the opposite: the technical problem is small and the governance problem is the project. Before a line of code is useful, someone has to settle who is the authoritative source for each field, who may amend a record after it is filed, how long records are retained, what is published openly and what is withheld, and which body is accountable when the published figures are wrong.
There is a privacy dimension that is easy to get wrong in both directions. A crash record contains personal information: names, vehicle registrations, injuries. Publishing that raw would be indefensible. Publishing nothing, on the grounds that some fields are sensitive, is the more common failure and it is also wrong. The workable answer is a two-tier release: a full record available to the agencies that need it under an access agreement, and a public extract with identifying fields removed and location generalised only where genuinely necessary. Coordinates on a public highway do not identify a person; a name does.
Where private teams can genuinely help
- Build the offline-first capture tool, which is a well-understood problem with no research risk.
- Publish open, well-documented converters between the formats agencies already use, so nobody has to change systems on day one.
- Run the geocoding pass that turns place names into coordinates, and publish the ambiguous cases rather than guessing them.
- Keep the analysis reproducible, so findings can be checked rather than trusted.
- Maintain the codebook and the schema as versioned, public documents.
The reproducibility point is not academic pedantry. If a finding says a particular stretch of highway produces a disproportionate share of night-time crashes, the people who would have to spend money on it are entitled to re-run the analysis themselves. Publishing the query alongside the conclusion is what turns an analysis into evidence. It also means the next team does not start from zero, which in this field they almost always do.
What the data would let you build afterwards
Once locations are reliable, several things become possible that are currently guesswork. Ranking road segments by crash density per vehicle kilometre rather than by raw count. Checking whether a completed intervention, a barrier, a rumble strip, a speed change, actually shifted the numbers on that segment. Identifying the specific crash types that dominate a corridor, since the fix for head-on collisions on a straight is not the fix for run-offs on a bend. Feeding verified incident locations into a driver-facing alert channel, which is the subject of designing a highway incident alert system for Nepali conditions.
It also connects to the emergency side. A dispatcher who can see that a reported crash is at a known black spot with a known nearest hospital is working with better information than one reading a landmark description over the phone, a problem covered in what an emergency response app for Nepal actually needs. The same location discipline underlies both, which is a good argument for doing it once and properly.
Start small and publish early
The temptation with a national dataset is to design the whole schema first and launch nothing for two years. A better route is one corridor, one agency, a published codebook and a monthly open extract, however incomplete. An imperfect dataset that people use gets corrected. A perfect one that is still in committee does not exist. The same logic applies to the internal reporting tools built on top: the useful ones are narrow, and the pattern is described in internal dashboards people actually use.
The point of the exercise
Better data does not by itself fix a blind corner or an overloaded bus. It changes which corner gets fixed first, and it lets the public see whether the fix worked. That is a modest claim, and it is the honest one.
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.
