Updated GTFS-Flex: What is it and How is it used?

GTFS-Flex

GTFS-Flex is an emerging transit data technology that enables the discovery of flexible transit services in trip planning applications (e.g., Google Maps). This technology extends the General Transit Feed Specification (GTFS) to model demand-responsive transportation, route deviation, and other non-fixed-route services for use in digital passenger information tools.

1. What is GTFS?

GTFS is a data format that standardizes how to organize transit schedule information for easy transfer between online systems. GTFS data is primarily used to feed trip planning applications with transit information so users can see trip plans with transit as the primary mode of travel. More information can be found at gtfs.org 

Over 2,500 agencies worldwide publish GTFS data, over a thousand of which are in the United States.As of Fall 2023, GTFS is also now a reporting requirement of the National Transit Database, administered by the Federal Transit Administration. Many commercial applications consume GTFS, including:

• Google Maps
• Apple Maps
• Transit
• Microsoft Bing Maps
• OneBusAway
• Rome2Rio
• Actionfigure (formerly TransitScreen)

Other transit technologies (planning and scheduling software, CAD/AVL, APC systems, etc.) also interact with GTFS data.

For well over a decade, GTFS has enabled transit riders around the world to make better-informed travel decisions around bus schedules, routes, fares, and the like.

2. Why do we need Flex?

Despite GTFS’s ubiquity, the specification in its current form is only able to represent fixed-route transit, even though most public transportation systems are demand-responsive (i.e., they fulfill rider-requested trips rather than operate a predefined schedule of fixed stops). According to the American Public Transit Association, with flexible capabilities absent from the spec, riders are unable to discover over half of U.S. public transportation services in trip planning applications. These services are commonly intended for more mobility-dependent people who have a disability, seniors, or for rural communities that lack a robust fixed transit system. As long as flexible transit is missing from GTFS, these individuals will be unable to benefit from trip planning technology.

GTFS-Flex is a product of the ongoing efforts of public, private, nonprofit, and volunteer stakeholders within the transit data community to model flexible transit in GTFS. The overarching goal is to make trip planning and data exchange equally accessible to all transit services and users.

3. What does Flex do?

The table above shows a comparison of features between GTFS and GTFS-Flex trip planning applications

GTFS-Flex, so named because it represents “flexible” transportation as opposed to “fixed,” exists to bring demand-responsive transit services to trip planning applications. A trip planning application provides navigational directions for various modes of travel to and from user-defined locations. With the addition of Flex, GTFS data can feed a trip planning application with directions for a given dial-a-ride, on-demand, route deviation, or other flexible service, presenting a user with more trip options using alternative modes of travel. Importantly, GTFS-Flex is a static data specification, meaning it does not convey real-time information like current vehicle availability (the future of real-time and Flex is covered in Section 13). Rather, it describes agency-defined rules of a flexible service, such as geographic pickup/drop-off boundaries, booking requirements, and hours within which riders can access the service.

4. What are some higher level impacts an agency can expect from GTFS-Flex?

An agency participating in a GTFS-Flex implementation project can anticipate a range of positive impacts. These include:

• Improved customer experience through easier discovery of and clearer information on their services.
• Improved accessibility with trip planning capabilities for transit services most relied on by more mobility-dependent individuals.

These benefits instill rider confidence, collectively contributing to increased ridership. An additional indirect impact is that by promoting shared ride services, GTFS-Flex can reduce single-occupancy vehicle trips, leading to less traffic and improved climate outcomes for an agency’s community.

Agencies looking into implementing GTFS-Flex may be concerned that wider exposure of their demand-responsive services may lead to confusion about the access of those services in terms of eligibility and schedule availability. In fact, Flex allows agencies to communicate these restrictions more clearly to reduce such confusion (that likely already exists without the presence of Flex data), as is detailed in the following section.

5. How does GTFS-Flex improve the rider experience?

GTFS-Flex brings a few key features to trip planning along with the addition of demand-responsive services. One of the more significant features is the option of including a brief message conveying the unique instructions for accessing a given service, like eligibility or scheduling rules. Without this feature, a user may see that a flexible trip is possible but have no way of knowing whether they qualify. GTFS-Flex data also provides the mechanics to define specific booking parameters like minimum advance notice, phone number to call, a link to an online booking tool (if it exists), and more. Lastly, Flex includes a few fields to improve trip time estimates; the travel patterns of demand-responsive services differ from a private vehicle’s (e.g., if it is a shared ride service), so providing users with the clearest picture possible of their expected travel experience is essential.

The following sections illustrate GTFS-Flex’s ability to cover a range of demand-responsive trip planning scenarios.

6. What else can GTFS-Flex do?

Standardized demand-responsive transportation data streamlines development of digital tools covering use cases beyond trip planning. Here are a couple examples.

7. How does GTFS-Flex work?

Diagram illustrating the mechanics of GTFS/GTFS-Flex data consolidation and distribution

To understand how Flex works, a basic knowledge of GTFS, the specification it is built upon, is required. GTFS is a ruleset for packaging a transit agency’s stop, route, and schedule data into a universally accepted format, making it easy for entities like Google to consume and publish. GTFS data consists of a set of lightweight file format text (.txt) files containing rows and columns that represent different categories of transit information. Having the data organized into a table of comma-separated rows and columns simplifies the process of viewing and editing data by hand. For example, the stops.txt file of a GTFS dataset contains information on a transit system’s stops, such as their public-facing name, stop code, and latitude/longitude coordinates. For reference, a portion of TriMet’s stops.txt file is shown here in both a text editor application (above) and a text-to-columns spreadsheet (below). Each piece of information relating to a stop has its place under distinct categories.

stops.txt file from TriMet’s GTFS dataset

To publish GTFS data, an agency encloses those text files in a single .zip file, which is posted online at a static web address, publicly available for download. Because the agency’s data follows the universal GTFS format, various apps are able to pull from this “single source of truth” and have identical interpretations of that data.

GTFS-Flex file/field relationship diagram

As an extension, GTFS-Flex adds features to the standard to specify; it does not overwrite anything. Flex follows the same structure as GTFS and is actually expressed as extra files and columns within a GTFS dataset. A Flex dataset is identical to a GTFS dataset in every way except for the addition of the extra files and columns, incorporating information such as:

• service areas – to describe the geographical boundaries within which the vehicle can pick up and drop off a rider
• service hours – to describe the time window within which the vehicle can pick up and drop off a rider, and
• booking rules – to describe all the requirements and information around scheduling a ride.

The following table details the specific major changes Flex makes to the core GTFS specification as of Sepetember 2023.[1]

How exactly a demand-responsive service should be translated to these GTFS-Flex files and fields is not always immediately clear. This is in part because the approach taken to convey information on demand-responsive services greatly varies among agencies. For example, one agency may use the term “Dial-a-Ride” and “On-Demand” interchangeably while another may view these as distinct services operating in very different ways. The lack of standardization around designing and defining demand-responsive transportation services, as well as publishing information about them, makes it essential to have close coordination between technicians building GTFS-Flex data and agency representatives who are knowledgeable about their demand-responsive programs. This is also discussed later in the “What is the technical process of a GTFS-Flex implementation?” section.

Below is a simple example of how GTFS-Flex incorporates loose service information once that ambiguity is resolved. In this case, High Valley Transit’s website includes a section describing how their demand response transportation service operates, from which specific pieces of information are pulled into sections of a GTFS-Flex dataset.

Distribution of a hypothetical agency’s service information within GTFS-Flex

8. How did GTFS-Flex come about?

The extension’s initial proposal was written in 2013 by Google software developer Brian Ferris to improve the modeling of flexible transit systems within the GTFS ecosystem. Collaborators such as Sean Barbeau from the University of Southern Florida, Ross Peterson of CR Peterson Consulting, and Aaron Antrim of Trillium later helped build upon Ferris’s initial proposal. The following developments have served as significant steps in GTFS-Flex’s evolution from a proposal on paper into the operational technology it is today.

Mobility on Demand (MOD) Sandbox Project
The first major step in GTFS-Flex’s development came in 2017 with the beginning of the MOD Sandbox Project, funded by the Federal Transit Administration (FTA). This project resulted in the development of the first large scale GTFS-Flex v1 trip planning tool—using the OpenTripPlanner (OTP) web application—for all agencies in the state of Vermont. This required upgrading OTP to read Flex data and include trip results for services like dial-a-ride, route deviations, and continuous stops (then part of the Flex extension). Trillium and Cambridge Systematics released the code developed for Vermont Agency of Transportation as open-source, integrated it into OpenTripPlanner v1.4, and have commercialized it along with Kyyti and Interline—other independent companies.[2]

MobilityData stewardship
While the MOD Sandbox Project established GTFS-Flex v1 as a stable, operable data specification, stakeholders recognized the importance of the extension’s continued improvement. In 2018, MobilityData, a nonprofit that facilitates development and stakeholder engagement on several mobility data standards, assumed a leadership role for GTFS-Flex and began development of GTFS-Flex “v2,” which was released in 2018. Further enhancements led to the 2020 release of the current adoption candidate, which also saw limited refinements to its architecture in subsequent years. More detail on recent work in the spec’s evolution is provided in the next section.

OpenTripPlanner development
OpenTripPlanner (OTP) is an open-source web application created in 2009 that provides backend code for designing web-based trip planning applications. Since GTFS-Flex’s inception, OTP leadership has worked to incorporate GTFS-Flex in the development of their own software (the MOD Sandbox Project is one example of this). This history of cooperation, along with its tailorability, established OTP as the principle environment developers use to create GTFS-Flex trip planning tools.

OTP’s project leadership committee released OTP2 in November of 2020 which can ingest GTFS-Flex in its most current form to provide flexible trip plans. The upgraded routing technology in OTP2 provides significantly faster trip plans and improves how flexible and fixed-route services are combined in trip options. Many trip planners exist today using OTP2 and Flex “v2” data. Some include parts or all of the states of California, Colorado, Georgia, Massachusetts, Minnesota, Virginia, Washington, and others.

9. What is happening with the development of the Flex spec today?

Two requirements must be met before GTFS-Flex, or any proposed addition, is officially adopted into the core GTFS standard: First, there must be a pair of data-producing and data-consuming systems utilizing the proposed extension. Second, the addition must be approved in a vote held by the GTFS community. Thus, as a specification in an “experimental” state, the structure of GTFS-Flex is subject to change until that final vote takes place and the extension is officially integrated into the core GTFS.

As such, Flex continues to be shaped into a more viable extension under this experimental state. In the summer of 2023, MobilityData initiated a targeted effort to prepare the Flex spec for an official vote. Through this current initiative, Flex is undergoing a process of wider community feedback to allow interested parties who have not been previously involved to identify any inadequacies, ensuring it truly meets the needs of all stakeholders. As of September 2023, a variety of topics are under discussion with the following initiatives being the most significant:

• Reach wider consensus that GeoJSON is the right solution to represent polygons for GTFS
•  Determine how to better isolate flexible routes’ file/field relationships from fixed routes to reduce complexity for consumers
• Determine whether a “location group” function should exclude the use case of grouping polygons together, and whether the spec should revert back to a dedicated file for that function (as opposed to using the areas.txt/stop_areas.txt files from the Fares v2 extension)

Once these and other issues have been resolved, and once adopting producers and consumers have applied these changes to their data/software, a vote will be called. Given the amount of dependencies and number of parties involved, an exact timeline of these milestones is elusive, but it would be a reasonable estimate that such a vote occurs by the end of 2024.

11. What are some specific ways to leverage GTFS-Flex?

Regional flexible trip planners
An agency can attain the goal of seeing their services represented in a multimodal flexible trip planner, but the price of these projects is difficult for a single agency to bear. Additionally, while much of the technology required can be open-source, it is difficult to deploy without experienced developers; it is unlikely a small agency could create such a tool in-house with a probable lack of internal resources. Agencies can overcome these barriers by partnering with other regional providers to launch a multi-agency flexible trip planning tool. As a coalition, the agencies may also be able to access funding already pooled for certain regional technology projects. A regional trip planner could serve as the foundation for a “Mobility-as-a-Service” platform with a wider scope later on.

Directories and website integrations
A DOT or other organization can implement a large-scale database of GTFS-Flex datasets for comparative analysis of demand response services or for extracting specific details of those services. One example of this use is the Oregon DOT’s development of an open-source transit agency directory platform, funded by an FTA Accelerated Mobility Initiative grant.

A complete list of demand-responsive services powered by, for instance, GTFS-Flex and GTFS-ride[1] data that includes critical information like hours and areas of operations could support ancillary DOT objectives. Directories could also serve as starting points for future demand-responsive trip planning when the consumption of GTFS-Flex data by commercial applications becomes more widespread.

Request in “MaaS” or “Microtransit” projects
Academic entities, businesses, and agencies have a strong history of working together to drive the development and adoption of GTFS-Flex, believing that the specification presents an opportunity to make community transportation competitive. As it stands, small demand-responsive transportation agencies are at a disadvantage with large TNCs occupying an inflated presence in commercial trip planning applications, either as a dedicated mode of travel option or by appearing as first/last mile connections in “MaaS” apps. Small public agencies would be on a more level playing field with TNCs if they had access to the same technologies as microtransit operators without the need to use operators’ proprietary apps. GTFS-Flex can model the static operational parameters of any flexible shared-ride service, even a taxi or microtransit service, offering agencies a comparatively lower cost solution for exposing their on-demand services to riders in these digital spaces. Agencies considering a pilot for services of this kind could require a GTFS-Flex dataset as a condition of the pilot to ensure the service is ready to integrate into future trip planning apps.

12. What is the technical process of a GTFS-Flex implementation?

The precise steps taken to implement GTFS-Flex will look different for each project. Regardless, there are a few likely commonalities worth highlighting. The following is based on the experiences of this paper’s authors of the various agency-producer partnerships they have been involved in.

Step 0: Preliminary research
The GTFS-Flex producer gathers information from the agency website, looking for services that would be considered “flexible.” At this stage, the producer begins to construct a provisional understanding of the most essential features of that service, e.g., pickup/drop-off boundaries, days/hours of operation, eligibility, cost, etc.

Step 1: Agency interviews
Once the producer has gathered all the relevant information available, they schedule a call with the agency to verify that the information is correct and that they are interpreting the information as the agency intended. Agency descriptions of their flexible services can differ greatly from one to another; seeing entirely different vocabulary for similar types of transit service, or services with very different operation models, in a single region is not uncommon. The presence of such ambiguity requires close coordination between the producer and the agency for whose services they are building GTFS-Flex data, hence the need for the two parties to talk to one another.

Step 2: Flex feed development
After the producer has collected and verified all the necessary information, the producer builds the GTFS-Flex data. The producer may use their own software, use manual processes, use third-party tools, or a combination of both, but so long as the resulting data follows the standard and is valid, the outcome is the same for the agency.

Step 3: Validation and publication
As with any standard GTFS dataset, the data built must be validated and reviewed for accuracy before it is consumed by applications used by the public. Internal peer review, use of third-party automatic validator tools (like MobilityData’s Canonical Validator), and supplemental manual validation for especially important files are common practices. Once the vendor has confirmed the data is valid, they post the dataset (text files in a single zipped folder) to a directory on a public server, accessible to consumers via a direct download link (also known as a fetch URL).

Step 4: Testing in trip planning app(s)
If part of the Flex implementation includes a trip planning application, data producers begin working with partner consumers to test that the data and the consuming software are working as expected. Once the application is in a stable state, agency representatives may also be invited to test out the tool to ensure it represents their services correctly.

Step 5: Long-term maintenance
As data intended to model current parameters of services in operation, GTFS-Flex data requires maintenance just as standard GTFS does. Thus, agencies and their GTFS producer typically establish a communication process to capture any service changes with enough advance notice so there is no discrepancy between the information that consuming applications display and what a rider experiences. Specific to an experimental extension, the producer is also responsible for ensuring the agency’s GTFS-Flex data reflects the most current version of the spec.

13. Are there any other extension efforts related to GTFS-Flex?

Some categories of passenger information related to Flex are still missing from GTFS. Initiating an extension development effort for an open data standard like GTFS usually relies on grant funding, especially if including a pilot implementation, so it is difficult to predict the exact timeline of when Flex-adjacent enhancements will see further activity. Below are some examples where progress toward those enhancements has already been made.

GTFS-OnDemand: Considerations for booking and real-time
Booking is an integral part of completing a demand-responsive transportation trip; real-time information on service availability is equally valuable to riders. However, GTFS-Flex is a static extension to GTFS, describing static business rules and expected behavior of a flexible service. Flex does not include actual booking functionality (whether an in-app feature or deep linking) or real-time service information like vehicle location or rides available.

Recognizing the importance of this type of passenger information, MobilityData headed the “General On-Demand Feed Specification” (GOFS) working group in late 2020 to design an extension covering the use cases for real-time Flex. The outcome of the working group was a draft proposal of how on-demand information could be represented within GTFS. Because OnDemand uses GTFS-Flex components, further refinement or implementation of the proposed spec is virtually on hold until Flex is no longer subject to change.

Eligibilities and Capabilities
Eligibility requirements were included in the earliest version of GTFS-Flex, albeit simply: Routes were classified as either having eligibility requirements, or not. Understanding that defining eligibility conditions such as age, residency, disability, and the like necessitated a more comprehensive approach, it was decided that these considerations should be later addressed with more intentionality under a separate, dedicated extension effort.

Closely related to eligibility is the level of service/vehicle accommodations of a given transportation program, as eligibility groups more commonly need to know the capabilities of the service to determine whether they will be able to successfully use it. For example, does the vehicle have a ramp or a lift? What level of personal care training do drivers have? Can the rider expect to be escorted to the door of their destination?

In 2021, with a Federal Transit Administration’s Mobility for All Pilot Program (M4A) grant, the Oregon Department of Transportation funded a working group led by Kevin Chambers of Full Path to draft both a GTFS-Eligibilities and GTFS-Capabilities extension covering the two use cases (Click here for more information). Similar to OnDemand, further work with these proposed extensions are partially contingent on components they share with the Fares extension not yet adopted, like RiderCategories.

The existence of these two draft specs marks a significant first step in providing riders with complete information on whether they qualify for a service, and whether that service is able to meet their needs.

Brokerages and sharing trips
The exchange of information between a trip planner and a reservation system provides for booking a customer trip, but in practice, operations are not performed consistently by one agency. Community transportation operators commonly share riders between services, so the reservation systems should also communicate with other reservation systems and with brokerages. This issue has seen important development and the beginning of standardization through the TCRP G-16 project and the Transactional Data Specification (TDS) for Demand-Responsive Transportation (DRT).

Conclusion: GTFS-Flex for a more competitive and equitable market

Transit providers, government agencies, and private companies in the transit data space have a responsibility to ensure that people reliant on public transit, in all its forms, are able to make informed, confident travel decisions that impact their daily lives. GTFS-Flex is helping the transit industry reach the vision of a more competitive and equitable market where all riders can easily discover all flexible transportation options, including the ones best for them. Actualizing the vision requires collaboration and adoption by both existing and new vendors in the marketplace. It also requires further collaboration with and education of agencies and regulators, which takes time and investment. Fortunately, we have already seen this vision come true for fixed-route transit thanks to the global buy-in of GTFS and GTFS-Realtime; investment in GTFS-Flex can do the same for flexible transit.

Open Printable Version Here