GTFS/GTFS+ deficiencies in specifying accessible stops
296 views
Skip to first unread message
Charles_Belov_SFMTA
Apr 12, 2019, 6:55:28 PM4/12/19
to Transit Developers
I'm noticing some differences between the accessible stop (wheelchair boarding) situation at our agency and the ability of GTFS/GTFS+ to specify those differences. Specifically:
- There are stops which are technically legally accessible from an ADA standpoint but which we don't recommend that people needing ADA access use because they present physical challenges.
- There is a stop that is accessible to accessible streetcar trips but not to accessible bus trips. This means that accessible trips to this accessible stop cannot provide accessibility.
- There are several stops that are accessible to accessible bus trips but not to accessible streetcar trips.
- Pertinent to the previous two items, we occasionally have unscheduled replacements of one or more streetcar trips with bus trips. These are not reflected in the GTFS file.
As for the abilities of the GTFS and GTFS+ files to record these:
stops.txt has a wheelchair boarding field with 3 values:
0/empty - no info
1 - some vehicles can board wheelchairs here
2 - no vehicles can board wheelchairs here
trips.txt has a wheelchair accessible field with 3 values:
0/empty - no info
1 - vehicle can accommodate at least one wheelchair on this trip
2 - no riders in wheelchairs can be accommodated on this trip
stop_times.txt has no information about accessibility
Deficiencies as follows:
- No way to indicate that a stop is accessible if the rider insists but that it is better if the rider chooses a different stop. This could be handled with additional field values.
3 - Stop is accessible under the ADA but may present challenges to use.
- No way to indicate that a particular accessible stop is accessible for a particular accessible trip. This could be handled with an optional accessibility override value in the stop_times file.
0/empty - no override
1 - this stop is accessible for this trip
2 - even if this stop is accessible for some vehicles and the vehicle for this trip is accessible, this stop is not accessible for this trip/vehicle
4 - this stop is normally accessible for this trip; there is the possibility of the stop not being accessible on this trip due to vehicle substitution, even if the substitute vehicle is accessible
Additionally, the case of the stop not being accessible on a particular trip due to vehicle substitution could be handled by an additional field in StopTimeUpdate, perhaps WheelchairRelationship:
SCHEDULED Accessible or not in accordance with the GTFS file.
NOT ACCESSIBLE Even if this stop is normally accessible for this trip, it will not be accessible for this trip.
ACCESSIBLE Even if this stop is normally not accessible for this trip, it will be accessible for this trip.
NO_DATA No data is given for this stop.
Details follow:
With regard to San Francisco's Market Street island stops:
Accessible to historic streetcars (F-line streetcar trips) but not to buses (F-line bus substitution trips, all other routes):
- Inbound, Market @ 5th
Accessible to buses (F-line bus substitution trips, all other routes) but not to historic streetcars (F-line streetcar trips):
- Inbound, Market @ 9th
- Inbound, Market @ 6th
- Outbound, Market @ 2nd
- Outbound, Market @ Larkin/Hayes
All remaining Market Street island stops are either accessible to all vehicle types or not accessible to any vehicle type, and are therefore outside the scope of this post.
Guillaume Campagna
Apr 13, 2019, 8:54:34 PM4/13/19
to Transit Developers
Hi Charles,
See the responses below :
- There are stops which are technically legally accessible from an ADA standpoint but which we don't recommend that people needing ADA access use because they present physical challenges.
This seems to me like a problem that shouldn’t really be solved. If SFMTA thinks that wheelchair users should go to these stops, mark those as accessible. If you don’t want wheelchair users to go there, mark those as inaccessible (even if it’s possible but difficult).
I don’t think adding a third value will fix this problem because it’s not information that’s actionnable for consumers.
- There is a stop that is accessible to accessible streetcar trips but not to accessible bus trips. This means that accessible trips to this accessible stop cannot provide accessibility.
- There are several stops that are accessible to accessible bus trips but not to accessible streetcar trips.
This can be fixed by having two stops in the gtfs with the exact same attributes except for
accessibility. One stop can be used for streetcar and the other for bus or vice-versa.
- Pertinent to the previous two items, we occasionally have unscheduled replacements of one or more streetcar trips with bus trips. These are not reflected in the GTFS file.
For real time updates, this was proposed a year ago but was dropped by lack of agencies support https://github.com/google/transit/pull/87.
Hope this helps,
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
T Sobota
Apr 19, 2019, 11:58:17 AM4/19/19
to Transit Developers
Our agency has taken the language of the US ADA 37.167g - as basis for encoding items in our stops.txt file:
§37.167 Other service requirements.
(g) The entity shall not refuse to permit a passenger who uses a lift to disembark from a vehicle at any designated stop, unless the lift cannot be deployed, the lift will be damaged if it is deployed, or temporary conditions at the stop, not under the control of the entity, preclude the safe use of the stop by all passengers.
wheelchair_boarding=1 indicates the location in stops.txt fully meets design requirements of the ADA.
wheelchair_boarding=2 would indicate the location in stops.txt is barred from accessible (lift) usage due to damage that would occur, or temporary conditions preclude safe use by all passengers [no such items, in our feed, to my recollection]
wheelchair_boarding=0 thus indicates the location does not fully meet design requirements of the ADA, but accessibility equipment (i.e. vehicle lift or ramp) can be deployed, without damage, if requested.
Charles_Belov_SFMTA
Nov 28, 2022, 8:36:42 PM11/28/22
to Transit Developers
@guillame -
Thank you for that suggestion, and it has been suggested within our agency as well.
However, in the three years since that post, we have increased our use of web pages on our website for each individual stop, as well as provided a shortcut to the stop webpage. For example, a stop affected by the accessible-to-accessible-bus, not-accessible-to-accessible-tram is the stop at 43rd & Judah, stop ID 15214, shortcut SFMTA.com/15214, full URL https://www.sfmta.com/stops/judah-st-43rd-ave-15214.
If we give that stop two different stop IDs then we have to post two signs at the stop which identify the stop ID, one for bus and one for rail. That will be confusing to customers. While we could in theory update our website to show both stop IDs on the same webpage, third-party apps would have to reprogram as well to handle this in a way that was customer-friendly. It also makes it harder for a customer to pick out the right stop from a map, since both stops are in the same place from a lat-long perspective.
It would be much better if GTFS allowed a single stop to be fully described accurately as to accessibility.
Brian Ferris
Nov 29, 2022, 11:53:30 PM11/29/22
Out of curiosity, I'm wondering what the "suggestion" was here as it didn't seem to be captured in the email thread. Unless it was Tim's suggestion from 2019?
--
You received this message because you are subscribed to the Google Groups "Transit Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/transit-developers/4b533693-a261-43bd-a5cd-c5a4443f77c2n%40googlegroups.com.
David Weinzimmer
Dec 9, 2022, 12:38:57 PM12/9/22
It's the message before that in the thread https://groups.google.com/g/transit-developers/c/njDvKUvB2vY/m/iK1pQxTxBQAJ suggesting making two separate stops, and yes it's a suggestion from (April 13th) 2019.
To view this discussion on the web visit https://groups.google.com/d/msgid/transit-developers/CAG9YwWD0cqYZVEPBVLrPuDp_vU-KY_eTqcVSFtL4u_0BDsJSOQ%40mail.gmail.com.
Brian Ferris
Dec 9, 2022, 3:28:43 PM12/9/22
To be more specific on guillame's original proposal, have you considered using station-platform hierarchy for this situation? For the Judah St & 43rd Ave example, I see there are two separate platforms on the street, one for buses and one for the tram. That could be modeled as one parent station, with a stop_code matching the ID posted at the stop, and then individual platforms for the two travel modes, one marked as accessible and the other not. That would allow you to keep one effective stop for rider communication, but allow routing engines to consider the accessibility of each platform separately. Totally understood that your systems might not be able to handle this modeling, but to your point:
It would be much better if GTFS allowed a single stop to be fully described accurately as to accessibility.
I think this style of modeling is the closest match to what's actually happening on the ground. If it really was the same physical boarding location with different accessibility properties depending on mode, then I'd agree we might need something like an accessibility value in stop_times.txt.
To view this discussion on the web visit https://groups.google.com/d/msgid/transit-developers/CAPAGZNaNhhwVd%3DQs0k4gps5JFgNA6r%2BmKbpB7zzc%3DvNn4Tmt9A%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages