Inspiration

The maps tell you the shortest way to walk. They don't tell you the ramp is blocked, the sidewalk is broken. For someone who is specially challenged it is difficult to use google maps to figure out.

What it does

The app is accessible to anyone who is specially challenged cannot just rely on google maps only. CurbWise shows an accessible route next to the standard walking route. Anyone can report a hazard by tapping its spot on the map and taking a photo. The route then avoids it until the report expires. Directions come out as large text, vibration, and voice.

How we built it

  • Routing: openrouteservice's wheelchair profile on OpenStreetMap data, with slope and kerb limits set per user type
  • Gemini API: reads each hazard photo and returns a structured record (type, severity, a one-line note)
  • ElevenLabs: spoken directions and hazard warnings
  • FastAPI + SQLite backend, MapLibre map
  • Photos are never stored. We keep only a small record, and it expires automatically (12 hours for ice or a blocked ramp, up to 30 days for a broken surface).

Before building, we checked the data. Within 1.5 km of campus, OpenStreetMap has 262 sidewalk segments and 207 tactile paving points, but only 56 kerb points. The sidewalk network is mapped, and curb ramp detail is thin. That gap is what the photo reports fill.

Challenges we ran into

  • Finding usable sidewalk data was the first hurdle. Before building, we measured what OpenStreetMap has near campus: the sidewalk network is well mapped (262 segments), but curb ramp detail is thin (only 56 kerb points). That shaped the whole design, since we couldn't rely on map data alone to know where a wheelchair could actually cross.

  • Getting openrouteservice's wheelchair restrictions to behave. Describe what went wrong, e.g. routes ignoring kerb limits or failing to find any path, and how you fixed it.]

  • Handling photos that don't show a hazard. Describe what Gemini returned for blurry, off-topic, or ambiguous images and how you handled it, e.g. a "no hazard detected" result or a confidence check.]

  • Anything about keeping voice guidance working when ElevenLabs was slow or unavailable, if that came up.

Accomplishments that we're proud of

  • We built guidance that doesn't depend on a single channel: text, vibration, and voice go out together, with the browser's built-in voice as a fallback and a saved-route fallback when the server is unreachable.
  • Privacy by design: photos are never stored, and every report expires automatically.

What we learned

  • Data is the bottleneck since finding a path is easy but knowing it is passable is hard
  • AI works best with a small structured record instead of an open-ended judgment
  • Accessible means different things for a manual wheelchair, a power chair or a stroller
  • Guidance needs fallbacks because silent failure is not an option for someone relying on it

What's next for CurbWise

  • Voice commands, so the app works with no touch at all
  • Sensory-aware routing (noise, crowds, glare) for people with sensory sensitivities
  • Confidence labels: "confirmed," "reported," or "no data" on each stretch
  • Multilingual voice guidance
  • Exporting confirmed hazards back to OpenStreetMap
  • Working alongside tools like AccessNow, which rates venues. CurbWise covers the path between them.

Built With

Share this project:

Updates

Submission history