proposal: simple wheelchair accessibility information
Joe Hughes
Add a way to indicate which stops and trips are wheelchair-accessible.
Motivation:
People of limited mobility are a particularly important segment of
transit ridership, and given the patchwork of infrastructure that
exists in older transit systems, 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 (1) express 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. (There are many more
attributes that are important to consider for general accessibility.
This proposal does not address those, though I understand that TriMet
is doing some interesting experiments in that area that will hopefully
bear fruit.)
Proposal:
This proposal adds two fields, which interact with each other:
First, a field in the trips.txt file:
"wheelchair_accessible" (optional) - A value of "1" indicates that the
vehicle being used on this particular trip can accommodate at least
one rider in a wheelchair. A value of "0" or empty indicates that no
riders in wheelchairs can be accommodated on this trip (or that there
is no information to indicate that this is possible).
Second, a field in stops.txt:
"wheelchair_boarding" (optional) - A value of "1" indicates that at
least some vehicles at this stop can be boarded by a rider in a
wheelchair. A value of "0" or empty indicates that there is either no
information about accessibility, or that 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:
Can anyone think of a case in their own system where this proposal
would not be sufficient to encode the basic information of whether a
journey could be completed by a rider in a wheelchair? (Again, I
recognize that there are many more pieces of information--mostly
amenities--which are useful to riders with differing levels of
ability. Let's focus on the simplest case here.) Also, is it useful
to distinguish the case of a stop/trip being explicitly not accessible
from the default state of having no accessibility information?
Thanks,
Joe Hughes
Google
Marc Ferguson
Your Trip & Stop attributes will do the trick. The tendency though is to have these indicate exceptions. Most fleets these days are wheelchair accessible.
Stops are considered accessible unless there are conditions preventing the use of the stop by a person in a wheelchair. I know of one situation where there are 8-10 different codes in use to indicate such conditions as: no sidewalk (but the lift can be deployed), lift blocked, no curb cuts, ....
Speaking of accessibility, you need to consider accessibility when transferring. In some of the older, underground systems, there are places where you can not make a transfer because there are no elevators in place that would allow you to get from one platform to another.
Marc
| "Joe Hughes"
<joe.hug...@gmail.com>
Sent by: gtfs-c...@googlegroups.com 04/01/2008 01:24 AM
|
|
Roger Slevin
Marc
Please remember this specification is for international use – and certainly in the UK we are still several years away from all buses being accessible by wheelchair. We also have situations where some combinations of on-vehicle and at –stop arrangements for wheelchair access do not work together … high kerbs (curbs) do not work with some kneeling buses, for instance.
In many areas I can classify an entire service as being operated normally by wheelchair accessible vehicles, but in other areas it may be that only specific journeys on a particular service are normally operated by wheelchair accessible vehicles … so it is helpful to be able to specify this at both the service level, and at the individual journey level (where the individual journeys would inherit the default set at the service level).
Best wishes
Roger
<br
Marc Ferguson
true true,
Certainly how the "flags" will set will depend on the capabilities of the fleet. I don't know that setting the flag at the service level is something the GTF should address. I think the software exporting to GTF needs to make the decision and set the trip (journey) flag accordingly.
I think in the case of the high curbs, the agency export needs to decide how to set the stop flag (Y/N). This allows the agency providing the data to make the decision and not require GT to implement a compatibility matrix of which types of equipment are compatible with which type of stop.
Marc
| "Roger Slevin"
<ro...@slevin.plus.com>
Sent by: gtfs-c...@googlegroups.com 04/01/2008 08:42 AM
|
|
|
Marc
Please remember this specification is for international use - and certainly in the UK we are still several years away from all buses being accessible by wheelchair. We also have situations where some combinations of on-vehicle and at -stop arrangements for wheelchair access do not work together ... high kerbs (curbs) do not work with some kneeling buses, for instance.
In many areas I can classify an entire service as being operated normally by wheelchair accessible vehicles, but in other areas it may be that only specific journeys on a particular service are normally operated by wheelchair accessible vehicles ... so it is helpful to be able to specify this at both the service level, and at the individual journey level (where the individual journeys would inherit the default set at the service level).
Devin Braun
accessible. It should be enough for a user to see whether or not a stop
is wheelchair accessible by MTS's determination.
We also keep several other properties of the stop that could be used to
make an individual decision about whether the stop is accessible for an
individual user: curb cuts nearby, sidewalk slope, sidewalk width and
length, and sidewalk material. These types of attributes could be
rolled into Mike's previous proposal about bus stop amenities.
Devin Braun
San Diego MTS
-----Original Message-----
From: gtfs-c...@googlegroups.com
[mailto:gtfs-c...@googlegroups.com] On Behalf Of Joe Hughes
Sent: Monday, March 31, 2008 10:24 PM
To: Google Transit Feed Spec Changes
Subject: [gtfs-changes] proposal: simple wheelchair accessibility
information
T Sobota
indicate that there could be two rather significant differences in
definitions of accessibility, as it relates to trip planning. Per ADA
regs below:
49CFR37
Title 49 of the Code of Federal Regulations Part 37
"Sec. 37.167 Other service requirements.
(g) The entity shall not refuse to permit a passenger who uses a
lift to disembark from a vehicle at any designated stop, unless the
lift
cannot be deployed, the lift will be damaged if it is deployed, or
temporary conditions at the stop, not under the control of the
entity,
preclude the safe use of the stop by all passengers."
Appendix D to Part 37--Construction and Interpretation of Provisions
of
49 CFR Part 37
Section 37.123 ADA Paratransit Eligibility--Standards
"When we say that a lift cannot be deployed, we mean literally
that
the mechanism will not work at the location to permit a wheelchair
user
or other person with a disability to disembark or that the lift will
be
damaged if it is used there. It is not consistent with the rule for a
transit provider to declare a stop off-limits to someone who uses the
lift while allowing other passengers to use the stop. However, if
temporary conditions not under the operator's control (e.g.,
construction, an accident, a landslide) make it so hazardous for
anyone
to disembark that the stop is temporarily out of service for all
passengers may the operator refuse to allow a passenger to disembark
using the lift."
As indicated above, it is likely a very narrow class of stops that a
transit agency would likely wish to flag as "inaccessible" (i.e. do
not permit accessible itineraries - due to the agency having
officially declared a stop to be a danger to lift operation). On the
other hand, there are probably large numbers of stops in what could be
termed a "gray" area. They may not meet all of the ADAAG guidelines
for letter-of-the-law accessibility (i.e. curb ramp, sidewalk,
boarding pad, grades), but on the other hand could still be used by
individuals with mobility constraints if they so choose.
For the specification, as it relates to stops, it would seem
beneficial to delineate between "Not Served (by lift)", "Able to be
served (but not otherwise accessible)", "Able to be served (fully
accessible)". This would permit a rider with mobility constraints to
clearly understand where the transit system is not able to provide
them with service, where the rider would need to make their own
determination on whether the particular stop can be negotiated based
upon their constraint, or if there are no foreseable barriers to their
use of the service.
Tim Sobota
Metro Transit (Madison, WI)
Joe Hughes
have this distinction represented in their databases already? When I
looked at the Madison website I only saw stops marked as "accessible"
vs. not.
Thanks,
Joe
Devin Braun
Devin Braun
San Diego MTS
KevinChicago
has been discussed, we in Chicago have the odd situations were some
transfers can be made within our rail network, via a wheelchair, but
you cannot actually access the station platforms from the street level
via a wheelchair. So possibly, the new transfers.txt file could
contain a 1/0 field for transfer accessibility as well. The
transfer.txt field would override the stops.txt field, but only if the
boarding is a transfer.
Within a year or so, that issue in Chicago will go away as these
stations are becoming fully accessible, but you may have other cities
with that oddity.
Kevin
CTA
Joe Hughes
promising, though we'll need to work out the details of how it
interacts with the other fields in that file.
Joe
Donovan
Disabilities Act. In San Francisco, all of our vehicles are
accessible to wheelchairs, but our stops fall into three categories,
fully ADA compliant, accessible with advisory, and not accessible
(lift cannot deploy). Optionally I would include a list of
accessibility amenities for that stop. The amenities list could be
defined by the agency themselves and would only appear on as bubble
captions for that stop.
Rather than a binary in the stops.txt, I would really recommend three
options, not accessible 0, accessible with advisory 1, fully
wheelchair accessible, 2.
Ideally a user could plan a trip as fully wheelchair accessible, and
then compare to a trip with advisory, then look at the stops for any
amenities that would help determine the suitablity of those stops.
This introduces some more complexity, but meets the intent of the ADA
in the U.S.
Donovan
San Francisco MTA
Joe Hughes
Thanks for chiming in. I think the addition of an "accessible with
advisory" state for a stop doesn't add too much complexity, but it
probably would require an accompanying text field to indicate what the
advisory for that stop was.
Do any other agencies here have data that would allow them to specify
"accessible with advisory" along with meaningful advisory text for
some stops?
Related question: Is the "accessible with advisory" mode relevant to a
trip, or is it sufficient for trip planning purposes to consider a
vehicle either accessible or not?
Incidentally, the specification of stop amenities is discussed on a
separate thread. I hope we can keep these two things orthogonal so as
to not make the logic that a GTFS client needs to implement too unduly
complicated for accessible trip planning. The easier it is, the more
apps will implement it properly.
Joe
Marc Ferguson
If you include the "with advisory" then the advisory information has to be available and someone has to know how to interpret the advisory. Then, if the stop is not accessible based on their particular circumstances, then what? How are alternate stops found??
Black or white covers more circumstances than yes, no or maybe.
Marc Ferguson
marc.f...@trapezegroup.com
757-961-9224 x304
| Donovan <dcor...@gmail.com>
Sent by: gtfs-c...@googlegroups.com 04/15/2008 02:13 PM
|
|
Donovan
In the case of our system, all trips will be accessible and whether a
stop is accessible or not depends on the physical stop, and does not
vary with the trip.
In response to Marc, if we go with a binary (accessible, not
accessible) we could list a few dozen fully ADA compliant stops out of
4000+, and that would give the impression that for most of our system
is not accessible, which isn't true. Or we could list every stop
where a lift can be deployed (over 95% of stops), but that would
include some stops that would some users would not want to use and we
would want a stop specific advisory or to direct them to a description
of the stop and area (perhaps a URL?) to let them determine whether or
not they want to use it. So I am open to suggestions, but somehow
need to distinguish fully ADA compliant stops from not-fully compliant
stops that many users will want to use. It seems clear to me that the
intent of the ADA is to empower users to determine which stops they
board/disembark at as long the agency can deploy a lift there.
Donovan Corliss
SFMTA
>
> - Show quoted text -
Marc Ferguson
Hi Donovan,
In my scenario the 95% of the stops would be marked as accessible because a lift can be deployed. The "accessible" attribute in this case does not indicate full ADA compliance but the union of: "can the lift be deployed" and "can a majority of customers get to the stop." The lack of curb cuts may prevent the stop from being fully ADA compliant but the curb presents an obstacle and not a barrier to persons with mobility issues. (in my able bodied opinion).
The advisory presents another level of complexity to the GTFS as well as the how to the system deal with the situation of " there is an advisory, now what do I do??"
Marc
| Donovan <dcor...@gmail.com>
Sent by: gtfs-c...@googlegroups.com |
04/16/2008 02:10 PM |
|
|
Peter Miller
photographs of the 'accessible' infrastructure could help a person
decide for themselves if something was suitable for their needs. He
gave the example of a 'disabled accessible toilet' which might be
accessible to one person and not to another. The person in question
could probably tell from the photo if it was made available to them
and was much more useful that any binary flag.
I also saw a very interesting university project in Oslo where users
were asked after making a journey if it had worked for them. For each
leg of the journey they could say 'fine', 'hard', or 'impossible'.
Importantly they also self-identified themselves into groups so that
their experience could be shared with others with similar issues.
There might be a group for 'wheel chair users', and other for
'motorised wheelchair users' and another for 'XYZ make wheelchair
(super XXX size) along with 'parents with young children' and 'infirm
elderly' etc. The clever invention to my mind was that people self
organised into groups and then provided feedback for journeys they had
made so that the system could learn from their experience.
Incidentally the Department for Transport in the UK invited wheelchair
users to come and be measured so they could decide how large
wheelchairs actually are (they all vary) and therefore how much room
needed to be provided in buses so that at least the great majority of
wheelchair users could use public transport, even if some could not.
I think I am saying that there is only so far that the technology can
go and as Donovan says a binary indicator must come with a health-
warning. Cutting out the ridiculous stops at the top of a flight of
steps and leaving all the ones in where it should be ok with some
assistance seems sensible. If this could be enhanced by user feedback
of the type described above, then even better.
Regards,
Peter Miller
On Apr 17, 12:58 pm, Marc Ferguson <Marc.Fergu...@trapezegroup.com>
wrote:
>
> In my scenario the 95% of the stops would be marked as accessible because
> a lift can be deployed. The "accessible" attribute in this case does not
> indicate full ADA compliance but the union of: "can the lift be deployed"
> and "can a majority of customers get to the stop." The lack of curb cuts
> may prevent the stop from being fully ADA compliant but the curb presents
> an obstacle and not a barrier to persons with mobility issues. (in my
> able bodied opinion).
>
> The advisory presents another level of complexity to the GTFS as well as
> the how to the system deal with the situation of " there is an advisory,
> now what do I do??"
>
> Marc
>
Bob Heitzman
the text is present display it whenever other stop info is displayed
as an accessibility advisory. The agencies can decide what the text
says to cover a multitude of cases. (I would assume today 90+%
wouldn't have advisories and the field would be blank.)
Using this method marginal cases could be address too. e.g "Wheel
chair ramp 1/10 mile west on A Street" or "No flat/hard surface
available for boarding"
A step beyond would be to use a slightly different icon for the stop -
perhaps yellow color or a little x in the corner.