Proposal: simple wheelchair accessibility (extended)
Igor Kulkin
Add a way to indicate which stops and trips are wheelchair-accessible.
This is an update of an earlier proposal:
https://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f8fa7c4cc8430?pli=1
The main difference is that we allows to distinguish between cases
when there is no information on whether the stop/trip is accessible
and when it's explicitly not accessible.
More discussion on the topic here:
https://groups.google.com/group/gtfs-changes/browse_thread/thread/6caaadd2e1ec9b65?pli=1.
Motivation:
People of limited mobility are a particularly important segment of
transit ridership, and it can sometimes be difficult to determine
whether a transit trip will be possible when traveling in a wheelchair
or motorized scooter. We would like to be able to express (1) whether
a given transit journey can be completed by a person in a wheelchair,
and (2) whether a stop generally supports loading a rider in a
wheelchair onto the vehicle, so that client applications can display a
basic indication that the stop is accessible.
As we did some investigation on adding the support of accessibility to
Google Maps we discovered that it makes sense to distinguish between a
stop being inaccessible and it's accessibility not being defined (or
being unknown).
That could be useful to be able to warn the user if the stop is
inaccessible (while we may not want to do that if we're not sure).
Also when there is no fully accessible trip client applications may
want to fall back to using stops/trips with unknown accessibility
status while still avoiding explicitly inaccessible trips.
Specifying accessibility to be unknown/undefined may also make sense
for aggregated feeds or for cases when a particular trip may sometimes
be accessible, but it's not guaranteed.
Proposal:
This proposal is mostly backwards-compatible with an earlier proposal
(https://groups.google.com/group/gtfs-changes/browse_thread/thread/
f98f8fa7c4cc8430?pli=1).
Introduce two fields, which interact with each other:
First, a field in the trips.txt file:
"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
Second, a field in stops.txt:
"wheelchair_boarding" (optional)
"0" (or empty) - indicates that there is no accessibility
information for the stop
"1" - indicates that at least some vehicles at this stop can be
boarded by a rider in a
wheelchair
"2" - wheelchair boarding is not possible at this stop
A transit journey constructed using this information can only be
considered wheelchair-accessible if all of the boardings and
alightings occur at points on trips at which both the trip's
"wheelchair_accessible" and the stop's "wheelchair_boarding" fields
are set to "1". When browsing stops, it is reasonable to indicate to
the user that a stop is accessible at a basic level if its
"wheelchair_boarding" value is set to "1".
Discussion:
It would be nice to hear opinions on whether you consider this
extension of the original proposal to be useful or if there are any
concerns about it.
Thanks,
Igor Kulkin
Google
Mike Gilligan
Mike Gilligan
TriMet, Portland
On Feb 25, 2:27 pm, Igor Kulkin <igor.kul...@gmail.com> wrote:
> Summary:
> Add a way to indicate which stops and trips are wheelchair-accessible.
>
> This is an update of an earlier proposal:https://groups.google.com/group/gtfs-changes/browse_thread/thread/f98...
> The main difference is that we allows to distinguish between cases
> when there is no information on whether the stop/trip is accessible
> and when it's explicitly not accessible.
>
> More discussion on the topic here:https://groups.google.com/group/gtfs-changes/browse_thread/thread/6ca....
David Turner
discussed here:
http://groups.google.com/group/gtfs-changes/msg/07ec5f48059f9346
It would, I think, be fine if implemented with the entrances/exits
proposal, but I think it is a mistake to introduce that dependency.
Joe Hughes
Do we have any transit agencies here who have stations/stops that fall
into these "not accessible" and "accessible for transfers only" cases
that are being proposed, who can help test these values to see if they
make sense practice?
Thanks,
Joe Hughes
Google
On Feb 26, 10:28 am, David Turner <nova...@novalis.org> wrote:
> This does not account for the Canal Street platform Q01, which I
> discussed here:
>
> http://groups.google.com/group/gtfs-changes/msg/07ec5f48059f9346
>
> It would, I think, be fine if implemented with the entrances/exits
> proposal, but I think it is a mistake to introduce that dependency.
>
> On Thu, 2010-02-25 at 14:27 -0800, Igor Kulkin wrote:
> > Summary:
> > Add a way to indicate which stops and trips are wheelchair-accessible.
>
> > This is an update of an earlier proposal:
> >https://groups.google.com/group/gtfs-changes/browse_thread/thread/f98...
> > The main difference is that we allows to distinguish between cases
> > when there is no information on whether the stop/trip is accessible
> > and when it's explicitly not accessible.
>
> > More discussion on the topic here:
> >https://groups.google.com/group/gtfs-changes/browse_thread/thread/6ca....
T Sobota
accessibility as either being fully compliant with all pertinent ADA
standards (i.e. boarding surface dimensions, sidewalk widths, ramp
slopes, etc.); versus a stop's present infrastructure perhaps not
achieving all current benchmarks - but otherwise generally perceived
as usable for many mobility-challenged riders? In the above example,
"1" would equate to a stop with less than full ADA accessibility
infrastructure (but not officialy deemed inaccessible under US Federal
- or other localized - standards), while "2" would indicate full
compliance with all regulatory guidelines for accessibility - and "3"
would become the case where the agency has officially deemed the stop
as not accessible under any circumstances.
The same added value could probably be carried over to vehicle/trip
accessibility, although I cannot think of a particularly compelling
example right now to illustrate such standardization (i.e. maybe an
older model subway car has a door width that no longer met current
standards?)
Tim Sobota
Metro Transit
> > > Google- Hide quoted text -
>
> - Show quoted text -
Igor Kulkin
transfers and not accessible from the street level:
I think it makes sense to treat a stop to be accessible for a transfer
if its 'wheelchair_boarding' property is set to "1" (at least it
doesn't contradict the definition of the value). Seems like we do need
a way to specify whether a stop is accessible from the street level.
This should probably be modeled with entrances/exits. An exit could
then be marked as either accessible or not.
Can someone else comment on whether there are other examples of
stations with similar problem.
Regarding the ability to distinguish between station being accessible
and being fully ADA compliant:
There are several concerns about that. First of all different
countries can have different accessibility requirements and it doesn't
seem right to have a value dedicated specifically to ADA. Second, it's
not completely clear how the clients of GTFS can use this additional
value.
David Turner
> Regarding the issue of having stations suitable for accessible
> transfers and not accessible from the street level:
>
> I think it makes sense to treat a stop to be accessible for a transfer
> if its 'wheelchair_boarding' property is set to "1" (at least it
> doesn't contradict the definition of the value). Seems like we do need
> a way to specify whether a stop is accessible from the street level.
> This should probably be modeled with entrances/exits. An exit could
> then be marked as either accessible or not.
This change would mandate that (a) anyone who provides accessibility
information must provide entrance/exit information, and (b) anyone who
processes GTFS must process that information. The second requirement
doesn't bother me, because I'm happy to write that code into
OpenTripPlanner, but it's worth making explicit.
The New York City MTA refuses to provide subway entrance/exit
information for security reasons. These security reasons are bogus,
since the location data is already available (a) from the city of New
York, (b) from us, and (c) to anyone with a GPS receiver and some free
time. Nonetheless, they will not budge. So,unfortunately, some feeds
will not have entrance/exit information, but would like to provide full
accessibility information.
Igor Kulkin
On Mar 5, 7:03 pm, David Turner <nova...@novalis.org> wrote:
> On Fri, 2010-03-05 at 09:55 -0800, Igor Kulkin wrote:
> > Regarding the issue of having stations suitable for accessible
> > transfers and not accessible from the street level:
>
> > I think it makes sense to treat a stop to be accessible for a transfer
> > if its 'wheelchair_boarding' property is set to "1" (at least it
> > doesn't contradict the definition of the value). Seems like we do need
> > a way to specify whether a stop is accessible from the street level.
> > This should probably be modeled with entrances/exits. An exit could
> > then be marked as either accessible or not.
>
> This change would mandate that (a) anyone who provides accessibility
> information must provide entrance/exit information, and
That's not completely true. For many cases entrances and their
accessibility doesn't make sense at all (e.g. for bus stations, which
are in many cases already on the street level and therefore are entry-
accessible).
I agree that there's going to be a bit of confusion around it, but the
stop could be assumed to be entry-accessible by default unless there
is an entrance, which is explicitly declared to be inaccessible. That
way there is no need to create entrances for all stops in the feed.
How does that sound?
> (b) anyone who
> processes GTFS must process that information. The second requirement
> doesn't bother me, because I'm happy to write that code into
> OpenTripPlanner, but it's worth making explicit.
>
> The New York City MTA refuses to provide subway entrance/exit
> information for security reasons. These security reasons are bogus,
> since the location data is already available (a) from the city of New
> York, (b) from us, and (c) to anyone with a GPS receiver and some free
> time. Nonetheless, they will not budge. So,unfortunately, some feeds
> will not have entrance/exit information, but would like to provide full
> accessibility information.
I'm guessing MTA in fact refuses to provide accurate *positions* of
entrances/exits. They could still add entrance/exit to properly model
accessibility and use some artificial position for it (e.g. the
position of the stop itself).
David Turner
>
> On Mar 5, 7:03 pm, David Turner <nova...@novalis.org> wrote:
> > On Fri, 2010-03-05 at 09:55 -0800, Igor Kulkin wrote:
> > > Regarding the issue of having stations suitable for accessible
> > > transfers and not accessible from the street level:
> >
> > > I think it makes sense to treat a stop to be accessible for a transfer
> > > if its 'wheelchair_boarding' property is set to "1" (at least it
> > > doesn't contradict the definition of the value). Seems like we do need
> > > a way to specify whether a stop is accessible from the street level.
> > > This should probably be modeled with entrances/exits. An exit could
> > > then be marked as either accessible or not.
> >
> > This change would mandate that (a) anyone who provides accessibility
> > information must provide entrance/exit information, and
>
> That's not completely true. For many cases entrances and their
> accessibility doesn't make sense at all (e.g. for bus stations, which
> are in many cases already on the street level and therefore are entry-
> accessible).
> I agree that there's going to be a bit of confusion around it, but the
> stop could be assumed to be entry-accessible by default unless there
> is an entrance, which is explicitly declared to be inaccessible. That
> way there is no need to create entrances for all stops in the feed.
> How does that sound?
+1
> > (b) anyone who
> > processes GTFS must process that information. The second requirement
> > doesn't bother me, because I'm happy to write that code into
> > OpenTripPlanner, but it's worth making explicit.
> >
> > The New York City MTA refuses to provide subway entrance/exit
> > information for security reasons. These security reasons are bogus,
> > since the location data is already available (a) from the city of New
> > York, (b) from us, and (c) to anyone with a GPS receiver and some free
> > time. Nonetheless, they will not budge. So,unfortunately, some feeds
> > will not have entrance/exit information, but would like to provide full
> > accessibility information.
>
> I'm guessing MTA in fact refuses to provide accurate *positions* of
> entrances/exits. They could still add entrance/exit to properly model
> accessibility and use some artificial position for it (e.g. the
> position of the stop itself).
Oh, that's a good idea!
So, to review:
(1) this proposal includes one new field in stops.txt, one new field in
trips.txt;
(2) this proposal absolutely depends on some version of the
entrance/exit data proposal;
This leaves two questions:
Which version of the entrance/exit proposal are you incorporating?
How are wheelchair accessible transfers computed?