Inspiration
This project was inspired by a simple but high-impact problem in everyday city life: the fastest walking route is not always the safest or most accessible route.
We observed the same pattern repeatedly—people choosing routes with broken sidewalks, missing curb ramps, poor lighting, or higher-risk streets simply because traditional map apps optimize for ETA first. For many users, especially people with mobility needs, older adults, and students walking at night, route decisions are not just about speed.
We wanted to build an AI-assisted navigation advocate that helps people make safer, more informed walking decisions with clear tradeoffs and real-world context.
Name: Walkable
What it does
Walkable acts as both a navigator and an accessibility/safety advocate through five core capabilities:
Unified Risk Map: Combines accessibility hazards and crime-risk overlays in one interactive map.
Smart Route Comparison: Returns both safest and fastest routes so users can choose based on context, not just speed.
Destination Preview Assistant: Lets users search and preview destinations before routing.
Accessibility Controls: Supports high-contrast mode, larger text, and safest-first preference behavior.
Hazard Reporting Loop: Allows users to submit new hazards that feed into future map visibility and planning.
How we built it
The system uses a modular architecture for rapid iteration and city-scale expansion:
Frontend: Built with Expo (React Native + web) for a unified cross-platform experience and fast UI iteration.
Backend: Implemented with FastAPI-style endpoints in Python, deployed on Modal for route computation and map data APIs.
Routing Layer: Uses OSMnx + NetworkX to compute walking routes with weighted edge costs.
Risk Layer: Uses H3-based crime risk bucketing and hazard datasets to enrich map context and route scoring.
Data Pipeline: CSV/Parquet processing for hazard/crime inputs and map-serving performance.
Infrastructure: Modal deployment with packaged artifacts and endpoint-based architecture for hazard, crime, route, and reporting flows.
Challenges we ran into
Safety vs. Overclaiming: We had to keep the product as decision support, not a guarantee of safety.
Data Variability: Hazard and crime datasets vary in freshness and quality, requiring validation and fallback logic.
Routing Tradeoffs: Balancing accessibility and safety penalties against ETA required practical score tuning.
Accomplishments that we're proud of
Built a working unified map with hazard + crime overlays.
Delivered safest-vs-fastest routing in one user flow.
Implemented accessibility controls as first-class product features.
Shipped end-to-end hazard reporting to backend APIs.
Deployed and validated live endpoints on Modal for real-time demo readiness.
What we learned
Navigation trust matters as much as navigation speed.
Accessibility must be reflected in both route logic and interface design.
Geospatial apps need graceful degradation and fallback behavior to stay usable in real-world conditions.
What’s next for Walkable
Multi-City Expansion: Launch city adapters (UIUC first, then additional major cities).
Data Freshness Improvements: Add stronger ingestion scheduling, retries, and validation workflows.
Richer Accessibility Modeling: Incorporate deeper curb-ramp/transit constraints and mobility-specific routing profiles.
Privacy & Governance Hardening: Improve auditing, report moderation workflows, and operational safeguards for wider usage.
Log in or sign up for Devpost to join the conversation.