Proposal: wheelchair_accessibility - revisted

[Brian Ferris]

It's been a while, but I'd like to revisit the wheelchair accessibility proposal.  When we last left the proposal back in September:

https://groups.google.com/group/gtfs-changes/browse_thread/thread/23343ee3a69e66e3

there was a lot of discussion about shades of accessibility and whether the current proposal had truly been properly vetted.  Since then, I've been working to find more support for the proposal.  For the purpose of this discussion, I'd like to focus on the wheelchair accessibility proposal just for stops.  If you'll recall, the current proposal is to add the following to the stops.txt 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

In the previous discussion, it was pointed out that there were no agencies with public GTFS feeds using the full specification.  I'm happy to announce that the San Diego Metropolitan Transit System has now added wheelchair accessibility info for all stops to their public GTFS feed.  Their feed uses all three "wheelchair_boarding" values, giving developers a chance to play with real-world data for a large agency.

In terms of GTFS consumers, I'd mention the following:

1) Google Maps continues to use the wheelchair_boarding field to show a wheelchair accessibility icon for transit stops on maps.

2) OpenTripPlanner properly handles wheelchair_boarding for planning accessible transit routes.

3) OneBusAway also uses the wheelchair_boarding field to indicate wheelchair accessibility at a stop, with a custom UI message for all three values.

At this point, we've got an agency with a public GTFS feed using the proposed feature and a number of applications that can consume this data.  I'd like to test the waters to see how people feel about the proposal.

Note that I'm purposely leaving the trips.txt wheelchair_accessible portion of the proposal off the table at this point.  I'm still working on finding more public data that uses this feature in a meaningful way.

Thanks,

Brian

[John L]

Not to /patself but NY MTA Metro-North Railroad uses wheelchair_boarding in the trips.txt and wheelchair_accessible in the stops.txt since 1/2011. (i may have tranposed the field names, have not looked at it in a while)

The vehicle is the easy part of the equation for rail as we have data regarding the number of wheelchair seating on the car. There really are three designations needed for this, 1 no vehichle(s) are accessible or 2 atleast 1 or more vehicle(s) is accessible. 0 or null for unknown.

The difficult part is if the station is wheelchair accessible.

What I mean by this is, can a wheelchair be used to access all platforms or put another way can  board and disembark from any vehicle that stops at a station; Partially, meaning at least one platform can be used; or not wheelchair accessible. Or as noted, no info is available.

Only with these two bits of information can you truly say a journey is entirely, partially or not at all accessible to wheelchairs.

The one caveat here is, this is what is scheduled, not what will happen. I dont think we have any vehicles without wheelchair seating so we are pretty confident that using this data is valid. The stations may be under renovation whichay change accessibility but that would be addressed in a different feed.

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

[Brian Ferris]

Hey John,

Thanks for making you data available!  I missed your feed in my survey because I think you might have the field names backwards?  It should be 'wheelchair_boarding' in stops.txt and 'wheelchair_accessible' in trips.txt.  Any chance you could update the feed?

Thanks,

Brian

[Brian Ferris]

John also raises a larger question that I had meant to bring up in my origin email: wheelchair accessibility for stations.

Right now, the proposal doesn't say much about what should happen when a feed uses stop-station hierarchy.  My interpretation would be that if a stop that is part of a larger station complex has been marked as "wheelchair_boarding=1", then there is some accessible path from outside the station to the specific stop / platform.  By the same token, if a stop has been marked with "wheelchair_boarding=2", there there is no accessible path from outside the station to the specific stop / platform.  These semantics would hold true no matter what value of "wheelchair_boarding" has been specified for the parent station.

I think the one grey area is what happens when a stop has a "wheelchair_boarding" value of "0" or blank (aka unknown) but the parent  station has a known "wheelchair_boarding" value.  One interpretation would be to let the parent station value propagate down to the child stop.  This would potentially make it easier for feed producers, but I think it's problematic because it's not clear how to explicitly specify that a child stop has an "unknown" wheelchair_boarding value if the parent station "wheelchair_boarding" value has already been set.

Another approach is to just treat the "wheelchair_boarding" as sort of a general summary of accessibility that agencies and applications might use when displaying a station summary page or map icon, but to require "wheelchair_boarding" to be explicitly set of child stops when it comes to routing decisions (aka no propagation of accessibility from station to stop).  I think this is the approach used in the NaPTAN spec, if I'm reading it correctly.  I also think I prefer this approach.

Finally, there is the question of specifying wheelchair accessibility for paths between stops or between entrances and stops at a specific station.  As some have pointed out before, there are situations where a platforms at a particular station are not specifically accessible from outside the station, but accessible transfers within the station are possible.  The pathways proposal attempts to address this, but I think that's something for a follow-up discussion.

Thanks,

Brian

On Thu, Mar 8, 2012 at 2:33 AM, John L <lars...@gmail.com> wrote:

[Brian Ferris]

Just to bump this to the top again, any one have any comments?  Objections?  TL;DR?

[Dave Barker, MBTA]

I'd love to see accessibility info added to the official spec. Of the
two options presented for how to address parent/child relationships I
prefer the latter (no propagation) because as you suggested an agency
might want to leave a child stop unspecified even as the parent
station is marked as being accessible. I also imagine it would be
slightly simpler for developers as it saves them from adding logic to
propagate accessibility down under certain circumstances.

As for accessibility of paths between stops, was adding accessibility
informatino to transfers.txt

-Dave Barker

Regarding paths between entrances and exits,

> > On Thu, Mar 8, 2012 at 2:33 AM, John L <larse...@gmail.com> wrote:
>
> >> Not to /patself but NY MTA Metro-North Railroad uses wheelchair_boarding
> >> in the trips.txt and wheelchair_accessible in the stops.txt since 1/2011.
> >> (i may have tranposed the field names, have not looked at it in a while)
>
> >> The vehicle is the easy part of the equation for rail as we have data
> >> regarding the number of wheelchair seating on the car. There really are
> >> three designations needed for this, 1 no vehichle(s) are accessible or 2
> >> atleast 1 or more vehicle(s) is accessible. 0 or null for unknown.
>
> >> The difficult part is if the station is wheelchair accessible.
>
> >> What I mean by this is, can a wheelchair be used to access all platforms
> >> or put another way can  board and disembark from any vehicle that stops at
> >> a station; Partially, meaning at least one platform can be used; or not
> >> wheelchair accessible. Or as noted, no info is available.
>
> >> Only with these two bits of information can you truly say a journey is
> >> entirely, partially or not at all accessible to wheelchairs.
>
> >> The one caveat here is, this is what is scheduled, not what will happen.
> >> I dont think we have any vehicles without wheelchair seating so we are
> >> pretty confident that using this data is valid. The stations may be under
> >> renovation whichay change accessibility but that would be addressed in a
> >> different feed.

> >> On Mar 7, 2012 7:38 PM, "Brian Ferris" <bdfer...@google.com> wrote:
>
> >>> It's been a while, but I'd like to revisit the wheelchair accessibility
> >>> proposal.  When we last left the proposal back in September:
>

> >>>https://groups.google.com/group/gtfs-changes/browse_thread/thread/233...

[Dave Barker, MBTA]

Apologies for the incomplete message posted, complete message
follows.

I'd love to see accessibility info added to the official spec. Of the
two options presented for how to address parent/child relationships I
prefer the latter (no propagation) because as you suggested an agency
might want to leave a child stop unspecified even as the parent
station is marked as being accessible. I also imagine it would be
slightly simpler for developers as it saves them from adding logic to
propagate accessibility down under certain circumstances.

As for accessibility of paths between stops, was adding accessibility

information to transfers.txt considered? Street access could always go
by the stop's accessibility flag; transfers could go by the least-
accessible level of the two stops, unless the transfer appears in the
transfers.txt file and that file has an accessibility column, in which
case the level of accessibility specified there is used.

-Dave Barker

[Brian Ferris]

Hey Dave,

There was some discussion in the past about using transfers.txt.  One of the edge-cases that someone mentioned was the situation where a station platform was marked as inaccessible (wheelchair_boarding=2) but an accessible transfer is possible at that platform (two different trains both stop at the platform).  If we used transfers.txt, we'd have to indicate a transfer where the from and to stop ids are the same, which seems a little strange.  It's also not clear what would happen if the trip-to-trip transfers proposal was adopted, where we'd now potentially have multiple transfers.txt entries with the same stop pairs (some with routes/trips, some without).  Where would the accessibility option be indicated?  For those reasons, I worry about using transfers.txt to model this information.  I think the pathways proposal is probably the best way to handle the use-case.

Brian

[tompw]

On Thursday, March 8, 2012 5:15:44 AM UTC-5, Brian Ferris wrote:

John also raises a larger question that I had meant to bring up in my origin email: wheelchair accessibility for stations.

Right now, the proposal doesn't say much about what should happen when a feed uses stop-station hierarchy.  My interpretation would be that if a stop that is part of a larger station complex has been marked as "wheelchair_boarding=1", then there is some accessible path from outside the station to the specific stop / platform.  By the same token, if a stop has been marked with "wheelchair_boarding=2", there there is no accessible path from outside the station to the specific stop / platform.  These semantics would hold true no matter what value of "wheelchair_boarding" has been specified for the parent station.

I think the one grey area is what happens when a stop has a "wheelchair_boarding" value of "0" or blank (aka unknown) but the parent  station has a known "wheelchair_boarding" value.  One interpretation would be to let the parent station value propagate down to the child stop.  This would potentially make it easier for feed producers, but I think it's problematic because it's not clear how to explicitly specify that a child stop has an "unknown" wheelchair_boarding value if the parent station "wheelchair_boarding" value has already been set.

 

I think the general approach should be that a child value over-rides a parent value, and the parent value should only be applied when its children have blank/zero values.

[RTC_Québec]

Hi all,

Just to let you know that Réseau de transport de la Capital (RTC),
currently provides stops.txt and trips.txt with wheelchair
accessibility and wheelchair boarding for the Quebec City area. The
feed is available on GTFS Exchange.

Regards,

Bernard

> > On Mar 7, 2012 7:38 PM, "Brian Ferris" <bdfer...@google.com> wrote:
>
> >> It's been a while, but I'd like to revisit the wheelchair accessibility
> >> proposal.  When we last left the proposal back in September:
>

> >>https://groups.google.com/group/gtfs-changes/browse_thread/thread/233...

[Brian Ferris]

I'd like to take another stab at building consensus on the wheelchair accessibility proposal.  Here is the updated proposal for stops.txt with some additions for stop-station hierarchy:

wheelchair_boarding (optional) 

The "wheelchair_boarding" field identifies whether wheelchair boardings are possible from the specified stop or station.  The field can have the following values:

"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

When a stop is part of a larger station complex, as indicated by a stop with a "parent_station" value, the stop's "wheelchair_boarding" field has the following additional semantics:

"0" (or empty) - the stop will inherit its "wheelchair_boarding" value from the parent station, if specified in the parent

"1" - there exists some accessible path from outside the station to the specific stop / platform

"2" - there exists no accessible path from outside the station to the specific stop / platform

For a station, specifying a "wheelchair_boarding" field value can be used to indicate a default wheelchair boarding value for the station's stops that have no "wheelchair_boarding" value specified.  Otherwise, the station's wheelchair boarding value is purely descriptive and should not be used in computing wheelchair accessible routes.

Thoughts?

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

[David Turner]

I don't understand how this lets us handle NYCT's stop Q01, the Canal St
N/Q platform. That platform allows transfers between the N and the Q
(that is, wheelchair boarding and alighting are possible), but does not
allow access to the outside world.

>
>

[Nicholls, Gregory]

I don't see a practical value in specifying the value 1. This translates into 'you may of may not be able to board with a wheelchair .. depending'. My rule is that if you can't make a decision it isn't information, it's just data <grin>.

    I'd recommend that the stops.txt contain flags for station/platform facilities only. If you want to cater for vehicle facilities I'd place the flags in trips.txt. The reasoning is that the question you want to be able to answer is 'Can I get on this service with a wheelchair ?'  For us (rail) this is easy since the timetable describes the class of rolling stock that is required for any given trip and the facilities are general to a class of rolling stock. I'm not sure if buses work the same way.

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Brian Ferris
Sent: Tuesday, 17 April 2012 6:46 PM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Proposal: wheelchair_accessibility - revisted

[Brian Ferris]

Agreed, it does not cover this use case.  You'll need something like the pathways proposal for that.

Just to be clear, this proposal doesn't cover all edge cases of wheelchair accessible routing.  However, variations of this proposal have been around for four years at this point (really - https://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f8fa7c4cc8430).  Feed producers and consumers are starting to implement various flavors of the proposal, which is just leading to confusion and incompatibility.  I'd like to come to some sort of consensus on the parts of the wheelchair accessible routing proposal that we can agree on now and focus on the additional parts after.  To me, there seems to be a fair amount of consensus on how we'd model wheelchair boarding at stops in the general case, which is why I'm pushing this proposal for formal adoption.

Brian

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

[Brian Ferris]

A "1" value indicates that wheelchair boardings are possible from the specified stop.  However, that doesn't mean that every vehicle serving that stop will be wheelchair accessible, thus the "at least some..." language.  The wheelchair accessibility of a particular trip is covered by the "wheelchair_accessible" trips.txt proposal, described elsewhere, which I'd like to follow up on if we can come to some consensus on the stops.txt proposal.

Brian

[David Turner]

On Wed, 2012-04-18 at 10:29 +0200, Brian Ferris wrote:
> Agreed, it does not cover this use case. You'll need something like
> the pathways proposal for that.
>
>
> Just to be clear, this proposal doesn't cover all edge cases of
> wheelchair accessible routing. However, variations of this proposal
> have been around for four years at this point (really
> - https://groups.google.com/group/gtfs-changes/browse_thread/thread/f98f8fa7c4cc8430). Feed producers and consumers are starting to implement various flavors of the proposal, which is just leading to confusion and incompatibility. I'd like to come to some sort of consensus on the parts of the wheelchair accessible routing proposal that we can agree on now and focus on the additional parts after. To me, there seems to be a fair amount of consensus on how we'd model wheelchair boarding at stops in the general case, which is why I'm pushing this proposal for formal adoption.

Can you tell us how the various wheelchair fields are used in the feeds
which Google indexes? Or at least what values are used?

Because I don't think it will hurt anything to handle the Canal St case,
and OTP already supports that case (as wheelchair_boarding=2 IIRC).

I don't think there are any producers or consumers for the new proposal,
right?

[David Turner]

(1) I checked, and apparently OTP doesn't actually support the Canal St
case. I can and will change this as soon as there is a feed producer.
Also, the value for wheelchair_boarding should be 3, not 2.

I would like to know if any feed in Google's dataset presently uses
wheelchair_boarding=3, and if so, if anyone knows what for.

(2) Is there a feed producer that would be willing to add
wheelchair_boarding=3 where applicable to their feed? If you are
willing but need some data input help to do this, I'm happy to provide
that help for reasonably sized systems (e.g. any subway or rail system)
where the necessary information is on the web in English.

[Nicholls, Gregory]

Are you considering including any other facilities (eg. AFILS) or is it just wheelchair access ? I ask because if so, there may be a case for a 'facilities.txt' file ..

    Greg.

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Brian Ferris

Sent: Wednesday, 18 April 2012 6:33 PM

[Brian Ferris]

So, just to clarify, a stop with a wheelchair boarding value of "3" would have the following semantics?

"3" - wheelchair boarding from the street is not possible at this stop, but wheelchair transfers between vehicles at this stop are possible

I'm inclined to push for adoption of the proposed 0,1,2 semantics, since we have feed consumers and producers already using this functionality.  I think the additional 3 semantics could wait until there is an agency willing to produce such data and a consumer how has tried it out.

Brian

[Brian Ferris]

What does the AFILS acronym stand for?

[Nicholls, Gregory]

Sorry,

    Audio Frequency Induction Loop System. It basically feeds Passenger Information audio into people's hearing aids. It is present on some of our platforms & station concourses as well as some classes of rolling stock.  

 Greg.

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Brian Ferris

Sent: Thursday, 19 April 2012 8:05 AM

[Brian Ferris]

I think that's outside the scope of the current proposal.

[David Turner]

Even though that's out of scope for the wheelchair_boarding proposal, I
would like to read your thoughts on other accessibility data.

My primary use of GTFS is writing trip-planning software. I don't know
what changes I would make to a route based on the presence or absence of
AFILS. Is there another customer-information use of the AFILS data?
Or of other accessibility data that agencies are likely to have?

On Thu, 2012-04-19 at 07:41 +1000, Nicholls, Gregory wrote:
> Are you considering including any other facilities (eg. AFILS) or is
> it just wheelchair access ? I ask because if so, there may be a case
> for a 'facilities.txt' file ..
> Greg.
>
>

> ______________________________________________________________________

> ______________________________________________________________

> +unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
> --
> 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

> +unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
>
> --
> 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

> +unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/gtfs-changes?hl=en.
>
>
> --
> 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

> +unsub...@googlegroups.com.

[Nicholls, Gregory]

I brought up the AFILS case to point out that there is more than one type of facility that falls into the 'disabled assistance' class. Selecting wheelchair access over other types of disabled assistance seems arbitrary. This is not to mention all the other types of facilities that help passengers navigate a network.

If you're not considering any other facilities in the future then the current proposal is fine. I'm wondering if it might be worthwhile folding the wheelchair proposal into a more general proposal around the inclusion of stop/trip facility information ?

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Brian Ferris

Sent: Thursday, 19 April 2012 8:22 AM
To: gtfs-c...@googlegroups.com
Subject: RE: [gtfs-changes] Proposal: wheelchair_accessibility - revisted

[Nicholls, Gregory]

Re: Your AFILS question. The simple case would be someone who is hearing impaired preferentially selecting journeys that are serviced by rolling stock that is AFILS equipped. The real value for these sorts of things is communicating during disruptions.

If we restrict discussion to the facilities that might be useful in journey planning we've got the following as examples :-
Wheelchair Accessible - already discussed
AFILS - just covered
Lifts - This is both whether a station/platform has lifts and their current operational status.
Car Park - Does the station have an attached car park
Interchange - Is this station a multi-modal interchange

There are also attributes of trips and rolling stock that we are calling facilities (probably out of laziness).
AFILS again - Rolling stock 'facility'
Toilets - Rolling stock 'facility'
air conditioning - Rolling stock 'facility'
Guardian service - Trip 'facility' - late night service with additional security.
Quiet cars - Trip 'facility' with quiet (ie no cellphones allowed) cars.

There are a lot more but the others are probably of less use during planning.

Greg.

-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of David Turner
Sent: Thursday, 19 April 2012 8:55 AM
To: gtfs-c...@googlegroups.com

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[David Turner]

Do you know of agencies that would be able to provide this info, if
there were a standard?

[Nicholls, Gregory]

Well we have all that information available and already use some of it in a limited form. Unfortunately I'm not in a position to promise a GTFS feed .. I'm researching it for suitability but the actual decision exceeds my pay grade <grin>.

[Brian Ferris]

In terms of facility information like this, I think I would model it as an additional column in stops.txt, routes.txt, or trips.txt, depending on the context.  As always, if we can find an agency willing to provide it and a developer wishing to use, it's all potentially fair game for adding to the spec.

Brian

[Brian Ferris]

It's time for my monthly push to get the wheelchair accessibility proposal officially added to the spec.  TL;DR?  I'm starting the clock, officially adding this to the spec on Wednesday, June 20th unless I hear otherwise from the community.

For those of you new to the list (more and more every day!), here's a quick recap of the proposal:

Add the following field to stops.txt:
wheelchair_boarding (optional) 

 

The "wheelchair_boarding" field identifies whether wheelchair boardings are possible from the specified stop or station.  The field can have the following values:

 

"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

 

When a stop is part of a larger station complex, as indicated by a stop with a "parent_station" value, the stop's "wheelchair_boarding" field has the following additional semantics:

 

"0" (or empty) - the stop will inherit its "wheelchair_boarding" value from the parent station, if specified in the parent
"1" - there exists some accessible path from outside the station to the specific stop / platform
"2" - there exists no accessible path from outside the station to the specific stop / platform

And here's a recap of what's been discussed but's NOT in the proposal at this time:

1. Details on wheelchair accessible trips.

2. The "3" proposal - wheelchair boarding from the street is not possible at this stop, but wheelchair transfers between vehicles at this stop are possible

3. Pathway-leve detail of accessibility, as proposed to be modeled with the pathways.txt proposal.

4. More fine-grained, agency-specific accessibility information.

5. Other issues discussed in this thread and past threads https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/IzQ-46aeZuM

To be clear, I'm choosing to focus on stop accessibility only at this time not because I think these other aspects are unimportant.  Rather, we have a number of agencies providing GTFS data that used the proposed wheelchair_boarding feature at this point and multiple GTFS feed consumers who can use it.  I think we have consensus on the stop accessibility proposal as outlined and I'd like to make that official before we tackle these other issues.

Thoughts?

Thanks,

Brian

[Matt Conway]

Looks good. Should there be a category for stops where all vehices can be boarded by wheelchairs, guaranteed?

[Brian Ferris]

So to clarify, the wheelchair accessibility of a boarding / alighting is a function of the stop and the vehicle.  The "1" value indicates that the stop itself is accessible, but it doesn't make any claim about the vehicle that might be serving the stop.  The "wheelchair_accessible" flag that's been proposed for trips.txt would cover the vehicle.  Specifying "1" for both the stop and all the trips serving that stop would cover the "all" case.  That said, I'm focusing on stops since we have a lot more agencies using that field at this point.

Brian

[Matt Conway]

 Brian,
Thanks! I apologize for the misunderstanding.
-Matt

[David Turner]

The same is true for transit outages of all sorts. Perhaps
GTFS-realtime should be extended to support adjustments to these
values?


On Mon, 2012-06-18 at 07:00 -0700, Aaron Steinfeld wrote:
> One observation for everyone, and I'm not well versed enough in the GTFS spec to interpret this, is that it may be necessary to use an alternate method for temporary elevator/escalator outages. These may only last a day or less, so it doesn't make sense to use the static GTFS for such outages. Therefore, we may want to spec that this change is tied to the expected accessibility (i.e., assuming all escalators and elevators are in good repair, the accessibility is...).
>
>
> On Wednesday, June 13, 2012 4:44:22 PM UTC-4, Brian Ferris wrote:
> > <font size="2">It&#39;s time for my monthly push to get the wheelchair accessibility proposal officially added to the spec. TL;DR? I&#39;m starting the clock, officially adding this to the spec on Wednesday, June 20th unless I hear otherwise from the community.
> >
> >
> > </div>
> > For those of you new to the list (more and more every day!), here&#39;s a quick recap of the proposal:</div>
> >
> > </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

> > Add the following field to stops.txt:

> > wheelchair_boarding (optional)<WBR>
> > </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> > </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The &quot;wheelchair_boarding&quot; field identifies whether wheelchair boardings are possible from the specified stop or station. The field can have the following values:
> >
> > </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> > &quot;0&quot; (or empty) - indicates that there is no accessibility information for the stop
> > &quot;1&quot; - indicates that at least some vehicles at this stop can be boarded by a rider in a wheelchair
> > &quot;2&quot; - wheelchair boarding is not possible at this stop
> >
> > </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> > When a stop is part of a larger station complex, as indicated by a stop with a &quot;parent_station&quot; value, the stop&#39;s &quot;wheelchair_boarding&quot; field has the following additional semantics:
> > </blockquote>
> > <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
> > &quot;0&quot; (or empty) - the stop will inherit its &quot;wheelchair_boarding&quot; value from the parent station, if specified in the parent
> > &quot;1&quot; - there exists some accessible path from outside the station to the specific stop / platform
> >
> > &quot;2&quot; - there exists no accessible path from outside the station to the specific stop / platform</blockquote>
> >
> > </div>
> > And here&#39;s a recap of what&#39;s been discussed but&#39;s NOT in the proposal at this time:</div>
> >
> >
> > </div>
> > 1. Details on wheelchair accessible trips.</div>
> > 2. The <span>&quot;3&quot; proposal - wheelchair boarding from the street is not possible at this stop, but wheelchair transfers between vehicles at this stop are possible</span></div>
> >
> > <span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">3. Pathway-leve detail of accessibility, as proposed to be modeled with the pathways.txt proposal.</span></div>
> >
> > <span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">4. More fine-grained, agency-specific accessibility information.</span></div>
> > <span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:13px;background-color:rgb(255,255,255)">5. Other issues discussed in this thread and past threads </span><font color="#222222" face="Arial, Helvetica, sans-serif"><a href="https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/IzQ-46aeZuM" target="_blank">https://groups.google.<WBR>com/forum/?fromgroups#!topic/<WBR>gtfs-changes/IzQ-46aeZuM</a></font></div>
> >
> > <font color="#222222" face="Arial, Helvetica, sans-serif">
> > </font></div>
> > <font color="#222222" face="Arial, Helvetica, sans-serif">To be clear, I&#39;m choosing to focus on stop accessibility only at this time not because I think these other aspects are unimportant. Rather, we have a number of agencies providing GTFS data that used the proposed wheelchair_boarding feature at this point and multiple GTFS feed consumers who can use it. I think we have consensus on the stop accessibility proposal as outlined and I&#39;d like to make that official before we tackle these other issues.</font></div>
> >
> > <font color="#222222" face="Arial, Helvetica, sans-serif">
> > </font></div>
> > <font color="#222222" face="Arial, Helvetica, sans-serif">Thoughts?</font></div>
> > <font color="#222222" face="Arial, Helvetica, sans-serif">
> >
> > </font></div>
> > <font color="#222222" face="Arial, Helvetica, sans-serif">Thanks,</font></div>
> > <font color="#222222" face="Arial, Helvetica, sans-serif">Brian</font></div>
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 17, 2012 at 10:45 AM, Brian Ferris <span dir="ltr">&lt;<a href="mailto:bdfe...@google.com" target="_blank">bdfe...@google.com</a>&gt;</span> wrote:
> >
> > <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> > I&#39;d like to take another stab at building consensus on the wheelchair accessibility proposal. Here is the updated proposal for stops.txt with some additions for stop-station hierarchy:</div>
> >
> >
> >
> > </div>
> > wheelchair_boarding (optional)<WBR>
> >
> >
> >
> > </div>
> > The &quot;wheelchair_boarding&quot; field identifies whether wheelchair boardings are possible from the specified stop or station. The field can have the following values:</div>
> >
> >
> > </div>
> >
> > &quot;0&quot; (or empty) - indicates that there is no accessibility information for the stop
> >
> >
> > &quot;1&quot; - indicates that at least some vehicles at this stop can be boarded by a rider in a wheelchair
> > &quot;2&quot; - wheelchair boarding is not possible at this stop</div>
> >
> > </div></div>
> > When a stop is part of a larger station complex, as indicated by a stop with a &quot;parent_station&quot; value, the stop&#39;s &quot;wheelchair_boarding&quot; field has the following additional semantics:</div>
> >
> >
> >
> >
> >
> > </div>
> > &quot;0&quot; (or empty) - the stop will inherit its &quot;wheelchair_boarding&quot; value from the parent station, if specified in the parent</div>
> > &quot;1&quot; - <span>there exists some accessible path from outside the station to the specific stop / platform</span></div>
> >
> >
> >
> >
> > &quot;2&quot; - <span>there exists no accessible path from outside the station to the specific stop / platform</span></div>
> > <span>
> > </span></div>
> > <span>For a station, specifying a &quot;wheelchair_boarding&quot; field value can be used to indicate a default wheelchair boarding value for the station&#39;s stops that have no &quot;wheelchair_boarding&quot; value specified. Otherwise, the station&#39;s wheelchair boarding value is purely descriptive and should not be used in computing wheelchair accessible routes.</span></div>
> >
> >
> >
> > <span>
> > </span></div>
> > <span>Thoughts?</span></div>
> > <span>
> > </span></div>
> > <span>Thanks,</span></div>
> > <span>Brian</span></div>
> >
> >
> >
> > </div>
> >
> > </div>
> >
> > On Tue, Apr 3, 2012 at 7:46 PM, tompw <span dir="ltr">&lt;<a href="mailto:to...@hotmail.com" target="_blank">to...@hotmail.com</a>&gt;</span> wrote:
> >
> >
> >
> > <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> >
> >
> > On Thursday, March 8, 2012 5:15:44 AM UTC-5, Brian Ferris wrote:

> > <blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">John also raises a larger question that I had meant to bring up in my origin email: wheelchair accessibility for stations.
> >
> >
> > </div>
> >
> > Right now, the proposal doesn&#39;t say much about what should happen when a feed uses stop-station hierarchy. My interpretation would be that if a stop that is part of a larger station complex has been marked as &quot;wheelchair_boarding=1&quot;, then there is some accessible path from outside the station to the specific stop / platform. By the same token, if a stop has been marked with &quot;wheelchair_boarding=2&quot;, there there is no accessible path from outside the station to the specific stop / platform. These semantics would hold true no matter what value of &quot;wheelchair_boarding&quot; has been specified for the parent station.</div>
> >
> >
> >
> >
> >
> >
> >
> >
> > </div>
> >
> > I think the one grey area is what happens when a stop has a &quot;wheelchair_boarding&quot; value of &quot;0&quot; or blank (aka unknown) but the parent station has a known &quot;wheelchair_boarding&quot; value. One interpretation would be to let the parent station value propagate down to the child stop. This would potentially make it easier for feed producers, but I think it&#39;s problematic because it&#39;s not clear how to explicitly specify that a child stop has an &quot;unknown&quot; wheelchair_boarding value if the parent station &quot;wheelchair_boarding&quot; value has already been set.</div>
> >
> >
> >
> >
> >
> > </blockquote>
> >
> > </div>
> > </div>
> > I think the general approach should be that a child value over-rides a parent value, and the parent value should only be applied when its children have blank/zero values. </div>
> >
> >
> >
> > </p>
> >
> > --
> >
> > You received this message because you are subscribed to the Google Groups &quot;General Transit Feed Spec Changes&quot; group.
> > </div>
> > To view this discussion on the web visit <a href="https://groups.google.com/d/msg/gtfs-changes/-/Ui9vWFeNojsJ" target="_blank">https://groups.google.com/d/<WBR>msg/gtfs-changes/-/<WBR>Ui9vWFeNojsJ</a>.
> >
> >
> >
> >
> > To post to this group, send email to <a href="mailto:gtfs-c...@googlegroups.com" target="_blank">gtfs-c...@googlegroups.com</a>.
> >
> > To unsubscribe from this group, send email to <a href="mailto:gtfs-changes%2Bunsu...@googlegroups.com" target="_blank">gtfs-changes+unsubscribe@<WBR>googlegroups.com</a>.
> >
> >
> > For more options, visit this group at <a href="http://groups.google.com/group/gtfs-changes?hl=en" target="_blank">http://groups.google.com/<WBR>group/gtfs-changes?hl=en</a>.
> >
> >
> >
> > </div></div></blockquote></div>
> >
> > </div></div></blockquote></div>
> > </div></div>
> > </div></div></font></div>
>

[Brian Ferris]

My two cents is that it'd be great to have that information in the spec (both static and realtime), but probably beyond the scope of this proposal.  Maybe we can start a separate thread for ideas around this?

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.

[Brian Ferris]

Ok, hearing no major complaints, I'm making this official.  The stops.txt wheelchair_boarding field is now officially part of the spec:

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

This is just a small, but important, step into getting all the data we need to plan accessible trips in GTFS, so I will keep pushing on the various proposals for accessibility information.  Thanks for all the feedback!

Brian

[Brian Ferris]

The GTFS specification supports marking the accessibility of transit stops and stations.  Check out the wheelchair_boarding field in the stops.txt file:

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

Regarding stop-station hierarchy, what ended up in the official proposal was the idea that the child stop value overrides the parent station value, but the parent station value can be used as a default value if you don't want to specify the value for all stops.

Google Maps uses this information to display wheelchair accessibility information for transit stops on Google Maps.  See, for example, this entry for Newark Penn Station in NJ:

http://goo.gl/maps/WN2SH

Note the wheelchair icon next to the stop name.  The same icon shows up on info windows on the map itself.  Another example in San Diego: http://goo.gl/maps/gsVhW

Beyond wheelchair accessibility of stops, there is also a proposal for wheelchair accessibility for trips.  See the documentation for the proposed "wheelchair_accessible" field in trips.txt described at:

http://support.google.com/transitpartners/bin/answer.py?hl=en&answer=2450962

A number of GTFS consumers use that proposed field to support features like accessible routing.

Thanks,

Brian

On Wed, Sep 5, 2012 at 8:04 AM, Catrina <catrinabl...@gmail.com> wrote:

Hi Brian,

We are looking to deploy both the Wheelchair access to stops; and to services for our GTFS feeds launched in June this year. I have not been able to find evidence of deployment by
San Diego Metropolitan Transit System or NY MTA Metro-North Railroad both of which came up in earlier discussions.

Is there someone who can  advise me in defining how these options would look in GTFS and given the Services option is still only in proposal, does this mean that we cannot deploy it?
Earlier discussions also raise prioritisation issues and suggest
 A child value  over-rides a parent value. The parent value will only be applied when its children have blank/zero values.
Or
Alternatively treat the google maps "wheelchair_boarding" as a general summary of accessibility that agencies and applications use when displaying a station summary page or map icon, but to require "wheelchair_boarding" to be explicitly set of child stops when it comes to routing decisions (ie no propagation of accessibility from station to stop).

Are one or both of these options inherent to the specifications as they stand now? - This is not clear to me in my reading of the field definitions.

Please let me know if there are sites, descriptions or screen shots available that can help us to
1.  Better define our data requirements and
2.  How things will appear at the front end for users.

Many thanks

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

[Brian Ferris]

Fixed:

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

Thanks,

Brian

On Mon, Oct 1, 2012 at 6:10 AM, alpe <ales....@gmail.com> wrote:

Brian,
will you please update the revised date on the Reference page (https://developers.google.com/transit/gtfs/reference) as well? It currently says 'Revised February 2, 2012'. This is the place I check to confirm  I'm working against the latest revision ;-)

Thanks,
Ales

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