Expanded options for accessibility of walking routes

[Thomas Craig]

Hopelink in Western Washington, United States, is developing a new program finder (trip planner with additional user account features) for transit services in the Puget Sound region. The intention of this project is to provide transportation options for every user with a focus on ensuring accessible options for riders with disabilities.

Providing more accessible walking routing is a priority for this project, which will launch next year using OpenTripPlanner. Over time, Hopelink would like to see updates in OpenTripPlanner that would allow the program finder meet more rider needs. To this end, myself (Thomas Craig of Washington State Department of Transportation) and Anat Caspi (of the Taskar Center at University of Washington), who are both on Hopelink's technical advisory committee, met with Leonard Ehrenfried recently to discuss his recent work on accessible routing in OTP (presented at the recent OTP version 2.2 release webinar). We discussed where routing in OTP stands next to the types of routing options offered by accessmap.io which is based on data in the OpenSidewalks specification, and whether improved walking accessibility options are feasible within OTP.

The outcomes of the conversation were

• meeting the specific user needs for accessible routing identified by the Taskar Center in past research should be feasible.
• significant effort would need to be applied to update the manner in which OTP imports OSM data; the cost of traversing various edges in the pedestrian network would need to be variable based on inputs from the user.
• specific variable costing approaches would need to be implemented for scalability (ie, it would not be feasible to design a "core OTP" API endpoint that allowed frontends to apply arbitrarily defined costing algorithms for the purposes of research, because such a feature would not be scalable)

We would like to continue this conversation first by asking whether others in the OTP community 1) are interested in this development 2) have any comments, suggestions, or corrections regarding the above.

There would also be interest in applying for funding for this development through various means, so understanding the technical scale of this effort would be useful. If any developer is interested and thinks it appropriate, the near term roadmap for this effort potentially could be broken into github issues which could help clarify the needs and costs between different organizations that want to see these features implemented.

[Thomas Gran]

Hi Thomas,

• specific variable costing approaches would need to be implemented for scalability (ie, it would not be feasible to design a "core OTP" API endpoint that allowed frontends to apply arbitrarily defined costing algorithms for the purposes of research, because such a feature would not be scalable)

I am not 100% sure what you want, but take a look at the DataOverlay . It does allow for clients to pass in arbitrarily defined costing algorithms (thresholds and penalty per variable). Even if the data overlay was implemented for "air quality" routing, it is generic, so supporting accessible routing is a matter of importing data into the data overlay.  

Thomas