MUSTANG MOBILITY
Accessibility-first campus navigation


Navigating a university campus isn't just about distance—it's about access. Google Maps routes to random entrances, leaving wheelchair users to manually find accessible entry points. Accessibility PDFs require decoding a complex multi-page map. Neither supports real campus needs: multiple destinations, entrance-level constraints, or building hours
Buildings aren’t single points.
Accessibility depends on which entrance you use. Modeling each building as a single node hides critical constraints and leads to unusable “shortest paths.”


SIXTY PERCENT
of disabled students experience fatigue simply trying to get around campus—often without sufficient institutional support.
THE SOLUTION
Model the campus as a graph where each building has multiple entrance nodes, each with its own accessibility metadata. Built in C++, Python, and JavaScript (HTML/CSS + Mapbox GL JS) with a Flask backend, routes are computed using Dijkstra's algorithm, selecting the most accessible entrance–exit combination at every step.
Users can:
Select multiple buildings
Filter for wheelchair-accessible entrances
View entrance images, building hours, and closing warnings




THE PROBLEM
INSIGHT
CORE SYSTEM DESIGN
Graph-based model spanning 105 buildings, 200+ entrance nodes, and 5,000+ edges
Python Flask REST API serving route data to a JavaScript/Mapbox frontend — full client-server architecture
Dijkstra’s algorithm for reliable, constraint-aware routing
Adapter pattern to decouple graph storage from algo and UI
Singleton graph instance to ensure consistency and performance
Google Test/Mock for unit and integration testing — caught 4+ edge cases pre-deployment
This structure made the system scalable, debuggable, and realistic.


CHALLENGES → SOLUTIONS
Campus data only existed as a static PDF → manually digitized 200+ entrance coordinates into structured CSVs, validated and cleaned before routing
Missing nodes in Dijkstra's adjacency list caused broken paths → defensive checks + refactored edge models
Buildings have multiple entrances with different accessibility → Dijkstra evaluates every entrance combination per route leg, always picking the most accessible pair
Mapbox layer filtering didn't support dynamic constraints → custom event-driven filtering + real-time marker updates
Each challenge reinforced that real-world systems are messy.
KEY ENGINEERING DECISIONS
Why Dijkstra (not Prim’s):
1
2
Why multiple entrance nodes:
3
Why testing mattered:
The problem wasn’t “connect everything cheaply,” but “find reliable, accessible paths between chosen destinations.”
Modeling that included every entrance in all buildings enabled meaningful accessibility decisions instead of theoretical shortest paths.
Using Google Test / Mock surfaced 4+ edge cases early—missing nodes, broken adjacency links, and invalid paths.
Separating the C++ routing engine from the Flask API and JavaScript frontend meant the algorithm could scale independently — and the UI could evolve without touching core routing logic.
Why a client-server split:
4
Good abstractions matter more than clever algorithms
Edge cases are product cases
Designing for accessibility improves system quality overall
WHAT I LEARNED
WHAT I'D DO NEXT
Add elevation/slope and indoor routing
Expand to surrounding London routes
Introduce user feedback loops for accessibility data





