Proposal: wheelchair_accessibility

[Brian Ferris]

Original Discussion:

http://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f8fa7c4cc8430
http://groups.google.com/group/gtfs-changes/browse_thread/thread/6caaadd2e1ec9b65
https://groups.google.com/group/gtfs-changes/browse_thread/thread/94a15fd8b78a5e8c

Summary of proposal:

The addition to the stops.txt section of the GTFS spec:

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

The addition to the trips.txt section of the GTFS spec:

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

Initial implementation from a GTFS producer and consumer:

Producers: Only 9 feeds currently include
stops.txt:wheelchair_boarding and only 5 feeds currently include
trips.txt:wheelchair_accessible in the Google Transit corpus. Most
agencies are using the “0” and “1” semantics for accessibility. Just
two feeds, for agencies in Spain, are using the “2” semantics.
Consumers: The feed validator only check wheelchair_boarding in
stops.txt but not wheelchair_accessible in trips.txt. Google Transit
pipeline also supports wheelchair_boarding for stops but not
wheelchair_accessible for trips. In terms of others who are using the
spec, I know OTP supports both wheelchair_boarding and
wheelchair_accessible, but an older version of the proposal that
didn’t include the “2” semantics. Should be relatively easy to fix.

Status:

There is some concern about encoding stations where an
accessible-transfer is possible even if boarding-or-alighting from
that station is not (eg. a train platform with no elevator). This
will hopefully be addressed by the pathways.txt proposal, but that may
be a while coming, so I’d like to move forward on this either way,
especially since some agencies are including data.

Unless there are objections in the next week (Sept 6), we will
formally add this proposal to the GTFS spec.

Thanks,
Brian

[Joe Hughes]

It would be fantastic to get these accessibility features into the
official spec.

Do you know if OpenTripPlanner uses the interaction of
wheelchair_boarding and wheelchair_accessible values for planning an
accessible trip? This seems like a key interaction to check in
practice.

Also, it sounds as though the "2" semantics haven't been tested with
any clients. We should consider dropping that from the proposal due
to lack of interest & testing, unless someone wants to volunteer to
use it in their client.

Cheers,
Joe

On Aug 30, 1:07 pm, Brian Ferris <bdfer...@google.com> wrote:
> Original Discussion:
>
> http://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f...http://groups.google.com/group/gtfs-changes/browse_thread/thread/6caa...https://groups.google.com/group/gtfs-changes/browse_thread/thread/94a...

[Brian Ferris]

I'll let the OTP guys add more detail, but I'm pretty sure they do
support accessible routing.

Just to clarify, I think there was a fair amount of agreement on the
[0, 1, 2] semantics in the last iteration of the proposal. The feed
validator is already checking for [0, 1, 2] for
stops.txt:wheelchair_boarding (but not yet on
trips.txt:wheelchair_accessible). The proposal seemed to bog down
most recently do to discussions around stations where an accessible
transfer is possible, but an accessible boarding / alighting is not
possible. We'll ultimately need the "pathways" proposal to address
this fully, but I think it's worth moving forward on these
accessibility features first.

Brian

> --
> You received this message because you are subscribed to the Google Groups "General 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.
>
>

[David Turner]

On Tue, 2011-08-30 at 08:40 -0700, Joe Hughes wrote:
> It would be fantastic to get these accessibility features into the
> official spec.
>
> Do you know if OpenTripPlanner uses the interaction of
> wheelchair_boarding and wheelchair_accessible values for planning an
> accessible trip? This seems like a key interaction to check in
> practice.

Yes, it does.

> Also, it sounds as though the "2" semantics haven't been tested with
> any clients. We should consider dropping that from the proposal due
> to lack of interest & testing, unless someone wants to volunteer to
> use it in their client.

2 is better handled through pathways.txt, I think.

[Brian Ferris]

Is that a vote for removing the "2" convention for both stops and trips?

[David Turner]

If pathways.txt becomes official, yes.

[Brian Ferris]

Taking this to the next step, we would then change the semantics of
the "0" value back to "wheelchair boarding is either unknown or not
possible"?

I personally like the 0, 1, 2 semantics, because it is explicit the
difference between "definitely not accessible" and "maybe not
accessible".

Brian

[MVTA Users]

I definitely think that the question of accessibility is a trinary,
not binary question - there are three distinct states, Yes/No/Unknown,
and it's much more useful to the consumer to have that information
than simply the binary states of Yes/Not Yes. One could I think
fairly argue that Unknown should be the default state until an agency
evaluates a given stop/trip for accessibility. If this were to be
implemented, that's what we'd do on the stop side (our trips are
already 100% Yes).

Mike
Michael Abegg, Transit Planning Mgr
Minnesota Valley Transit Authority
100 Hwy 13 E
Burnsville, MN 55337
952-882-7502
mab...@mvta.com

On Aug 30, 11:17 am, Brian Ferris <bdfer...@google.com> wrote:
> Taking this to the next step, we would then change the semantics of
> the "0" value back to "wheelchair boarding is either unknown or not
> possible"?
>
> I personally like the 0, 1, 2 semantics, because it is explicit the
> difference between "definitely not accessible" and "maybe not
> accessible".
>
> Brian
>
>
>
>
>
>
>
> On Tue, Aug 30, 2011 at 6:04 PM, David Turner <nova...@novalis.org> wrote:
> > If pathways.txt becomes official, yes.
>
> > On Tue, 2011-08-30 at 17:54 +0200, Brian Ferris wrote:
> >> Is that a vote for removing the "2" convention for both stops and trips?
>

> >> On Tue, Aug 30, 2011 at 5:49 PM, David Turner <nova...@novalis.org> wrote:
> >> > On Tue, 2011-08-30 at 08:40 -0700, Joe Hughes wrote:
> >> >> It would be fantastic to get these accessibility features into the
> >> >> official spec.
>
> >> >> Do you know if OpenTripPlanner uses the interaction of
> >> >> wheelchair_boarding and wheelchair_accessible values for planning an
> >> >> accessible trip?  This seems like a key interaction to check in
> >> >> practice.
>
> >> > Yes, it does.
>
> >> >> Also, it sounds as though the "2" semantics haven't been tested with
> >> >> any clients.  We should consider dropping that from the proposal due
> >> >> to lack of interest & testing, unless someone wants to volunteer to
> >> >> use it in their client.
>
> >> > 2 is better handled through pathways.txt, I think.
>
> >> > --
> >> > You received this message because you are subscribed to the Google Groups "General 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 athttp://groups.google.com/group/gtfs-changes?hl=en.

[T Sobota]

To the extent the United States has a regulatory definition of what elements are required for a transit stop to meet the standards of the Americans with Disabilites Act (boarding surface dimensions, slopes, connections to curb ramps/sidewalks), but transit stops not meeting those standards do not necessarily restrict or limit all passengers with mobility devices from using a "substandard" transit stop (i.e. buses are permitted to deploy wheelchair ramp onto surface of a road that does not have curb or sidewalks), I would offer perhaps four categories:

0 (blank): Accessibility is unknown

1: Stop is inaccessible to passengers using mobility devices (i.e. transit agency has affirmatively determined that accessibility features of a transit vehicle cannot be used under any circumstance at the transit stop, due to safety or other reasons)

2: Stop may be accessible to passengers using mobility devices (i.e. transit stop does not meet all government mandated parameters that formally define accessible, but transit vehicles are permitted to use accessibility features to aid passengers with mobility devices)

3: Stop accessible to passengers using mobility devices (i.e. transit stop meets all government mandated parameters that formally define accessibility for passengers with mobility devices).

Tim Sobota, Transit Planner

Metro Transit, City of Madison (WI)

[Wojciech Kulesza]

+1 to add wheelchair_boarding and wheelchair_accessible to official gtfs.
in our trip planner for city of Lublin in Poland (lublin.iplaner.pl) which is powered by Open Trip Planner API, we're using this in the user interface to allow planning trips that use low-floor buses (where wheelchair_boarding is set to 1 for all stops and wheelchair_accessible is set to 1 for all trips that are serviced by low-floor buses).
i personally also like the approach with yes/no/no info.

Wojciech Kulesza
goEuropa

[Joe Hughes]

Tim, thanks for the info about ADA requirements. The question is,
would any clients actually make any meaningful distinction between
your proposed state 2 and 3, or would they just lump them together
under "I can plan an accessible trip across this stop"/"show the
wheelchair icon on this popup"? If no one takes the time to use that
distinction, the likelihood of getting improperly coded data for that
field from feed publishers increases.

So to move that concept forward, we need to find some GTFS client
authors who are interested in representing such a distinction to the
passenger.

Joe

[Joe Hughes]

It does seem that there are a lot of people (myself included) who are
intellectually attracted to having having the explicit "not
accessible" value. The key question, then, is why almost no feed
publishers or clients have chosen to support this field yet. Are
there regulatory disincentives for an agency to express this in the
feed? Is it just a rare case? Is it a difficult thing to represent
to a rider in a client?

Joe

On Aug 31, 8:42 am, Wojciech Kulesza <wkule...@gmail.com> wrote:
> +1 to add wheelchair_boarding and wheelchair_accessible to official gtfs.
> in our trip planner for city of Lublin in Poland (lublin.iplaner.pl) which
> is powered by Open Trip Planner API, we're using this in the user interface
> to allow planning trips that use low-floor buses (where wheelchair_boarding
> is set to 1 for all stops and wheelchair_accessible is set to 1 for all
> trips that are serviced by low-floor buses).
> i personally also like the approach with yes/no/no info.
>
> Wojciech Kulesza
> goEuropa
>

> On 30 August 2011 14:07, Brian Ferris <bdfer...@google.com> wrote:
>
> > Original Discussion:
>
> >http://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f...
>
> >http://groups.google.com/group/gtfs-changes/browse_thread/thread/6caa...
>
> >https://groups.google.com/group/gtfs-changes/browse_thread/thread/94a...
>

[Sean Barbeau]

+1 to add wheelchair_boarding and wheelchair_accessible to official
gtfs.

> It does seem that there are a lot of people (myself included) who are
> intellectually attracted to having having the explicit "not
> accessible" value. The key question, then, is why almost no feed
> publishers or clients have chosen to support this field yet. Are
> there regulatory disincentives for an agency to express this in the
> feed? Is it just a rare case? Is it a difficult thing to represent
> to a rider in a client?

Joe - I agree, from a trip planner's perspective it makes perfect
sense to include a "not accessible" option to route users to the
proper stop. From my discussions with some transit agencies, though,
it seems they are very reluctant to publicly classify stops in this
category. We've had some folks tell us that they won't have something
labeled "not accessible" in a public-facing data set due to fear of
lawsuits & liability - that someone would learn that the agency knows
a stop isn't accessible, go to that stop, and "fall" and sue the
agency. I don't know if this is a fear based on past experience, or
just an anticipation of something that might or might not happen.

Another reason may be that the "not accessible" state for stops.txt is
(or at least should be) a transient state from "unknown" to
"accessible". For example, say the agency truly doesn't know whether
its stops meet ADA standards, but it hires a consultant to assess
them. Once it becomes known which stops are not accessible, they are
improved to make the stop accessible. This might happen in faster
than the GTFS publishing time period, so the "not accessible" field is
never seen in the GTFS data. Alternately, we're also aware of
agencies discontinuing service to a stop because they are aware that
the stop is not accessible, but they do not have the funds to make it
accessible. So the stop is removed from service entirely rather than
marked as "non-accessible".

With the above being said, in the interest of open data I think for
stops.txt its still best to include the "not accessible" field for
situations where a bus stop may be known to be not accessible, and
there is no easy method (or funds) for the transit agency to
immediately make it accessible. So, my +1 would be for the [0,1,2]
semantics in Brian's first post in this thread for stops.txt.

As an aside, I think we'll likely have differing perspectives on stop
accessibility for the immediately surrounding area from agencies in
dense urban environments versus more suburban areas. For example, in
NYC and DC most subway entrances I've seen are served by sidewalks,
and the key accessible path issues come in terms of elevator/ramp
access to the platform. I believe the proposed GTFS pathways.txt
would be the best way to represent whether the surrounding area for
these stops is "accessible" (since the agency likely maintains the
surrounding area). Alternately, in our area of Tampa, Florida, our
main challenge are bus stop "islands", where the bus stop itself is
"accessible" with a concrete pad, etc., but it is surrounded by grass
on the non-street sidess with no nearby connecting sidewalks. It
seems to me that alternate datasets like OpenStreetMap, such as the
design used in OpenTripPlanner, would be best to handle surrounding
accessibility issues here (since the agency may not maintain the
surrounding area). So, wheelchair_boarding in stops.txt would define
just that - boardings - and access to the stop is defined by
surrounding data. I'd be interested in hearing others feedback on this
too though.

Sean

[T Sobota]

To address Joe's question on why transit providers might be limited in affirmatively coding stops as inaccessible, and to reinforce my four class schema - I would note that the US Federal regulations in the Americans with Disabilities Act do have language along the lines of a transit provider may not refuse to deploy a vehicle's accessibility feature (i.e. wheelchair ramp) at a designated stop, unless damage would occur to the accessibility feature - or the stop is otherwise temporarily inaccessible for all passengers regardless of their need for a mobility device.  An interpretation of that language goes to where a transit provider could be inclined to code stops as either fully meeting all the regulatory definitions of accessibility (no foreseeable reason why a passenger with a compliant mobility device would be unable to use the transit stop) - or that the stop does not have every feature required for regulatory accessibility, but the accessibility feature of the vehicle can still be used (it however becoming incumbent upon the passenger to research/determine what particular accessibility elements are lacking and if using transit at that stop would, for example, involve waiting on the shoulder of the road, needing to use a driveway apron to get on/off the sidewalk, etc.)

[Brian Ferris]

Hey Tim,

Would Metro Transit (City of Madison) be willing to provide this level
of detail in their GTFS?

Just a reminder that a critical first step in moving a GTFS proposal
forward is finding an agency who is willing to produce data conforming
to the proposal.

Thanks,
Brian

> --
> 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/-/Eia_8nSUCuwJ.

[Roger Slevin]

I am a little concerned that this subject appears to be heading towards an encoding which is based on a single nation’s regulatory provision for disability / accessibility ... and wonder whether this is going to fit the bill internationally, which is what GTFS needs to accommodate.  Sure, let the US legal codes inform the debate – but let’s not see GTFS based on just one country’s legal code.  The provisions need to be equally applicable across all nations – and each has its own slightly different provisions in this area of policy.  That means that provision to encode that it is “not possible” to achieve wheelchair accessibility at a particular stop point is probably sensible – even though that value may not be used in the USA.

 

Roger

 

[David Healy-AUS]

+1 on Roger’s proposal below. I think the logic of having a “non-accessible” value makes it worthy of inclusion. It doesn’t mean that it has to be used if it is not appropriate.

--

[Brian Ferris]

In the interest of building some consensus around what we all agree
on at this point and what we do not, I'd like to do a quick recap of
where we stand.

Things I believe we generally agree on:

1) Adding wheelchair accessibility information to GTFS is a good thing.
2) The stops.txt wheelchair_boarding field and trips.txt
wheelchair_accessibility fields are generally reasonable ways of
adding accessibility info.
3) The semantics of "0 = unknown accessibility, 1 = accessible" are
generally agree to be reasonable.
4) We have multiple agencies producing data of this form and multiple
clients consuming it.

Things we have less agreement on:

1) The addition of "2 = definitely not accessible" is useful. We have
fewer agencies producing data of form and fewer clients consuming it.
2) The addition of additional levels of accessibility beyond 0, 1, and
potentially 2 is useful.
3) It is sufficient to adopt the existing wheelchair accessibility
proposal, recognizing that there are accessible routing cases that can
only be correctly modeled with the pathways.txt proposal.

If you have strong disagreement with anything I put in the "Things I
believe we generally agree on" section, let me know.

Thanks,
Brian

[Bernard Au]

I would suggest adding a 3 option "coordinate with agency for accessible ride"

[tompw]

Thanks for the summary Brian.

I feel quite strongly that there needs to be way for agencies to show
that a stop is *not* accessible. Some people with physical
disabilities may be willing to risk an "unknown" (particularly with
bus stops), but clearly an "not accessilble" means they need to change
their plans. (I can see a transit agency doing "Yes" and "No" for its
few dozen subway stattions, and leacing "unknown" for its hundreds of
bus stops).

I agree that the practices of existing feeds and consumers should
inform out discussion. However, the whole point of this discussion
group is to take unofficial practices and refine/polish them into
something official. If a transit agency knows a stop is inaccessible,
then the GTFS spec should provide a way to communicate that to the
customer.

Regards,

Tom

> >http://groups.google.com/group/gtfs-changes?hl=en.- Hide quoted text -
>
> - Show quoted text -

[T Sobota]

I would anticipate that I would be able to code the stops in our agency's service area into the four broad categories that I am advocating:

0: No info

1: Not accessible (specifically a transit vehicle is absolutely prohibited from using any of its accessibility equipment at the stop in question, i.e. bus cannot deploy wheelchair ramp, bridge plates not possible between train and platform)

2: Accessible (specifically the stop complies with all applicable governmental regulations that define accessibility, such as ADA in the United States - but also regional or national guidelines as present in other countries)

3: Not inaccessible (generally a transit vehicle can use its accessibility equipment, but the stop itself does not fully comply with all applicable governmental regulations - which may result in some riders using a mobility device not being able to use the stop based on what particular accessibility elements are missing such as curb ramps, sidewalks, cross-slope grades, etc.)

The conflict I see is between a formal definition of accessibility (based on applicable governmental standards), and the individual experience of each passenger based on their abilities and the capabilities of any mobility devices they use.  A transit agency can affirmatively state at which stops their vehicles cannot use any accessibility equipment that is present on the vehicle, and a transit agency can affirmatively state what stops fully comply with the governmental regulations that officially define accessible.  I would see my own agency as having few if any of the former (Not accessible), and a growing number of the latter (Accessible).  I would still anticipate the majority of the (bus) stops would be type 3 however, a gray area that would ultimately be a determination of the individual having an accessible experience rather than the agency guaranteeing as much.

A passenger with low or no vision may easily be able to navigate to and access a transit vehicle at a stop classified as "1" Not Accessible.  A similar passenger might however require braille directional signage, or detectable warning plates, to feel safe accessing the same stop - making it inaccessible for their experience.

A passenger using a manual wheelchair may lack the strength to roll up a slope/incline to access a transit stop classified as "2" Accessible - despite the slope not exceeding the applicable governmental definition, making it inaccessible in their experience.

Also, thanks to Roger for underlining the point that a GTFS standard would need to extend beyond the borders of the US... which has always been my intent.  My assumption is that other countries would either have guidelines/standards for what comprises an accessible transit stop (which would guide the differentiation between 2 and 3) - or absent any formal definitions for the technical items like cross-slopes of boarding surfaces, etc. - a transit agency would use the item 3 (plus zero or one as appropriate).  My reference to various components of US ADA standards is only due to that being my sole area of transit accessibility knowledge on an international level.

[John L]

Any station with a ramp or ground level elevator is considered accessible. This may not be ada accessible however

[Brian Ferris]

I want to keep this proposal moving forward, so here is a quick
update. I haven't heard any disagreement about the general summary of
things I think we agree on from two weeks ago. Since then, I've been
working on some of the other, more-contentious parts of the proposal,
including the addition of "2 = definitely not accessible".
Specifically, I've reached out to some individuals who had questions
or concerns about the proposal to see what was blocking. I've also
been working on getting an agency to publicly publish a feed that uses
the "2 = definitely not accessible" semantics. I've had success with
former, but not as much the latter.

Specifically, there are a handful of agencies who are publishing data
to Google that uses the "2 = definitely not accessible" semantics for
stops and Google in-turn displays that information through a
wheelchair icon displayed on stop info windows. Unfortunately, none
of these agencies are sharing their feeds publicly, so I can't point
developers to that data to play with. That said, I'm hoping this is
sufficient to demonstrate the utility of this portion of the proposal.
Combine that with a number of comments in favor of the feature on
this thread, and I think it's worth moving forward with the proposal.

I'm going to send out an updated version of the proposal in a new
email (so it's easier to link to) that includes the "2 = definitely
not accessible" proposal. Expect an email shortly.

Thanks,
Brian

[Brian Ferris]

As promised, the summary of proposal:

The addition to the stops.txt section of the GTFS spec:

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

The addition to the trips.txt section of the GTFS spec:

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

We have agencies producing data and developers consuming data using
the proposed addition (I'm happy to provide specific examples on
request). I'm opening up the proposal for an official request for
comment period for the next week. If no major comments are received
by Tuesday, September 30, the proposal will be adopted.

Thanks,
Brian

[Bernard Au]

What if we have a paratransit stop or for inter-city buses where advanced arrangement with the operator is required?

Bernard Au, M.U.P.
Transportation Planner / Analyst.

[Brian Ferris]

That could potentially be modeled with an additional code? That said,
to avoid speculative features, I'd be interested in hearing from:

a) An agency interested in providing that data
b) A developer interested in consuming that data

Would you be opposed to the initial version of wheelchair
accessibility, even if additional features are added later?

Brian

[StuartJReynolds]

In the UK, buses are not necessarily only wheelchair accessible. We
have a number that are low floor (e.g. the bus drops to present a
small step to the user) but which do not have a wheelchair accessible
space. It would be good to capture that as an attribute in addition to
wheelchair accessible.

Could we extend the intent of this to include a more general
definition of accessible so that we might have (for example):

"255" or empty - no accessibility info
"1" can accommodate wheelchair
"2" low floor

plus binary combinations (e.g. 3 = low floor plus wheelchair)

or something similar?

Apologies for late contribution, but only just joined group.
Regards,
Stuart

[Bernard Au]

I have no problems with the initial version of wheelchair accessibility. This could be added later, if there is
sufficient demand from public transportation systems.

[Joe Hughes]

I'm not sure I agree that this version of the proposal has been fully
tested. You mention that the "2" ("not accessible") states are used
by some feed publishers, but those feeds aren't public, and there
don't seem to be any consuming apps that display "2" as a distinct
state in the UI. Therefore, it seems impossible for this group to
determine whether the "2" state works as intended in a client-facing
app.

I'd propose putting states "0" and "1" into the spec now, and leaving
"2" as a proposal until we have clients that want to display that
state differently to the user.

Cheers,
Joe

On Sep 20, 4:36 pm, Brian Ferris <bdfer...@google.com> wrote:
> As promised, the summary of proposal:
>
> The addition to the stops.txt section of the GTFS spec:
>
> 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
>
> The addition to the trips.txt section of the GTFS spec:
>
> 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
>
> We have agencies producing data and developers consuming data using
> the proposed addition (I'm happy to provide specific examples on
> request).  I'm opening up the proposal for an official request for
> comment period for the next week.  If no major comments are received
> by Tuesday, September 30, the proposal will be adopted.
>
> Thanks,
> Brian
>

[Brian Ferris]

Given the discussion from Bernard and others about leaving room in the
spec going forward for additional definitions of accessibility in the
future, I guess I'm not opposed to that. It's true that the Google UI
does not distinguish between "unknown accessibility" and "definitely
not accessible" at this point. If we and other developers aren't
explicitly using the functionality, it can probably wait for now. I'd
rather get an initial version of the proposal adopted that can be
extended later than to keep waiting.

Brian

[Brian Ferris]

Similar to my comments to Bernard and Joe, the question remains about
whether any developers would expose that level of detail in their
apps. Recall that in order to keep the spec from growing unwieldy, we
look to adopt changes that have been implemented by both a GTFS
producer and consumer.

Thanks,
Brian

[David De Vries]

TransLink has a public feed and in our local trip planner do mark our stops as Non Accessable

If there is a developer who would be interested in working with our feed, we would be happy to add the "2" Not Accessible option to our feed.

 

All of our current fleet is accessible (barring mechanical failure of the lifts) so the ability to board is directly related to the conditions at the stop. Our trips would be coded as "1" and stops would be either "1" or "2" depending on the conditions at the stop.

 

DAVID DE VRIES MCP,MCSA +S, MCDBA, MCSE +S

Team Manager Client Solutions - IS Operations

Business Technology Services

david....@translink.ca

 

>Given the discussion from Bernard and others about leaving room in the spec going forward for additional >definitions of accessibility in the future, I guess I'm not opposed to that.  It's true that the Google UI does >not distinguish between "unknown accessibility" and "definitely not accessible" at this point.  If we and other >developers aren't explicitly using the functionality, it can probably wait for now.  I'd rather get an initial >version of the proposal adopted that can be extended later than to keep waiting.

 

>Brian

 

 

On Tue, Sep 20, 2011 at 5:54 PM, Joe Hughes <joe.hug...@gmail.com> wrote:

>> Thanks,

>> Brian

>> 

>> On Tue, Sep 20, 2011 at 5:30 PM, Brian Ferris <bdfer...@google.com> wrote:

>> >>> --

[T Sobota]

I continue to struggle with the proposed spec, and what the intent is for providing it.

As a bus only transit system, all the stops in our service area would fall under category one in the proposed spec (to the extent there are no bus stops in our service area where we discriminate against passengers with mobility devices and refuse to deploy the wheelchair ramp/lift if requested).  Having the spec contain three categories:  accessible, not inaccessible, and inaccessible would allow our system to affirmatively differentiate those transit stops that have accessibility elements (per regulatory design guidelines) from those that don't.

I cannot see how the intent of this spec could be to affirmatively guarantee that any individual using a wheelchair (or other mobility aid) will personally be able to board the transit vehicle at such a transit stop - as the abilities/constraints of each individual (and their mobility device) will vary widely.  What one individual may be able to accomplish in a given stop environment may differ from what another individual is capable of in that same environment.  Where a transit system would make very restrictive assumptions about abilities - it may falsely filter or limit a passenger's possible identification of an otherwise (to them) functional transit stop.  Conversely, coding stops to the least restrictive assumption (i.e. a transit vehicle lift can be deployed, but only onto the travel surface - no sidewalk or boarding surfaces present to wait for the vehicle) could falsely direct riders to those locations when their requirements/preference would be to use a stop with specific accessibility elements in place at the stop.

If the intent of the proposed spec is to affirmatively identify what transit stops have upgraded accessibility elements that go towards enhancing the potential accessibility for individual riders using wheelchairs or other mobility devices, this would be much easier for a transit system operator to quantify.  Under this scenario though, I see a need for the three categories:  First being the transit stop meets all regulatory standards that technically define accessibility (an individual's experience may still vary, but the stop is otherwise in compliance with technical design standards); second the transit stop does not meet all regulatory standards that define accessibility - but the accessibility equipment on the transit vehicle can still be used at this stop (an individual will need to more closely review the actual stop environment when determining if this stop is accessible for their situation, will they need to navigate an especially steep slope, etc. - it is fine for exiting the transit vehicle, but not waiting for its arrival to board); and third, the transit stop is not accessible to the extent accessibility equipment on the transit vehicle cannot be used under any circumstance at this stop.

I would still be willing to populate our stops.txt file with this three-category system, if that becomes the group concensus on how to define transit stop accessibility.

[Bernard Au]

I think the word "accessible" at this stage is generic and will be governed by local accessibility laws and regulations, after all Google Transit is being used world wide.

In the US I am assuming the word "accessibility" would be based on ADA's definition of an accessible bus stop. Whereas, in Ontario, Canada it may be defined by AODA, so on and so forth.

My question too is, in some places bus stops are "accessible". However at the Route level, certain trips are accessible trips (ie. low floor buses, wheelchair ramps etc) while other trips are non accessible (high floor). Can the proposed spec include some provisions for that?

Bernard

--

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/-/RaCqPzkMr1AJ.

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]

Hi Tim,

I'm glad that you're asking these questions; the more of us think hard
about all the implications of these proposals, the better the results
will be.

My motivation for the simplicity of the original proposal was
increasing the likelihood that an app author, when interpreting and
displaying data, would create something that would convey useful
information to the rider. I believe that we need to balance the
desire for detail with the cost in UI complexity.

The accessibility information should clearly be able to answer the
following questions:

1) If a trip planner is asked for a trip that can be completed in a
wheelchair, can it include a boarding or alighting at a particular
stop for a particular trip?

2) If the user is browsing stops in a map or list of stops, can the
stop be identified as usable while in a wheelchair (in other words,
can an app display an "accessible" icon for that stop in the same way
that printed agency maps and schedules might)?

As you and others have pointed out, there are many other important
shades of accessibility when it comes to public transit. However, if
representing these accurately would increase the complexity of a
client app's UI to the point that the app auther either would't
implement them at all, or would choose their own approximation that
may incorrectly reflect those nuances, then we would have done our
limited-mobility riders a disservice by including them.

It may be useful to layer on really fine-grained accessibility details
for specialized clients that will take care to present them properly.
However, the spec should always be able to answer the simple questions
above easily and unambiguously.

Joe

[Bob Heitzman]

I'm not sure of the utility of reducing accessibility to a computer readable code.

Accessibility strikes me more as stop info and not routing criteria. Unless you add the ability to determine route using an accessibility level what would the code be used for? A text field with info provided by the transit system may be useful.

About the best use I could think of would be to display a NOT-accessible symbol somewhere as a warning. That is, the exception is what is significant.

As noted in other post accessibility depends on a lot of factors and I don't see all those can be resolved down to a few codes that would make sense over the entire GT system.

[Brian Ferris]

The machine-readable code is already being used for routing in
applications like OTP, for example. For enum-like values, such as
wheelchair_accessibility, that are designed to be used by software,
the goal is to pick a small set of values that are actually meaningful
and actionable in an application. The small set of accessibility
values we've discussed (unknown, accessible, not accessible) were
picked with that criteria in mind. I agree that there are a lot of
additional gradations of accessibility that an agency might want to
present to a rider but that probably wouldn't be treated all that
differently by an application. Capturing them all in an enum will
probably be difficult. Instead, I think the free-form
'stop_description' field is a good place to put free-form text that
describes specific details of a stop in a flexible way for the agency.

Brian

> --
> 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/-/Cd2TUOaouhoJ.

[T Sobota]

The binary treatment of just "accessible" or "not accessible" will need a very clear definition - to the extent there would seem to be a very distinct grey area between these two conditions.

If accessible is defined as "can a rider using a mobility device access the vehicle at this stop", every bus stop in our service area will comply with this condition - to the extent our policies and regulatory requirements dictate that the wheelchair lift on our buses must be deployed at any bus stop location regardless of built environment of the stop, unless temporary conditions at the stop make it unsafe for any passenger to access the vehicle there.

If accessible is defined as "does the stop meet regulatory design requirements that define accessible", I would estimate that less than half of the stops in our service area have a built environment that fully complies with the all the regulatory design guidelines that create this arbitrary definition of accessible.

I cannot think of any bus stops where our policy and regulatory requirements would create a classification of "not accessible", which would be a situation where deploying the wheelchair lift would cause damage to the equipment.

For an end user, this all or slightly more than nothing situation would seem to fail to create any real benefit in an application that would be filtering transit stops or trip itineraries based on this accessibility data.

From a transit agency perspective, I see the benefit of publishing what minority of stops have been brought up to the regulatory design requirements to meet that definition of accessible - but not if it means the data is being interpreted that wheelchair users are prohibited from using any stop that does not meet that regulatory definition.

Maybe what I need to do is accept using the "No Information/Unknown" category for the set of bus stops where the wheelchair lift can be deployed, but the stop does not meet all the regulatory design requirements - as opposed to suggesting that there be an affirmative (known to be) "not inaccessible" category for the same set of stops.

Tim Sobota, Transit Planner

Metro Transit, City of Madison (WI)

[Bernard Au]

I see where you are coming from. I guess it should be called "Wheelchair accessible stop" as opposed to "Accessible stop" since the latter has a very broad definition across different countries, culture and jurisdiction. Then the response would be

Yes
No/Don't know.

--

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/-/YcETZ4H-Mf4J.

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]

Just to be clear, this is the _wheelchair_ accessibility proposal that
we have been talking about all this time.

Brian

[Brian Ferris]

Ultimately, the decision of whether to mark a transit stop or trip as
"wheelchair accessible" will be up to the transit agency in question
to decide. The proposal is necessarily a simplification of all the
potential complexities and edge-cases of wheelchair accessibility that
might arise, if only because any application that uses this
information to help riders use public transit will need to be simple
enough to actually use. That is to say, anything beyond a simple
Yes/No checkbox that determines if an application will plan a
wheelchair accessible trip is probably starting to push the complexity
limits of most users.

Maybe what's missing from this proposal is an opportunity for agencies
to specify their definition of "accessible"? For example, in the King
County Metro trip planner there is a "Plan accessible trip" option.
This includes a link to a secondary page
(http://tripplanner.kingcounty.gov/help/atis-help-access.html) that
describes just what they mean by accessible. We could provide a
similar option ("agency_wheelchair_accessibility_url" in agency.txt?)
that would optionally allow agencies to specify just what they mean by
accessible.

Any thoughts?

Brian

> --
> 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/-/YcETZ4H-Mf4J.

[Marcy]

Brian, Tom, & all

I am pleased to see there is interest to sort out bus stop accessibility.  This has been an open question so I applaud Brian & Joe & all to move along on this.  

Could we have a confirmation (from FTA? or equivalent at a large US transit agency) that if a transit agency posts a stop is "inaccessible" they would not be disqualified for federal funding?

Seems like a strange question but if FTA funds a system, the system must be accessible. 

I've not seen, nor scoured as any type of expert, as to how finely this definition of accessibility must be resolved & perhaps it has not been asked by route, trip, and obstacles at particular bus stop location.  Certainly the logic of making the system transparent for stop accessibility is in the right direction but who will resolve making the "system" accessible if a rider needs an inaccessible stop updated & accessible.

Most (if not all) buses are lift equipped but if a stop is not accessible should the agency provide a nearby stop within x distance for the system to be ADA compliant?

And it may be helpful to post the weight limit for the lift as there are now persons+their scooters that are exceeding the limit.  Perhaps not helpful for this discussion but this may arise in the future.  The other constraint is also the scooter/wheelchairs dimensions and the lift.  Would you consider a accessibility_url (to the page that explains what is acceptable size, weight, etc and who to call for help) as you have for more info on fares?

I would like to see a reply from some of the larger agencies that they are comfortable with the proposal or suggest alternatives and I've seen, thankfully, a few participating agencies but there could be more US agencies that get fed $ to post their considerations before this goes forward & we might need further confirmation that no one is caught in any confusion if the data is purely and innocently machine readable.

Perhaps one option might be a feedback link that allows riders to note they feel the stop is accessible (or not).  This feedback would be posted for the transit agency allowing more input than a definition from the agency about size of scooter & poles, shelters, obstacles that make it nearly impossible to board the bus.  The opening of a link for feedback could confirm RIDERS want this (which I believe they do) & they can quickly give input to the agency to re-assess a stop that may appear as one value but is really a "3" for them.  I might suggest that offering more public input on accessibility might outweigh the handful of stops noted as "not accessible"

Again, with appreciation for diving in to issues that may appear simple & finding ways to keep them that way.

Marcy

[Bernard Au]

I like the idea of where each transit system can provide a URL on it's own definition of 'accessibility'. Then on the accessibility field all the agency needs to do is say "Yes" or "No". If the customer wants more accessibility info on the transit system they can open the link provided.

--
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/-/1Pftx2Y9xCAJ.

[Brian Ferris]

Are there any agencies out there who are currently providing wheelchair accessibility data in their GTFS who would be willing to include an "accessibility URL" pointing to an agency-specific page documenting your definition or handling of wheelchair accessibility?

Thanks,

Brian

[Brian Ferris]

Hey Marcy,

Thanks for the comments.  That's an interesting question about FTA funding.  I'll see if I can find out an answer.  That said, if anyone on-list knows, feel free to comment.

Thanks,

Brian

--

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/-/1Pftx2Y9xCAJ.

[Brian Ferris]

Just to add to this discussion, I did a little bit of digging regarding FTA funding and ADA compliance.  It's true that any transit agency receiving FTA funding must be ADA compliant, but in practice most agencies have a para-transit system that augments fixed-route service in order achieve compliance.  Specifically, an agency can have inaccessible stops, stations, or vehicles if they provide a complementary para-transit system that can help qualified riders who are impacted by the inaccessible fixed route service.

The Easter Seals Project ACTION site has a good FAQ on these issues:

http://projectaction.easterseals.com/site/PageServer?pagename=ESPA_faq&s_esLocation=faq_

Also, check out the FTA - Civil Rights - ADA page:

http://www.fta.dot.gov/civilrights/civil_rights_2360.html

The take-away from all of this is that it is ok for agencies to have stops or trips that are inaccessible as long as they are meeting their ADA regulatory requirements through other means.

Brian

[Bernard Au]

Technically the provision of accessible or inaccessible stop data on Google Transit should have no bearing on the legality of FTA funding requirements. If I understand (correct me if I am wrong) there is a formal data/information process collected on ADA compliance in order to determine FTA funding. Having said that, this is best for transit systems to individually consult their funding coordinator and legal team for proper guidance.

[T Sobota]

Brian-

(Apologies to Google Transit users outside the US for this continued discussion that has been centered on an aspect of American accessibility regulations)

  The specific regulatory language that exists in the United States, which has caused my concern with only using a simple binary yes/no accessibility coding (and would seem to echo Marcy's concern about flagging stops as "inaccessible" creating compliance concerns) is the American's with Disabilities Act Section 37.167 part G:

(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.

  An interpretation to be drawn from this language would be that every bus stop should be available for use by passengers in wheelchairs, except where the lift would be damaged by deploying it.  My recollection is that there may have been accompanying clarification language further noting that entities should probably review the continued use of any stop location that could be termed "inaccessible" - i.e where a lift would be damaged - and an alternative/replacement site should be encouraged.

  I would agree with the observation that bus stop locations are not required to meet design standards for accessibility, but the regulation would seem to be stating that regardless of the conditions at the stop (be it fully compliant with accessible design standards, only partially so, or anything short of threatening damage to the lift) a wheelchair cannot be refused usage of the vehicle lift.  Under that scenario, both bus stops meeting accessible design standards as well as stops not meeting them would seem to need to be coded as accessible (to signal to developers and end users that a wheelchair would be permitted to use the vehicle lift to enter/exit the vehicle).  The yes/no coding (based on ability to deploy vehicle lift) fails to capture what is probably the more beneficial piece of information, namely will the wheelchair passenger be using a stop that is compliant with accessible design standards or not.

  On some level, it could comparable to bus stops with shelters to those without.  A passenger can wait for the bus at any stop, but it would be beneficial to have the option to filter stops on a cold or rainy day to those that have a shelter.

[Brian Ferris]

I am not a lawyer or an expert in US public transit ADA compliance, so I'll certainly defer to the experts here, but how do you interpret "unless the lift cannot be deployed"?  Does that cover only the case of "the lift is broken on this particular bus" or more general cases like "the curb configuration at this stop makes deployment impossible" or other at-stop issues.  If it's the more general case, then that seems to suggest that some stops may in fact be inaccessible.  That is to say, it's a decision left to the transit agency to say "We can't deploy a lift at this stop so let's potentially mark it as inaccessible."  In those cases, I'd hope an agency would mark the stop as inaccessible in the GTFS feed.

Coming back to your main argument:

The yes/no coding (based on ability to deploy vehicle lift) fails to capture what is probably the more beneficial piece of information, namely will the wheelchair passenger be using a stop that is compliant with accessible design standards or not.

I don't think the "yes/no" flag is solely a function of whether the lift can be deployed at a stop, though if a lift COULDN'T be deployed, I'd hope an agency would mark a stop as inaccessible.  Ultimately, it will be up to each agency to decide if a stop is accessible based on their own determination of accessibility, which would hopefully capture a number of factors.  Ultimately, the "yes/no" flag is a simplification of a complex decision that may not be ideal for a few edge cases but will hopefully be generally useful for a rider without overwhelming them with options.

Thanks,

Brian

--

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/-/7vHME5rrXZkJ.

[John L]

MTA Metro-North Railroad

I am one of the author's of our feed.

We use wheelchair_accessible in the purest form, not ADA or other standards. We use this in the stops and trips.

If a wheelchair can egress to all platforms at a station, we consider that station wheelchair accessible. This can be any combination of ramps and elevators. Our station URL shows the facility amenities and in those cases where it is not fully accessible, directions to the nearest station is provided.

We chose to put it in the trip as a way of identifying vehicle accessibility. All our trains have atleast one coach that has wheelchair seating. We felt that if we provided schedules for other transit properties that we would run, might not have wheelchair capabilities. This would give that opportunity.

Full ADA, or other, compliance is a different animal altogether.  Wheelchair is common to any requirement however.

Going to an extreme, and adding levity,  if incontinence made it onto the ADA list, public bathrooms would have to be provided at all stations to meet that requirement.

Although possible to code for, if the compliance changes, having a simple yes/no will not cut it. Adding station amenities is really where this is heading if it needs to be that complex.

So if a station has three platforms, one being an island platform, you would atleast need one ramp and three elevators to say that station is wheelchair compliant. A public bathroom would make it incontinent compliant ;) This gets very complicated very quickly.

I for one do support the wheelchair_accessible column because it does cut across all compliance needs and presents the most hindrance for a passenger to use public transit.

[T Sobota]

My ultimate goal is that the data our agency supplies does not create type two errors for (wheelchair) passengers.

To the extent there is:

True Positive result (passenger has positive accessible experience at a stop coded as accessible)

True Negative result (passenger avoids a negative accessible experience at a stop coded as inaccessible - i.e. they do not attempt to use a stop where the lift cannot be deployed because it would result in damage)

False Positive, or Type 1 error result (passenger has a negative accessible experience at a stop coded as accessible - i.e. lift could have been deployed onto roadway surface, but they then would have needed to travel down the live traffic lane two hundred feet to reach a driveway apron to get up off the street and onto the closest sidewalk)

False Negative, Type 2 error result (passenger avoids what could have been a positive accessible experience at a stop coded as inaccessible - i.e. lift could have been deployed onto the shoulder of the road at bus stop right next to their destination, but closest stop with an accessible physical environment - sidewalks, etc. - was a mile further away)

If our interpretation of applicable regulations is that the wheelchair lift must be deployed regardless of the physical environment at the stop (except due to temporary conditions making it unsafe for any passenger, or that if deploying the lift would cause damage to the lift) - any attempt to code bus stops as inaccessible for any reason other than the potential damage caused to the lift if used at that particular stop could potentially create false negative errors for passengers... which could be interpreted as the transit agency prohibiting service to passengers needing use of the wheelchair lift, to the extent the data caused the passenger to be directed away from using those stops.