The methodology

A route is only as useful as the information behind it.

AccessPath makes route choices explainable. It keeps a known barrier, an unknown condition, and a documented pathway separate.

Different paths. Different needs.

The details make
the difference.

Built to help people who walk, roll, use mobility aids or need fewer barriers—not just a shorter line on a map.

A ramp can provide a step-free connection, but its slope, width, surface and current condition still matter. Review the details before guidance starts.

Interactive illustration, not a real pathway or a compliance diagram.

Connected paths. Calculated choices.

We represent a site as a graph: intersections, entrances, ramps, and destinations are nodes; documented paths between them are edges. Each edge records a distance and access information. Dijkstra’s algorithm finds the shortest qualifying connection by adding segment distances. It respects one-way paths and cannot invent a missing connection.

The schematic positions and distances in this demo are synthetic. Distances are calculated from its invented geometry and stored with each edge, rather than measured from screen pixels. They are demonstration values, not field measurements.

Routes between real places.

The real-world planner searches places with Photon and requests walking routes from FOSSGIS’s OSRM foot-routing dataset, both using OpenStreetMap data. Distances, geometry and directions come from the provider; the demonstration graph is not substituted if a request fails.

Wheelchair / mobility access uses a connected wheelchair-routing profile with steps and ferries excluded, requested mapped slope, width, kerb and surface limits, and reviewed obstacle-avoidance areas. Returned paths are also checked against those reviewed areas. Ramps can be included. The provider does not return complete per-segment ramp or missing-data coverage, so the interface does not invent zero counts or offer unsupported complete-data/no-ramp controls. An optional local OSM graph engine supports finer checks when its data service is available. This beta covers endpoints up to 3 km apart; unmapped endpoint gaps and current field conditions remain unverified.

Opt-in foreground GPS guidance shows your moving position and next step, with optional browser speech and controlled off-route recalculation. It is not a replacement for a maintained, field-verified mobility-navigation service. Driving, cycling and bus/transit options open the corresponding Google Maps directions; live transit coverage and vehicle accessibility must be checked with the provider.

These are ordinary walking directions. They can include steps or inaccessible sections. The provider response does not verify slopes, curb ramps, widths, live closures or individual suitability, so AccessPath does not call these routes confirmed step-free. Dashed links between a selected point and a nearby routed street are explicitly labeled un-routed gaps.

Find a real-world walking route

Three ways to ask a different question.

What each route mode includes
ModeRoute questionWhat to watch for
Shortest WalkWhich available path is shortest under the selected preferences?It can contain stairs or other documented barriers. Check the explanation.
Confirmed Step-FreeWhich path meets the documented step-free rules?Incomplete or unverified access records are excluded. Demo records only demonstrate those rules.
Exploratory Step-FreeWhat potential path remains if incomplete information is allowed?Known stairs and blocked paths remain excluded. Unknown details require confirmation before travel.

Strict mode checks the site, endpoints, step-free status, operating status, surface, slope, width, and curb information. Slope and width preferences are product rules, not a legal accessibility assessment or a guarantee of individual suitability.

Unknown never means confirmed.

If no strict route qualifies, AccessPath says so. Choosing an exploratory result is a separate action, and uncertain segments stay visible. The app does not silently substitute a route with missing evidence.

A “demonstration” record is an authored fixture. “Unverified” means review or information is missing. “Verified” describes reviewed attributes and their source, not live conditions or a blanket statement that a route works for everyone.

Reported obstacles start as pending. Moderator approval and a justified operating-status update do not automatically verify a segment’s slope, width, or other access details.

The route exists beyond the map.

Start and destination controls, segment details, and an ordered itinerary provide a text route experience. The map and itinerary use the same calculated sequence. Simulations change a copy of the synthetic graph and are labeled so they cannot be mistaken for a new field report.

A small, honest starting point.

The campus workspace uses fictional data; street planning uses OpenStreetMap with the limits described above. Palos Verdes Peninsula is only a potential campus pilot: no real school paths, observations, partnership, or impact result have been supplied. A real pilot needs permitted measurements, documented review, participant testing, and a process for keeping conditions current.

AccessPath does not replace official site guidance, professional mobility assessments, or emergency instructions. Conditions and individual requirements can extend beyond its recorded fields.

View the evidence record