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

  1. Good abstractions matter more than clever algorithms

  2. Edge cases are product cases

  3. Designing for accessibility improves system quality overall

WHAT I LEARNED
WHAT I'D DO NEXT
  1. Add elevation/slope and indoor routing

  2. Expand to surrounding London routes

  3. Introduce user feedback loops for accessibility data