Wheelchair Accessibility for Trips

[Brian Ferris]

Back in June, we added support for defining the wheelchair accessibility semantics of transit stops and stations in a GTFS feed:

https://groups.google.com/d/topic/gtfs-changes/ASxItgsQlh4/discussion

During that discussion, I put off formally adopting the proposal for defining the wheelchair accessibility of trips, because some felt we didn't have enough agencies using the full proposal to justify adoption.  I think that has changed, so I'd like to revisit the proposal.

As discussed previously (https://groups.google.com/d/topic/gtfs-changes/IzQ-46aeZuM/discussion), the proposal to define the wheelchair accessibility of trips looks like the following:

Introduce the following field in trips.txt:

wheelchair_accessible (optional)

"0" (or empty) - indicates that there is no accessibility information for the trip
"1" - indicates that the vehicle being used on this particular trip can accommodate at least one rider in a wheelchair
"2" - indicates that no riders in wheelchairs can be accommodated on this trip

At this point, a number of public feeds are using the proposed feature.  As a quick example, the RTC Québec feed (http://www.rtcquebec.ca/Donn%C3%A9esouvertes/tabid/460/Default.aspx) uses all three of the different accessibility values to distinguish the accessibility of different trips.  Similarly, the BKK feed from Budapest (http://www.bkk.hu/magunkrol/fejlesztoknek/) also uses all three values.  There are a number of other public feeds supplying tripx.txt wheelchair_accessible field values in some capacity: CTA in Chicago, Metro Transit in Madison, WI, SDMTS in San Diego, TTC in Toronto, etc.

And we've also got a few consumers of the trips.txt accessibility proposal as well.  For example, the OneBusAway GTFS library supports the proposal and the OpenTripPlanner project uses that information to perform wheelchair accessible routing.

I'd like to open this proposal back up to discussion, but first let me summarize some of the previous discussion around this proposal (read the old threads if you are new to the list!) to avoid rehashing some ground that we've already covered:

1) This proposal doesn't explicitly model real-time wheelchair accessibility of a trip.  There has been some discussion of such a feature on the GTFS-realtime list (https://groups.google.com/forum/?fromgroups#!forum/gtfs-realtime).  If you are an agency that wants to publish this data in real-time, the community would love to hear from you.

2) This proposal doesn't cover the case where a transit station is not wheelchair accessible, but wheelchair accessible transfers are possible at the station (see discussion of stops.txt wheelchair_boarding=3 semantics for that).

3) We recognize that agencies all define "accessibility" differently.  This proposal does not attempt to define in explicit detail all the ways that that a trip may or may not be accessible given the regulatory or practical definitions used by a particular agency.  Ultimately, it is judgement call on the part of the agency if they want to indicate that a trip can accomodate a wheelchair.

Based on the resulting discussion around this proposal, I might try to start the clock ticking for adoption sooner rather than later.  But either way, let's hear your comments first : )

Thanks,

Brian

[Koch]

+1

About 3/4th of the Dutch trips include a trip accessiblity field in the Dutch transitformat (Koppelvlak1). I include this in my conversion to GTFS.

Op dinsdag 2 oktober 2012 02:02:37 UTC+2 schreef Brian Ferris het volgende:

[Wojciech Kulesza]

+1 from goEuropa too. Using wheelchair info for both trips and stops

On 8 October 2012 05:04, subarb <sub...@gmail.com> wrote:

+1

We'll be providing wheel_chair accessibility to both realtime and static feed. 

Our feeds will be public very soon. 

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/Pb1N51dREUAJ.

To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[Brian Ferris]

Since I'm only hearing positive things for this proposal, let's start the clock.  If there are no blocking objections by Oct 15 (one week from now), then let's add this to the spec.

Brian

[Brian Ferris]

Hearing no complaints, I've added the trips.txt 'wheelchair_accessible' proposal to the official GTFS reference spec:

https://developers.google.com/transit/gtfs/reference#trips_fields

Thanks to all the agencies who have provided data and developers who have implemented features to make this happen.  I know discussion around this proposal has been ongoing since 2008, and I look forward to seeing what the transit developer community can do when lots of agencies are publishing this data.

Thanks,

Brian

[Eric Burkman]

Sorry to pop this back into the stream of consciousness almost a year after the fact.

I have read through this thread, and am still unresolved about denoting a stop that isn't wheelchair accessible (for example, there are only stairs leading to the stop or there is no curb-cut/ramp nearby). It seems that the change only addresses vehicle accessibility as opposed to physical stop accessibility.

Furthermore, I am curious about the benefit of separately denoting stops serviced by wheelchair-accessible vehicles and also trips performed by wheelchair-accessible vehicles. Can't the data in the stops file regarding stops serviced by accessible vehicles be extrapolated from the trips file field, which indicates that a trip is serviced by an accessible vehicle?

As it stands now, to my understanding, there is no attribute in the GTFS standard for physical stop accessibility data - only vehicle accessibility.

For example, if there were stop accessibility data available in the standard, a trip planner program would know not to suggest a wheelchair passenger board or alight at a stop that is only accessible by stairs - even though the vehicle servicing that stop might have capacity for a wheelchair passenger.

Am I correct in my understanding?

After reading through my post again, it seems to me that there are three things that happen at a stop for a passenger in a wheelchair:
1. stop must be accessible (not addressed by present specification)
2. boarding of a wheelchair passenger must be possible at the stop - ie, appropriate gap from platform to vehicle (addressed in stops.txt wheelchair_boarding)
3. vehicle must be able to accommodate a wheelchair passenger (addressed in trips.txt wheelchair_accessible)

In this case, it seems that a prudent addition could be a wheelchair_access (not wheelchair_accessible for difference between stops.txt and trips.txt accessibility fields) field to stops.txt, with "0/empty" being no info, "1" denoting accessible by wheelchair, and "2" denoting not accessible by wheelchair.

Thanks!
-Eric

[Brian Ferris]

Perhaps the wording of the spec is not clear enough here, but the current semantics of "wheelchair_boarding" captures both the accessibility of the stop and whether accessible boardings are possible at the stop.  A value of "1" implies that it's possible to access the stop from the street in a wheelchair AND board vehicles.  While it's certainly possible to model the two concepts separately, I think it practice it's a reasonable compromise to model them together as accessible riders usually just want to know "can I get from the street to the vehicle at this stop?"

During the proposal discussion, it was noted that a station might allow accessible transfers at the platform but not be accessible from the street  (eg. underground station with no elevators) and it's true that the current spec does not support such situations.  I think it would be natural to model this with an additional enum type for "wheelchair_boarding" if there is some agency who wishes to provide this data.  However, during the discussion, it was noted that the accessibility semantics in such situations could actually be pretty complex.  For example, accessible transfers might be possible at a single platform or between certain pairs of platforms, but not others, depending on the station layout.  At that point, the single enum "wheelchair_boarding" isn't really enough anymore and you either need something like the pathways.txt proposal or full indoor modeling of the station.

Brian

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/9098f63c-fc24-4533-9fe8-d61ace95138a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Fabian V. Thobe]

+1