Navigation simulation (to show some of the other cool features we built along with this).
Pick anywhere in the GTA by searching up an address, or by placing a pin on the map
Select from a Variety of Routes, all built to ensure users get to their destination safely

Inspiration

This idea came from putting our previous project/internship experience together to create something impactful. Specifically, one of our group members spent an entire internship creating and improving websites to make them more accessible.

We also all knew someone who needed accessibility services, so this hit home for all of us. Being able to create a product to help those close to us was a main motivator for creating this.

What it does

ClearPath plans Toronto trips for people who use manual or power wheelchairs, scooters, walkers, canes, or may have limited stamina.

It plans an accessible street route that avoids stairs, using a profile tuned to your mobility.
We show the route a normal map would suggest side by side, so you can see what it would have cost you (stairs, a broken elevator, a risky stretch).
Every subway and LRT stop is matched against the TTC's list of stations with elevators and the live alerts feed. Wheelchair users are never shown a trip that depends on a station without a working elevator.
A model trained on years of City of Toronto 311 reports and weather forecasts where accessibility complaints (uncleared snow, ice, damaged sidewalks and curbs) are likely in the next few days. Routes can detour around high-risk areas, and those areas are always labelled as likely, never as confirmed.
Turn-by-turn directions with alerts ahead for barriers, City road restrictions, TTC elevator outages and forecast risk, plus automatic rerouting. -Riders can mark a spot as blocked or clear. Once two different riders confirm a spot, routing avoids it.
For the October 26, 2026 municipal election, every one of Toronto's 25 wards gets a nonpartisan report card built from City 311 data, live TTC elevator status, active closures and the forecast. Each number links to its source, and a plain-language summary is written by Gemini (with a template fallback).

How we built it

Frontend: React, TypeScript and Vite, with MapLibre GL on OpenFreeMap tiles. Also has full keyboard and screen reader support.
Backend: FastAPI, Postgres with PostGIS and TimescaleDB.
Routing: OpenRouteService wheelchair and walking profiles, with verified barriers sent as avoidance polygons. Transit trips come from Transitous and are checked against TTC station data and live alerts.
ML pipeline: Cleaned Toronto's 311 history, hand-picked the request types that block people with mobility needs, geocoded requests by matching their intersection street names to the City's centreline intersections, and grouped them into hexagonal zones (about 0.7 km² each). model predicts the chance of an accessibility report in each cell over the next 3 days, using past report history plus weather (snowfall, snow on the ground, freeze-thaw days).
Live predictions: Toronto publishes 311 data monthly, so the newest reports can be about 40 days old. Our live model only uses reports older than 40 days, paired with the Open-Meteo forecast, so it works the same way in production as it did in testing.
AI summaries: Gemini writes each ward's "In plain words" summary from the ward's numbers only. If Gemini mentions any number not in its input, or the call fails, we fall back to a template so the card never shows an invented figure.

Challenges we ran into

Initially, accesible routes would fail near big buildings and on park paths. he fix was to try again from points 40, 120 and 300 m along the typical route. The last stretch is shown as an orange dotted "not confirmed" line instead of failing.
The City road-closures feed was invalid JSON. It contains stray backslashes, so a pattern now cleans them up before reading it.
Wards slow to open (2 to 24 s). Gemini's free tier allows only 20 requests a day per model. Summaries are now generated ahead of time, and the live data feeds load in the background.
Automatic rerouting would only work with a new route, making it to stop working after one failiure. To fix this we created a function onReroute to report whether a new route was found. On failure it clears the flag, resets the off-route count, and waits 20 s before trying again.

Accomplishments that we're proud of

Being able to set up our model, as well as having our backend to frontend pipeline working flawlessly
Creating a product that could definitely help thousands of people in Toronto
Being able to set up live navigation with audio directions being played out as well.

What we learned

Learned how to create/manipulate geographical data
Learned how GPS systems work.

What's next for ClearPath

Hopefully we can add community video audits to report curb cuts and obstructions from a phone walk, so a user would be able to take a video of their surroundings, and we'd update the potential blockages as a result.