A hackathon project that combines accessible routing with street-level frontage review so participants can evaluate whether a trip is usable from real origin to real destination, not just from one sidewalk segment to another.
This repo is for teams building:
- an accessible routing layer powered by the AccessMap API
- a frontage visibility layer powered by the Mapillary API
- a barrier identification layer that flags where a route works on the network but may fail at the door, entry, curb, or bus boarding platform
Most trip-planning tools stop too early. They may show that a sidewalk or transit stop is nearby, but they often do not answer the practical question:
Can someone actually get from their true starting point to their true destination in a way that matches their mobility needs?
This project focuses on the gap between:
- the network route on the sidewalk graph, and
- the frontage approach between the sidewalk and the actual entry, boarding pad, or destination access point.
A route can succeed on paper and still fail in reality because of:
- stairs at the entrance
- missing curb ramps
- unclear frontage paths
- inaccessible bus stop landing zones
- obstructions near the final approach
Build a lightweight tool that:
- accepts a start point, end point, and mobility preferences
- requests an accessible route from the AccessMap API
- retrieves nearby street-level imagery from Mapillary around the origin and destination frontages
- presents the route and imagery together
- classifies the trip with a simple label such as:
Origin/destination fully reviewableOrigin/destination accessibleOrigin/destination frontage uncertainOrigin/destination barrier
The application included in this repo achieves the first 4 objectives!
- As a wheelchair user, I want to know whether I can get from my apartment entrance to a grocery entrance.
- As a rider using transit, I want to know whether I can get from my home door to a bus stop boarding zone.
- As a planner, I want to identify locations where the route works on the map but fails in the frontage zone.
- As an advocate, I want to show why a route line alone is not enough to represent accessibility.
TBD
For this hackathon, use the shortest path custom routing endpoint:
GET https://www.accessmap.app/api/v1/routing/shortest_path/custom.jsonlon1— origin longitudelat1— origin latitudelon2— destination longitudelat2— destination latitude
uphill— maximum tolerated uphill incline percentagedownhill— maximum tolerated downhill incline percentageavoidCurbs—0or1streetAvoidance—0.0to1.0avoidPrimaryStreet—0or1timestamp— epoch timestamp for time-restricted routing cases
GET https://www.accessmap.app/api/v1/routing/shortest_path/custom.json?lon1=-121.914971&lat1=47.647018&lon2=-121.913763&lat2=47.6485371&uphill=0.05&downhill=0.099&avoidCurbs=1&streetAvoidance=1Ok— route foundInvalidWaypoint— origin and/or destination are not close enough to a traversable pathNoPath— valid points, but no route available under the chosen constraintsNoGraph— server-side graph error
AccessMap gives us the network-level accessibility answer. It tells us whether the route can be traversed on the modeled pedestrian graph under the user's mobility constraints.
What it does not fully answer is whether the frontage approach to the real door, stop pad, or entrance is usable. That is where Mapillary helps.
Mapillary is the imagery side of this project.
Use it to:
- find street-level images near the start frontage
- find street-level images near the destination frontage
- inspect curb edges, sidewalk-to-entry transitions, frontage walkways, and boarding contexts
- optionally display imagery in a custom viewer experience
- Create a Mapillary account.
- Open the developer dashboard and register an application.
- Copy the Client Token from the dashboard.
- Store it in your local
.envfile asMAPILLARY_CLIENT_TOKEN.
For this project, the Client Token is usually enough for read access to the API.
A strong MVP for the hackathon should:
- let the user click a start point and destination
- allow a small set of mobility constraints
- request and draw the AccessMap route
- fetch 3–10 Mapillary images near each endpoint
- show imagery beside the route
- produce a simple classification label
- explain uncertainty in plain language
- add bus stop specific workflows
- add a confidence score
- rank imagery by approach direction
- support reviewer annotations
- export a review as JSON or GeoJSON
See docs/API_REFERENCE.md for:
- AccessMap endpoint details
- Mapillary API