The grant from the FTA Mobility for All Pilot Program (M4A) supported efforts to improve mobility and access to public transportation for older adults, people with disabilities, and individuals of low income, focusing on the need for standardized and computer-readable ways to describe rider eligibility and service provider capacity.
The earliest focus for transit data standards was transit aimed at the public — buses, trains, and ferries that run on fixed routes and fixed schedules. Over time, additional data standards have made it possible for providers of more flexible types of transportation (dial-a-ride services, for example) to begin to disseminate information to riders more easily.
Compared to generalized public transit, specialized transportation often needs to accommodate a wider range of mobility devices. Some specialized transportation involves picking riders up directly at their residences (possibly even providing them with assistance getting from their home to the vehicle) and dropping them off at their destination (again, with the possibility of assistance disembarking). As with eligibility factors, there is considerable variation in service capability and data standards are not yet available for this information.
There is an impact to the absence of data standards describing this complex world of service capability: The people who rely on specialized transportation have to work harder to plan how they will move through the world, whether they are going to work, medical appointments, the grocery store, or other destinations.
Capability Challenge: Aligning vehicle capabilities with rider needs and with methods used in other standards (e.g., 211 taxonomy, TCRP 210, SUTI).
The project goal was to create a solid first step and to include fields and data elements that were determined to be important (based on research into similar standards and professional experiences of contributors). The proposals are not intended to be the final work on this effort.
The following were determined to be initially important for this project: presence or absence of a ramp; ramp width if present; presence or absence of a lift; lift width, length, and weight capacity if present; dimensions of space available for a mobility device; and a description of the effect of use of a mobility device space upon seating and standing room.
Capability Challenge: Aligning vehicle capabilities with those of the overall service and taking into consideration the limited IT infrastructure of some providers/need for good tooling.
With demand-responsive services, there can be considerable variety across vehicles within a specific service. As a result, it is necessary to address the complexity of the deployment of different types of vehicles. This can involve describing the type of vehicle expected for a specific service, fora particular run or trip, or a particular stop time.
The project approach has been to give agencies choice about the level of detail they present. At the most general level, an agency might choose to indicate that a particular vehicle type (e.g., a vehicle with a bariatric lift) is part of the pool of available vehicles for this service (without specifying its availability at a particular time or place). This choice involves a lower level of effort for the agency to produce an accurate data feed. Agencies could also choose to provide more and more granular information, if they have the ability to maintain that level of detail.
Capability challenge: Consider other standards, 211 taxonomy, and other projects
In order not to reinvent the wheel, the project examined existing standards and efforts, including:
● LEX, a standard that uses URNs to describe laws and regulations
● Other draft GTFS extensions, including GTFS-vehicles, GTFS-seats, and GTFS-fares
● Mobility Data’s GOFS project
● Lessons from the 211 taxonomy, including discussion with Interface Children and Family Services staff who are responsible for the 211Ride program in Ventura County, California
● Expert panel representation from multiple DOTs (Caltrans, MNDOT, and WSDOT) and their consultants involved in other projects funded by USDOT and FTA.
Capability challenge: Support for multiple languages (i.e., to switch an entire feed from one language to another)?
The current project was not able to account for multiple languages.
GTFS-translations exist, providing the minimum ability to say, “this field is in this language.” Further work would be necessary to provide support for multiple languages under all scenarios.
Notable successes of the project:
● Resulting tools allow for descriptions of services not generally available to the public and with a wide range of service capabilities; this type of description is not currently available through GTFS
● Introduction of URNs as a way to capture local detail and nuance with a unique description that can also be a tool for coordinating at any level
● Flexibility, in that the specifications can be implemented at different levels of complexity/levels of detail
This work will have implications for stakeholders that are already part of the GTFS ecosystem (transit agencies, DOTs), as well as stakeholders that are new to GTFS, including: human service agencies, policymakers, users/riders who want to have a voice in enhancements to services they use, healthcare systems, mobility managers, and 211/information referral/aging/disability resource centers. The institutional challenges (i.e., connecting different cultures) of these efforts may be more significant than technological ones.
This project did not include rider engagement. As these standards are used in rider-facing apps, it will be essential to include these stakeholders.
Many demand-responsive transportation providers are very small organizations that are not currently providing data in a machine-readable form. They will need to be engaged in order to understand the benefits of providing their data and the requirements of maintaining it over time.