PathWise

Inspiration

While delay, missed connections, inconsistent information might occur in everyday journey, our schedule could get interrupted. In our case, we target users as people whom may have different needs when they get to work. Commuters need timely and realistic source to help them organize route to cooperate with urgent incidents.

Inspired by that, our team decide to design an application, helping user receive a quickly response route organization with several options, we value travel time over pure distance, taking factors that affect travel stability into consideration, let user choose one planned for them that meet their current need.

What it does

The application is designed to support multiple transport modes and to present routing results in interactive map interface. The current system includes four route modules:

Drive
Walk
Public Transport
Combined Transit + Walk

The project made to help user receive route results quickly, while also incorporating traffic conditions, weather summaries and route interaction features. It is designed around the following goals:

Provide multiple transport modes
Use real Sydney road and transport network data rather than synthetic maps
Estimate travel time more realistically than pure geometric shortest path
Return results quickly enough for interactive use
Keep the architecture flexible so that more advanced features can be added later

How we built it

We built the project as a client-server web application prototype. The backend is responsible for routing logic, graph loading, geocoding, traffic modeling, public transport requests, weather summaries, and structured route responses. The frontend displays the map, sends route requests, and visualizes the returned results in a user-friendly way.

The road and walking networks are modeled as graphs built from real Sydney map data. In this graph structure, nodes represent road or path points, and edges represent road or walking segments. This allows the project to treat route planning as a network optimization problem and use pathfinding algorithms for different goals, such as shortest distance or fastest estimated travel time.

For local road and walking routes, we used A* search because the graph has geographic coordinates. A* can use straight-line distance to the destination as a guide, which helps reduce unnecessary search and keeps route calculation more efficient.

A key part of the project is the traffic-aware driving model. The available NSW traffic dataset contains traffic count information rather than direct speed measurements, so we treat it as a traffic demand proxy. The model cleans the data, builds station-level hourly profiles, compares current traffic intensity with typical baseline levels, and converts that ratio into a travel time multiplier. The influence of a traffic station becomes weaker as the distance from the road segment increases.

The driving time estimate combines several factors: baseline road travel time, fallback speed by road class, road-type adjustment, junction delay, and the traffic multiplier. This is intended to make the fastest route more realistic than simply choosing the geometrically shortest route.

For public transport, the project relies on official journey planning data instead of trying to reconstruct transit routing from the road graph. This is important because public transport depends on timetables, route variants, transfers, stop sequences, and service timing. The returned journeys are parsed into readable steps, and transfer points are displayed on the route where possible.

We also designed route-aware weather logic. Instead of only showing the weather at the starting point, the route is sampled at several points. For each sample point, the system estimates when the user would arrive there and checks the forecast for that location and time. This allows the app to produce a more useful weather summary for the actual journey.

To keep the app responsive, the system includes fallback logic. If exact route calculation or external API calls are too slow, the system can return an approximate route rather than leaving the user with no result. The goal is to balance accuracy with usability.

Challenges we ran into

One big challenge is at current state our data can’t fulfill all our needs, for example the traffic model we used introduce station-level profile to indicate whether current traffic demand at that place and time is above or below that station’s level, for better approach we need direct travel segment speed data, and more real-time data, not just hourly profile constructed based on historical datasets. While those data is currently unavailable and there’s no better approximation.

Other limitation:

Public transport fallback routes are approximate when live API calls are slow
Walking first-load performance may still be affected by graph size
Weather along route is based on forecast sampling rather than dense continuous simulation
Approximate fallback routes are intended for responsiveness, not for final navigation precision

Accomplishments that we're proud of

Our approach is intentionally practical. We aimed to use available data responsibly, make routing more realistic than pure shortest path, and keep the system responsive enough for live interaction. Although there is still room for refinement, we believe the current design provides a clear and useful foundation for further development.

To be specific:

We value travel time over travel distance
We consider other factors may affect on journeys’ stability: weather/ intensity/ number of transfers, and are precise to specific region
We design a function could set walking distant restriction for route calculation

What we learned

We learned how route planning becomes much more complex when it moves from a simple shortest path problem to a realistic city travel problem. Distance alone is not enough. Travel time depends on road type, traffic, intersections, public transport schedules, walking distance, and user preferences.

We also learned the importance of understanding what a dataset actually measures. The NSW traffic count data was useful, but it did not directly represent speed. This taught us to be careful with assumptions and to design a model that matches the meaning of the data.

The project also helped us understand graph modeling, A* search, multimodal routing, and map-based user interaction. Most importantly, we learned that engineering is often about trade-offs: accuracy, speed, data availability, and user experience all need to be balanced.

What's next for Untitled

The next step is to improve the accuracy of the travel time model by calibrating it with observed speed or travel time datasets. This would make the fastest driving route more reliable and reduce the need for conservative assumptions.

We would also like to improve first-load performance by using prebuilt local subgraphs or more efficient graph storage. This would make the app feel faster from the first interaction.

For public transport, future work could refine the fallback logic and support more advanced multimodal optimization. We would also like to add a time-of-departure option, so users can plan trips for a specific future time instead of only using the current context.