Inspiration

During a disaster, knowing there is a warning is important, but what do you actually do next?

That was the question we started with. We already have weather apps that can tell us there is a flood warning, a hurricane approaching, or dangerous heat, but we wanted to focus on what happens after receiving that warning. Where can I go from my current location? What resources are around me? Does the shortest route take me through the affected area? What happens if I lose connectivity when I actually need this information?

That is where the idea for WayAhead came from. We wanted to build more than another map showing alerts, so we focused on connecting disaster information with real roads, nearby resources, and routing. We chose North Carolina and started with floods, hurricanes, and extreme heat because they create very different problems across the state, which also gave us a chance to see whether one system could adapt to different kinds of disasters.

What it does

WayAhead is a disaster-planning application that takes a user's location and the disaster they are facing, then looks at nearby resources and possible road routes using the hazard information available at that time. One of the main ideas behind the project is that the shortest route is not necessarily the route we want to suggest during a disaster. We keep the shortest route for comparison, evaluate hazard exposure along the road network, and show why the suggested route may be different. Floods, hurricanes, and extreme heat are also handled differently instead of applying the same rule to every warning.

We also wanted WayAhead to remain useful when connectivity becomes unreliable. Users can save supported areas with their map, road network, resources, conditions, and routing data so that previously downloaded information can still be used offline. The current project focuses on Raleigh, Wilmington, and Asheville.

How we built it

We use OpenStreetMap and Overpass for real road networks and mapped facilities, NOAA/NWS for weather alerts and observations, and USGS for water-gauge observations and historical trends. These sources provide very different types of information, so we bring them into a common geospatial workflow before using them for planning.

The routing itself is graph-based. Roads form the network, resources become possible destinations, and hazard information affects the roads that the system evaluates. We compare candidate destinations based on reachability, mapped hazard exposure, and road distance, while keeping the normal shortest route as a baseline that the user can see. Offline support required us to save more than the application interface, so WayAhead also stores vector maps, road graphs, resources, conditions, and the data needed for browser-side routing.

We integrated Gemini for evidence-grounded situation briefings and questions and ElevenLabs for narration and voice interaction. Tiger Data supports time-series observations. We intentionally kept these integrations separate from the core routing decision. AI can help communicate the information, but it does not decide which road to take or calculate hazard risk. Those decisions stay within the deterministic geospatial routing logic.

For the final deployment, we hosted WayAhead on Render and connected it to our custom GoDaddy Registry domain, findawayahead.us. This gave us a publicly accessible version of the project that people can directly try instead of keeping the application limited to a local development environment.

Challenges we ran into

Working with real disaster data was probably the part that changed our thinking the most. An alert may not always have usable geometry. A sensor reading can already be stale even if we just retrieved it. A library or community facility appearing on OpenStreetMap does not suddenly make it an official shelter, and getting no warning from an API does not mean an area is safe. We had to be careful about what each source actually allowed us to say.

Routing created a different set of problems because avoiding a hazard on a map still has to make sense on the actual road network. We had to account for one-way roads, destination access, affected road sections, and situations where there simply may not be a reasonable alternative route.

Offline support became another challenge on its own. Initially, "offline" sounds like a caching problem, but for WayAhead it meant keeping the map, roads, resources, conditions, hazard information, and routing capability available together. That pushed us to think much more carefully about what data had actually been downloaded and whether it was still current enough to use.

Accomplishments that we're proud of

We are proud that WayAhead grew from an idea into a working end-to-end application using real geospatial and disaster data. We were able to bring road networks, nearby resources, weather alerts, sensor observations, hazard-aware routing, and offline support into one system instead of treating them as separate features.

One of our biggest accomplishments was making the routing explainable. WayAhead does not just return a route. It keeps the normal shortest route as a comparison and shows how hazard exposure can change the recommendation, while keeping the actual routing logic deterministic rather than letting an AI model make safety-critical decisions.

We are also proud that we were able to deploy the application publicly at findawayahead.us and integrate Gemini, ElevenLabs, and Tiger Data into the larger workflow while keeping the core routing decisions grounded in geospatial data. We ended with something people can actually open, interact with, and understand.

What we learned

We started with a routing problem, but ended up learning just as much about the data behind the route. Bringing together road graphs, warning polygons, sensor observations, facilities, live updates, and offline geospatial data showed us that freshness, provenance, and uncertainty matter just as much as displaying something correctly on a map.

It also changed how we thought about the interface. During a disaster, giving someone more data is not automatically helpful. We kept coming back to a few simple questions: What is happening around me? What options do I have from where I am? Why is this route being suggested? Keeping those questions in mind helped us decide what information actually belonged in WayAhead.

What's next for WayAhead

Floods, hurricanes, and extreme heat are where we started, but we want WayAhead to eventually support other calamities as well. The idea is not to simply add more disaster names to a menu. Each new hazard would need reliable data sources and its own rules for how it should affect roads, destinations, and resources, while still fitting into the same geospatial planning system.

There is also more we can do with the hazards we already support. Official road-closure feeds, verified real-time shelter and cooling-center availability, and elevation or inundation data could make the recommendations stronger. We would also like to expand beyond our current North Carolina coverage and adapt WayAhead to different regions and the disasters they face. The long-term goal is to keep extending the same approach to more locations and more disasters while staying focused on the question we started with: what can we help someone do next?

Built With

Share this project:

Updates

Submission history