A 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 a 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 rider eligibility and 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.
GTFS-eligibilities address how a person’s individual characteristics (e.g., age, disability status, residence, employment, or registration in a program) may affect their access to public transportation services. Such information is currently available to the public in analog or one-off digital formats only. This absence creates a range of unnecessary difficulties
● Discovering services is labor-intensive, often with the burden falling on riders themselves to figure out what exists, whether they qualify for a specific type of transportation, and whether a provider can meet their service needs.
● It is difficult for transit agencies to communicate their services, especially specialized services, to the public.
● It also adds barriers to planners, policymakers, and researchers understanding how eligibility factors and agencies’ ability to provide specialized services affect different populations’ mobility.
Eligibility Challenge: Global versus local naming of eligibility categories
Eligibility definitions are often hyperlocal and nuanced, so the project’s challenge was to figure out how to manage a high level of variability in a standardized way. The solution is Uniform Resource Names, or URNs.
URNs are structured with the most general terms at the beginning, with increasing specificity for each term. They would start with GTFS (to specify the type of URN), then eligibility, then the jurisdiction (United States in the first example, Oregon in the second, and Ride Connection (example of an Oregon-based organization) in the third), then the name of the eligibility(e.g., veteran).
● urn:gtfs:eligibility:us:va:veteran
● urn:gtfs:eligibility:us;oregon:odva:veteran
● urn:gtfs:eligibility:us;oregon:ride.connection:veteran
The URN structure allows for a local level naming structured to be machine/computer readable, resulting in unique names.
Currently, no global names are being proposed, but as more groups use these URNs, there will be opportunities for coordination atstate or regional levels. The URNs are not intended to be rider facing but provide the opportunity to add a short name and a longer description to make it easier to read.
Will the degree pf local choice in the development of URNs make it difficult to aggregate data? For example, the overlapping terms of senior, elder, or older adult?
Ultimately, best practices for URN development will be developed for a URN to reflect a specific jurisdiction. Over time, as the use of URNs grows, there could be mapping of terms (to make it clear how a local term relates to a state, national, or international term), but this effort did not develop a set of global terms or how other terms should be mapped. URNs are a new concept within GTFS, and so there needs to be an adjustment period.
Eligibility Challenge: Describing multi-element rules in a computer-readable fashion
Eligibility rules can have multiple criteria that are complex to describe. An example would be a rule that defines eligibility for a transit service as a person who is:
● 65 or older,
● has a disability, or
● a student who is 18 or younger.
The proposed standard addresses this kind of complexity by establishing a URN for each eligibility factor. The standard does this in a way that also conforms to the norms of GTFS data formatting.
Have there been any options for “not”? Otherwise, you would have complete first order logic. An example: the rider hasa disability and is a resident of Pierce County, so would be paratransit eligible.
That option was not been considered; eligibility had been approached as always affirmative (what you are, rather than what you are not).
How will the standard incorporate flexibility when providers allow it? One example is an income threshold – a criterion that can vary by provider and may not be absolute.
URNs will describe eligibility criteria, but agencies/jurisdictions would still have discretion for how they are applied. In addition, the only place where numeric calculations likely could be fully automated would be a criteria related to age. In thecurrent proposal, income ranges are not treated as absolute. Any new standard would have to address such questions.
Lesson from GTFS-flex: Allowing a great degree of flexibility means that some power users will stretch the criteria as far as it can go. This field type could benefit from some validator tooling for data producers, to ensure that their data can be consumed.
There has previously been discussion of the need for validation tools, but creating them was beyond the scope of this project. This need is not unique to these extensions and MobilityData has an operational GTFS validator. As new extensions to GTFS are adopted, the validator is updated (within about six months). There is an accompanying grading scheme for items that cannot be automated through the validator tool.
Eligibility Challenge: Describing registration or intake processes, including accounting for one-time determinations vs. those that require renewal/re-verification
The current proposal has only limited support for registration, with fields for a related URL and phone number as well as a text description of how to register, if required. Consistent with the project’s focus on discovery, this approach does not fully support one-stop registration; that could happen with future projects.
Does the standard incorporate a way to indicate who is defining local eligibility criteria and who gets to adjudicate in case of disputes? Whether eligibility decisions are made by computers/AI or humans, it is important to be transparent about how to refute a determination.
The project was not able to consider this aspect. There is an assumption that the producer of the data feed would also be the adjudicator of any determinations made about it. A potential solution (or a good start) would be to provide a URL to describe the process for disputing a determination and a phone number to connect to a person.
Eligibility Challenge: Describing authentication methods for booking, including considering privacy and security of rider data
Due to the limited scope of this project, it was determined that booking was too complex and outside the project’s scope. Thereare other projects, namely the General On-demand Feed Specification (GOFS) project led by Mobility Data, which have the entire trip lifecycle within their scope.
Eligibility 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 conversation 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 Eligibility
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 does exist, which does provide 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.
PROJECT WINS
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
PROJECT IMPLICATIONS
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, 211/information referral/aging, and 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.