-
-
dashboard
The problem
For logistics teams, the shortest route is not always the route with the lowest historical flood exposure. Dispatchers need to see the distance trade-off clearly before choosing a route.
SiltWay is a flood-aware logistics dispatch console for Kogi. It compares a standard shortest-distance route with a weighted resilient route and reports the kilometres of each route that cross mapped historical flood zones.
Based on 2012 satellite flood extents and a recent rainfall index. Avoids mapped flood zones. Not live flood conditions.
What inspired us
We wanted to build a practical tool for a real dispatch decision:
"If the resilient route avoids historically flooded road, how much extra distance does it require?"
Rather than claiming that a route is safe or predicting live flooding, SiltWay keeps the decision grounded in observable historical data. It shows what the route data contains and makes the trade-off visible.
How we built it
SiltWay uses a weighted road network. Each road segment receives a cost based on its length, historical flood exposure, and rainfall index:
w(e) = L(e) × (1 + α·F(e) + β·R(e))
Where:
L(e)is road length in kilometresF(e)is the fraction of the segment intersecting mapped 2012 flood zonesR(e)is the configured rainfall indexαandβare configurable weights
The backend is built with Python, FastAPI, NetworkX, GeoPandas, Shapely, NumPy, SciPy, and Pydantic.
The frontend is a responsive React and TypeScript dispatch console. It includes:
- Config-driven routing presets
- Standard and resilient route comparison
- Historical flood layer
- Road network layer
- Flooded route stretches with kilometres
- Recommendation banners based on API response data
- Wet-season and dry-season date options
- Batch CSV routing
- Shareable route links
- Route guidance based on mapped route geometry
- Optional browser location tracking and rerouting
- An evidence page that reads the reproducible evaluation results
What we learned
The most important part of a data product is not only the algorithm. It is also communicating uncertainty and boundaries clearly.
We learned to:
- Keep thresholds, weights, dates, presets, caps, and region settings in configuration
- Test general invariants instead of testing only named locations
- Separate historical flood exposure from live flood conditions
- Show both the benefit and the distance trade-off
- Avoid inventing road names, travel times, fuel usage, or cost
- Make evaluation evidence available inside the product
- Handle failed batch rows independently instead of failing the entire request
Evaluation
The evaluation uses 200 seeded origin-destination pairs in Kogi.
For the configured default setting, the 2012 in-sample evaluation shows:
- 6.16% total reduction in flood kilometres
- 7.00% mean pair flood-kilometre reduction
- 0.18% extra distance on affected pairs
The held-out 2022 result is also shown in the evidence page. It demonstrates why historical route exposure should not be described as a live flood prediction. In the held-out evaluation, the resilient route has higher flood exposure than the baseline, which is an important limitation rather than something to hide.
Challenges
- Working with imperfect geospatial data. Road geometries required cleaning, snapping, topology processing, and conversion into a connected graph.
- Keeping the project honest. It was tempting to add familiar navigation claims such as safety, arrival time, or live flood status. We deliberately avoided those claims because the available data cannot support them.
- Avoiding hard-coded examples. The configuration controls the pilot region, presets, route thresholds, dates, road classes, feature caps, and evaluation settings. The frontend renders values served by the API instead of embedding region-specific assumptions.
- Making results understandable. A technical route score is not enough for a dispatcher. The console therefore shows standard and resilient routes together, reports kilometres directly, explains the recommendation, and links the UI to the evaluation evidence.
What is next
Future work could add richer road metadata, improved turn instruction generation, additional regions, live data integrations, and more detailed operational workflows. These would require new data sources and validation. SiltWay intentionally keeps the current product limited to the evidence supported by its historical datasets.
