Inspiration
After an earthquake, a road on a map may be blocked, damaged, or simply unverified. We focused on Anamizu, Japan, and asked: how can a response team understand not only which route a system suggests, but also what reports shaped that suggestion?
What it does
RoutePulse is a route-planning exercise for uncertain road conditions. It uses an OpenStreetMap road network and lets users record road reports such as open, blocked, or suspected. The routing algorithm calculates a candidate route using roads marked open. Users can also ask plain-language questions such as “Which roads need checking?” and “Why did the route change?”
The project includes a scripted seven-day scenario so teams can explore how new reports may change candidate routes over time. These observations are simulated, not live incident reports or satellite analysis.
How we built it
We built a FastAPI backend with SQLite to store road reports, scenario state, route history, and version changes. A shared Python algorithm handles route calculation and question parsing. The project also includes an OpenStreetMap road graph and a seven-day scenario dataset for Anamizu.
What we learned and what was challenging
We learned that map geometry and road condition are different kinds of information. OpenStreetMap can show where a road is, but it cannot confirm whether that road is passable after an earthquake. RoutePulse therefore keeps unknown and conflicting reports visible instead of treating missing information as proof that a road is open.
One challenge was matching the road graph with the seven-day scenario data. Their graph versions and road IDs must line up before daily playback can work reliably. Backend playback is still being connected to the prepared scenario package.
RoutePulse is a prototype for practice and discussion. Its map coverage still needs review, and its candidate routes are not verified for real-world emergency navigation.
