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
- Microsoft Bing Maps
- 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?
|Typical GTFS Trip Planning Features||GTFS-Flex Trip Planning Features|
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.
Advance reservation demand response
Demand-responsive transportation services typically provide rider-scheduled rides anywhere within a specified zone or between zones. Often times, demand-responsive transit exists as a supplemental service to an agency’s existing network to comply with the Americans with Disabilities Act and thus is only available to people with a disability or seniors (these services are usually branded as “dial-a-ride” or “ADA paratransit” in the United States). In other cases, a community’s transit service is 100% demand-responsive because of the size of the population or geography of the service area.
The specific steps vary among apps, but trip planning for advance reservation demand response typically works by the user inputting into the system an origin and destination along with any preferences like time of departure/arrival. If the user’s trip parameters fall within the service area, days/hours of operation, and the direction of travel (for instance, Town A to Town B is allowed, but not the other way around) is permissible, then a possible itinerary for the service will display. Booking information for the user to further inquire about scheduling such a trip is also likely included. Any eligibility restrictions could be conveyed in a custom message field.
Demand-responsive trip plan from the RideNoCo Trip Discovery Tool
General demand-responsive rider scenario
The rider has a disability that makes it difficult for them to drive a car. They live in a small, rural county with one demand-responsive transit service. Sometimes, they can get a ride from a family member, but their family is not always available when they need transportation. They want to find a more reliable mode of transportation to access social services on their schedule. The rider navigates to their regional trip planning web app, inputs a search query, and discovers there is a county dial-a-ride service. The rider also sees instructions on how to schedule a ride and how much it will cost. They call the number listed and book a trip for the next day.
Route deviation is a type of demand-responsive service where vehicles operating a fixed route will deviate from the regular path of travel to fulfill rider-requested pickups and/or drop-offs, as long as they fall within a certain radius of the route. The vehicle returns to its regular course once it has fulfilled the deviation. To see route deviation results in a trip planner, a user inputs an origin-destination pair as they would for a regular trip plan. If their origin or destination is outside walking distance of a stop but within the deviation zone of a deviated fixed-route, the accompanying map will show a trip plan that uses the route and incorporates a deviation to that location. Additionally, any rules for using the service will display such as what kind of advance reservation the deviation requires.
Route deviation trip plan from nwconnector.org (now retired)
Route deviation rider scenario
The rider is visiting a midsize city. They rely on the city’s bus service during their stay, but stop coverage is inconsistent near where they are staying. Buses can deviate up to 3/4 of a mile from the route, but finding the deviation rules online is an involved task, especially while on the go. As the rider waits for the bus, they pull out their phone and open a trip planning app. They input a trip query to see if the bus can deviate to their destination at their desired time of arrival. Having confirmation that the bus indeed can make this deviation, they request the deviated drop-off to the driver as they board.
On-demand services are transportation services that allow a rider to request a demand-responsive ride in real time and be picked up shortly after. Examples of on-demand transit include microtransit, Transportation Network Companies (TNCs) like Lyft and Uber, or hail-and-ride/taxi-like services where the fleet of vehicles roams a service area and can be hailed by a pedestrian. On-demand trip planning is the most immediate in nature since the user’s ride request can be fulfilled instantly after booking.
On-demand trip plan from the connectingVA trip planning tool
On-demand rider scenario
The rider lives in a suburb of a large city and carpools to their downtown job. The carpool is unexpectedly canceled one morning, so they must find other means of getting to work. The rider opens a trip planning app and inputs their origin and destination with a “leave now” preference. One trip result includes the use of a microtransit service for seniors that picks up riders from surrounding suburbs and drops them off in the city center. Being of eligible age, the rider follows the link provided in the itinerary, registers for the program, and books the microtransit trip. After the microtransit vehicle takes them to the downtown transit center, the rider boards the frequent rail service for the last mile of their trip to reach their final destination.
In these scenarios, GTFS-Flex helped the first rider discover a dial-a-ride service that increased their mobility independence, simplified the process for understanding how to fully access a city’s transit for the second, and enabled the last rider to easily make on-the-spot travel decisions. GTFS-Flex improves the user experience of accessing digital transit information, but more importantly, it also increases transit access.
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.
Similar to how standard GTFS datasets can generate bus schedule timetable displays for websites, GTFS-Flex can produce other rider-facing tools centered around service discovery. One example is Pomona Valley Transportation Authority’s Program Finder, a GTFS-Flex-powered search tool that allows a user to input eligibility information and an origin-destination pair and see transit services that match those parameters.
PVTA Program Finder with example results
Mapping service areas
The geographical data GTFS-Flex produces can offer insight into the outcomes of a demand response program as well. For example, by using GTFS-Flex’s geographical data, agencies and other stakeholders can map demand response service areas to measure access or to compare other transportation providers like taxis or TNCs.
Various flexible services (excluding TriMet) of Northwest Oregon mapped with GTFS-Flex (left) compared to the closest Lyft service area (right).
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.
|Flex additions to GTFS||Description|
|New file: locations.geojson||GeoJSON is a human-readable open data format that produces geographic data structures. It is also the first instance of an extension introducing a file format other than a .txt containing CSV data. GeoJSON file defining polygons for the geographic areas in which demand response services can pick up and drop off riders.|
|Modified file: areas.txt and stop_areas.txt||These files originate from the Fares v2 extension. In the context of Flex, they are used to group multiple stops together so they can be referenced as a single on-demand service (also known as “unordered stops”). These files are also able to group multiple polygons from locations.geojson for cases where multiple isolated zones serve as a single service area with unlimited travel between and within each. However, in August 2023, the Flex community identified that this function may not be needed as the GeoJSON format itself can achieve grouping of zones by using the “MultiPolygon” feature type; based on this conclusion, it is likely that this aspect of the location grouping feature will be removed. As of September 2023, there are multiple discussions taking place on the future of areas.txt/stop_areas.txt as they relate to Flex. A possible outcome is that they are replaced by a new file strictly dedicated to grouping Flex stops along with a new dedicated column in stop_times.txt to reference a given stop group.|
|New file: booking_rules.txt||Establishes whether a service has reservation requirements and provides booking instructions. Specific data points include:
|Modified file: stop_times.txt||Fields are added to stop_times.txt that describe:
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.
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 (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.
10. What GTFS-Flex implementations are out there now?
GTFS-Flex data is now produced for well over a hundred public transit agencies in the U.S. alone, representing hundreds more of individual demand-responsive services. The transit data landscape in the U.S. has also been home to many projects culminating in data-producing and consuming partners launching Flex-enabled trip planning tools; European stakeholders have likewise recognized the viability of GTFS-Flex. Provided here is a survey of some of these GTFS-Flex projects as well as a list of companies offering GTFS-Flex-based services.
The Vamos Mobility App is a developing Mobility-as-a-Service platform that will eventually include flexible transit trip planning. The app is funded through a California Air Resources Board grant and a contract between UC Davis, DemandTrans, Trillium, and managed by San Joaquin Council of Governments (SJCOG). Vamos is a combination of agency-owned GTFS and GTFS-Flex data, an OTP instance hosted by a third party, and the Vamos Mobility App licensed and branded for the local region of San Joaquins County in California. Close to a dozen agencies participate in the project, providing a mix of fixed and demand-responsive routes. As of this writing, the Vamos Mobility App incorporates fixed bus, fixed rail, on-demand services, paratransit services, electric car share, bike share, and is working to integrate more transportation options within San Joaquin County as well as from neighboring counties.
Vamos Mobility App
The Vamos Mobility App project also received an Integrated Mobility Initiative grant from the FTA to add payment integration for fixed-route services; payment integration for the demand response services has also been considered. The Vamos Mobility App technology provides account-based features that are not as available through simpler website-based apps. With this app, users can save favorite trips and account details, including payment information to streamline purchasing tickets. SJCOG and Masabi partnered to Fare Payments-as-a-Service (FPaaS) via a program called EZHub. EZHub integrates natively with the Vamos Mobility App and allows agencies to have great control and insight on their ridership purchases. Agencies can also push promotional codes to users to encourage use of the system.
One-Call, One-Click, by King County Mobility Coalition
King County, Washington is home to Find a Ride, a service that aims to connect community members to specialized transportation. Recognizing that Find a Ride’s search tool lacked more dynamic features found in typical commercial trip planning applications, King County Mobility Coalition determined that an upgrade was warranted.
One-Call, One-Click, by King County Mobility Coalition, is a project aimed at upgrading the Find a Ride website into a trip planning tool allowing users to input preferences and accessibility requirements, enrollments, and other details to find matching transportation throughout King County and Washington’s Central Puget Sound region. King County Mobility Coalition is working with both public and private partners to achieve this goal, including:
- King County Metro
- Sound Transit
- Washington State Department of Transportation
- Cambridge Systematics
The project is near completion; partners expect to launch the GTFS-Flex-powered trip planner as soon as Fall 2023. When complete, the new Find a Ride website will represent one of the most significant milestones for GTFS-Flex: Its first implementation in a major metropolitan area. The Seattle Metropolitan Area is the 15th-largest in the United States (United States Census Bureau).
RideNoCo (Northern Colorado) is an online mobility coordination program headed by the North Front Range Metropolitan Planning Organization. The website contains a host of resources for individuals to discover and match mobility services to their needs. Among those resources is a flexible trip planning tool, launched in 2022, developed by IBI using the OTP2 base code and using GTFS-Flex data created by Trillium. Thanks to GTFS-Flex, the tool’s search results now include trips from four demand-responsive agencies operating in the region.
RideNoCo Trip Discovery Tool
Southern Minnesota MaaS Platform
2022 saw another major development through the Southern Minnesota MaaS Platform, a multilateral effort involving the Minnesota Department of Transportation, Cambridge Systematics, Transit app, Token Transit, and Trillium, to provide a robust digital passenger information system to rural Minnesota. Under this project, Trillium created GTFS-Flex data for 30 demand-responsive services operating in the state. Perhaps the most significant outcome of the project is Flex’s debut in a major commercial trip planning application, the Transit app, signaling to other major companies the spec’s now hallmark status as the solution for demand-responsive trip discovery.
GTFS-Flex outside the U.S.
The growth of GTFS-Flex has even extended beyond the U.S. In Germany, a team of OTP developers created GTFS-Flex data both for the city of Herrenberg instance of stadtnavi, an OTP-based trip planning tool, and for bbnavi, another mobility platform for municipalities in the state of Brandenburg. For stadtnavi, developers created a separate GTFS-Flex feed which was then merged into the city’s existing GTFS feed, while the bbnavi Flex feed was handwritten and published directly online.
stadtnavi trip planning tool
bbnavi.de (translated to English)
A small but growing field of software vendors now support GTFS-Flex as a producer, consumer, or both.
- OpenTripPlanner (code development by developers including IBI, Cambridge Systematics, and Interline)
- Transit app
- Agile Mile
If you would like your organization to be added to this list, please email the authors of this white paper: firstname.lastname@example.org
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 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.