Pathways: Determining the accessibility of fare gates

[npaun]

When providing directions to users, it's important to determine whether or not a certain pathway is accessible to people who use wheelchairs.

When the pathway mode is Stairs or Escalator, it's clear that the pathway is not accessible, but it's not obvious for Fare Gate or Exit Gate -- Ordinary turnstiles are not, but there might a separate gate that can be opened to allow a wheelchair to pass.

Has anyone else encountered this issue or developed a workaround, or should we (Transit) propose some additions to the spec to handle this case?

[barbeau]

@npaun If you take a look a the full GTFS-Pathways proposal: http://bit.ly/gtfs-pathways

...there is a field in pathways.txt called wheelchair_assistance, defined as:

The assistance field indicates if using this pathway requires an additional human assistance.

• 0 or empty: This pathway do not require assistance
• 1: Using this pathway requires assistance from the staff without prior notice (e.g. wheelchair/stroller door near turnstiles, ramp to install)
• 2: Using this pathway requires assistance from staff with prior notice

There is another field wheelchair_assistance_phone that can contain the phone number to call for notice about assistance needs.

There are a few other accessibility-related fields there too.

Please take a look and see if this would meet the use cases you're discussing. I believe the only reason that they haven't been officially adopted into the spec yet is because we're waiting on a producer and consumer.

cc @LeoFrachet

[opyh]

I'm working for Sozialhelden e.V., an NGO that is focused on physical accessibility data. We have been in contact with @LeoFrachet about adding accessibility attributes to GTFS.

We work on A11yJSON, a collection of interface specs that harmonizes existing data formats for physical accessibility worldwide. If necessary, we can extend it with new fields - for this, it would be best if new attribute describe measurable physical facts (e.g. 'the maximal slope is 10%', 'the way is plastered' or 'the elevator has these dimensions and has two doors').

The most interesting existing interfaces in the format are Door, EquipmentProperties (for elevators and stairways), Entrance, Ground, and Stairs.

Ground surfaces are not very detailed in the format yet. For them, it would be good to use something that is not too far from OSM's surface tag.

We also have on our roadmap to GTFS pathways in Wheelmap.org, world’s largest free online map for wheelchair accessible places, so we'd be a consumer of attributes like this. Wheelmap.org already displays exits/entries, elevators and escalators in Germany (for Deutsche Bahn, HVV, KVB, and VBB). For elevators and escalators, we display a real-time operational status.

cc @holgerd @mutaphysis @akii

[LeoFrachet]

Hi Nicolas,

Currently, we have the following fields: min_width and wheelchair_assistance. AFAIK they are the one that the agencies have been using so far. Do you have an example of a use case where those fields are not sufficient?

[npaun]

Hello Leo, it seems that there isn't currently a way to use the wheelchair_assistance field specify that the pathway is entirely inaccessible. The slope and width fields are potentially useful, but are not always conclusive, for instance, even a wide turnstile can be inaccessible.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[gcamp]

The issue is still relevant.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[npaun]

This issue is still relevant.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It may be closed manually after one month of inactivity. Thank you for your contributions.

[npaun]

K33p op3n