Wheelchair accessibility

63 views
Skip to first unread message

David Turner

unread,
Dec 21, 2009, 12:52:00 PM12/21/09
to gtfs-c...@googlegroups.com
I am pleased to announce that Open Trip Planner
(http://www.opentripplanner.org) now implements the wheelchair
accessibility proposal from:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f8fa7c4cc8430

Brian Ferris and I added the feature last week, and have tested it with
dummy data. We did not implement accessible-with-notes.

Do we also need to provide or locate actual data to make this change
official? If so, does anyone have actual data? I do have actual data
for all NYC buses (they're all accessible), but have not had the time to
put it into the GTFS yet.

Joe Hughes

unread,
Dec 21, 2009, 2:27:43 PM12/21/09
to Google Transit Feed Spec Changes
David,

Great! Thanks so much for helping to test this this proposal. In
order to get to the point where someone can nominate this for
inclusion in the spec, we need to have an end-to-end test with a real
app (yours!) and real data.

Agency folks, have any of you implemented this proposal in your
feeds? In a quick check, I haven't found any that conform to that
proposal yet. TriMet and Chicago have an "accessible" (rather than
"wheelchair_boarding") field in stops.txt, but no corresponding
"wheelchair_accessible" field in trips.txt. San Diego MTS comes the
closest--they have a "wheelchair_accessible" field in trips.txt, but
the field in stops.txt is also "accessible".

Joe

On Dec 21, 9:52 am, David Turner <nova...@novalis.org> wrote:
> I am pleased to announce that Open Trip Planner
> (http://www.opentripplanner.org) now implements the wheelchair

> accessibility proposal from:http://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f...

Devin Braun

unread,
Dec 21, 2009, 2:51:13 PM12/21/09
to Google Transit Feed Spec Changes
The most recent version of the MTS feed at
http://www.gtfs-data-exchange.com/gtfs/mts_20091214_1941.zip has
"wheelchair_boarding" field in stops.txt and "wheelchair_accessible"
field in trips.txt. We updated our feed based on the original
proposal by Joe, not on the other suggestions, so if you need
something different, feel free to ask.

Devin Braun
San Diego MTS

> > put it into the GTFS yet.- Hide quoted text -
>
> - Show quoted text -

David Turner

unread,
Dec 21, 2009, 3:02:01 PM12/21/09
to gtfs-c...@googlegroups.com
Can you give me some test start/end points on this data, so we can check
that OTP produces reasonable results?

> --
>
> You received this message because you are subscribed to the Google Groups "Google Transit Feed Spec Changes" group.
> 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.
>
>

Joe Hughes

unread,
Dec 21, 2009, 4:39:12 PM12/21/09
to Google Transit Feed Spec Changes
Thanks, Devin. It's also good (for the purposes of testing, at
least), that you have some stops for which wheelchair_boarding is 0,
as it'll help test handling of that situation.

Does anyone here have trips which you would mark as not accessible? A
full test would ideally also include some data where there's a mix of
accessible and not-accessible trips.

Joe

David Turner

unread,
Dec 22, 2009, 5:34:36 PM12/22/09
to GTFS-changes
I have attached the JSON output of OTP for each of these trips. Also a
screenshot of the accessible trip from 11th and C.

I have confirmed that, in the case of the trip from 11th and C, a
different route is generated when an accessible trip is requested, and
in the case of Broadway and Kettner, a different route is *not*
generated.

If you like, I can place the graph that I have generated of the San
Diego area from the MTS data and OpenStreetMap online for you to play
with. While you could just generate the graph yourself, I would not
recommend it, as it took me several hours and 3 GB of RAM, since we have
not yet optimized this part of OTP. Unfortunately, we do not yet have a
test instance of OpenTripPlanner, but we expect to put up a few
(Portland OR, New York, and then whatever we're playing with) in the
coming months. We also welcome feedback from people playing with OTP on
their own -- but don't expect the mailing list or IRC channel to be real
active around the holidays.

On Mon, 2009-12-21 at 13:01 -0800, Devin Braun wrote:
> Broadway & Kettner Blvd., San Diego to Mission Blvd. & Garnet Ave., San
> Diego
> 11th Ave. & C St., San Diego to S. Marshall Ave. & W. Palm Ave., El
> Cajon, CA
> Genesee Ave. & Linda Vista Rd., San Diego to Gilman Dr. & Myers Dr., San
> Diego (UCSD)
> Jamacha Blvd. & Calavo Dr., San Diego County to College Ave. &
> Streamview Dr., San Diego
> Lindo Paseo & College Ave., San Diego to Spring St. & Allison Ave., La
> Mesa, CA
> 30th Ave. & University Ave., San Diego to Fashion Valley Rd. & Friars
> Rd., San Diego
> Park Blvd. & University Ave., San Diego to University Ave. & 69th St.,
> San Diego
> Naples St. & Melrose Ave., Chula Vista, CA to Palm Ave. & Seacoast Dr.,
> Imperial Beach, CA
>
> I have also attached a random queries file if that helps.
>
> Devin

san-diego-wheel.json
11th.png

KevinChicago

unread,
Dec 30, 2009, 12:56:30 PM12/30/09
to Google Transit Feed Spec Changes
A new feed for Chicago has been posted (www.transitchicago.com/
downloads/sch_data/) that has "wheelchair_boarding" field in stops.txt

and "wheelchair_accessible" field in trips.txt.

Additionally, as a side note, last year I made mention that some urban
rail systems, particularly the subways or elevated, may have a need
for wheelchair accessibility to be coded in the transfers.txt file.
This would be because there are cases where a wheelchair could make a
transfer from one stop_id to another even though the stop_ids, from
the street level, are not accessible to wheelchairs. This used to be
the case here in Chicago, but fortunately is not anymore. It probably
does exist in other cities, so I just wanted to keep the idea alive in
this thread.

Kevin

David Turner

unread,
Jan 26, 2010, 6:41:38 PM1/26/10
to gtfs-c...@googlegroups.com, Open Trip Planner Dev
On Wed, 2009-12-30 at 09:56 -0800, KevinChicago wrote:
> Additionally, as a side note, last year I made mention that some urban
> rail systems, particularly the subways or elevated, may have a need
> for wheelchair accessibility to be coded in the transfers.txt file.
> This would be because there are cases where a wheelchair could make a
> transfer from one stop_id to another even though the stop_ids, from
> the street level, are not accessible to wheelchairs. This used to be
> the case here in Chicago, but fortunately is not anymore. It probably
> does exist in other cities, so I just wanted to keep the idea alive in
> this thread.

In New York, there are trips which require a transfer at a stop which is
not accessible from street level. Consider[1] a trip from 8th St
(accessible) on the N to Prospect Park on the Q (accessible). The
directions ought to be: take the N to Canal St, then get off and get on
the next Q train on the same platform. OpenTripPlanner, at present,
does not allow alighting at non-accessible stations, and Q01 (the N/Q
platform at Canal St) cannot be accessed from the street by wheelchair.

This is slightly different than the Chicago case, because the two trains
are on the exact same platform. I guess one could encode this as two
stop_ids with an accessible transfer between them, but it would be
confusing, and the feed validator would complain about it.

In Philadelphia, on the regional rail, it is possible to imagine
similar, although I think there are none in reality. For example, a R5
express from 30th St Station (accessible) to Bryn Mawr (not even a
little bit accessible), then a local to Berwyn (accessible). The
problem is that, unlike Canal St, you can't actually get a wheelchair on
or off the train at Bryn Mawr, because there's three giant steps down
from the train to the platform.

So I think wheelchair_boarding needs to have another possible value: 2,
meaning that a wheelchair can alight from the vehicle but not reach the
street. This is fully orthogonal to any changes to transfers.txt.

I will implement this proposal in OpenTripPlanner provisionally, and I
will request that the MTA implement it for New York City (presently,
they have no accessibility or transfer information).

[1] This example may soon be wrong due to service pattern changes, but
there are other examples.


tompw

unread,
Jan 27, 2010, 12:01:21 PM1/27/10
to General Transit Feed Spec Changes
Are you saying that "wheelchair users can board here" and "wheelchair
users can change here" should be seperate things in GTFS?

On Jan 26, 6:41 pm, David Turner <nova...@novalis.org> wrote:
> On Wed, 2009-12-30 at 09:56 -0800, KevinChicago wrote:

...

David Turner

unread,
Jan 27, 2010, 12:56:19 PM1/27/10
to gtfs-c...@googlegroups.com
Yes, for a very specific definition of "change" -- that is, change to
another trip at the same GTFS stop. This is distinct from a GTFS
transfer, which goes between two stops.

This is a distinction that OpenTripPlanner (and presumably Google
Transit) actually needs in order to correctly plan accessible trips.

KevinChicago

unread,
Jan 28, 2010, 9:59:12 AM1/28/10
to General Transit Feed Spec Changes
David's right about this.
My specifc idea was about using the transfers.txt file was to denote
accessibility between two different GTFS stops. For transfers at the
same stop_id, I was mistakenly assuming that a transfer between two
accessible trips (meaning the vehicles are accessible) would
automatically be implied by trip planners to be accessible. My
mistake is thinking of the accessiblity of the stop_id as a being
mostly a characteristc of the access TO the stop_id from "outside" the
transit network, i.e., the street/pedestrian network. And I was
primarily thinking of rail stations, where there either are ramps or
elevators that allow access for wheelchairs into the station. I was
not putting enough thought into whether the stop_id doesn't allow
boarding or alighting a vehicle via a wheelchair, because of some
physical issue with the stop_id, not necessarily something to do with
the vehicle themselves. So it is theoretically possible that a
stop_id is not wheelchair accessible for getting to the stop_id from
the "outside" but it is accessible for boarding/alighting the
vehicle. And this may not just be a rail thing. There may be buses
that have stops that are on overpasses or below grade that are
perfectly fine for wheelchair boarding/alighting the vehcile, just no
wheelchair access to get to/from the stop_id.

So accessiblity in GTFS could be.
trips.txt (accessibility of the vehicle)
stops.txt (accessibility of the stop to board an accessible vehicle
AND accessiblity to reach the stop_id from the "outside")
transfers.txt (to allow accessibility between two stop_ids--if not
coded here then what is in the stops.txt file governs).
and..
[proposed] some future entrances.txt file (to manage access points to
stop_ids from "outside" the network.)

Kevin

> > > platform at Canal St) cannot be accessed from the street by wheelchair.- Hide quoted text -

Reply all
Reply to author
Forward
0 new messages