GTFS-Flex: dial-a-ride in the GTFS spec, and who actually publishes it

GTFS-Flex is the part of the General Transit Feed Specification that describes service a rider has to ask for. Dial-a-ride, route deviation, zone-based rural service, senior and disability transportation: anything where the vehicle does not simply show up at a posted time and place. It stopped being an extension in March 2024, when the proposal was merged into the main specification after years in draft. The four files it adds now sit in the same reference document as stops.txt and trips.txt.

We wanted to know how many agencies actually use it, so in August 2026 we read every GTFS feed in the Mobility Database that is not marked deprecated. Of 892 readable US feeds, 333 carry at least one Flex file and 78 put anything in them. Seventy-two of those 78 come from a single feed producer.

Flex covers service an operator runs and a rider requests. Vehicles a rider finds and unlocks alone, scooters and bikeshare and the like, are described by a separate set of specifications, the shared-mobility data stack.

The four files, and what each one is for

An ordinary GTFS trip is a sequence of stop_times rows, each pointing at a stop and carrying an arrival time. Flex breaks both halves of that. A Flex stop_times row can point at a zone or a group of stops instead of a single stop, and it carries a window rather than a time.

File	What it holds
locations.geojson	Pickup and drop-off zones drawn as GeoJSON polygons
location_groups.txt	Named groups of stops that a rider may be picked up at or dropped off at
location_group_stops.txt	Which stops belong to which group
booking_rules.txt	How far ahead a rider has to book, and how to do it

Two stop_times fields carry the window, start_pickup_drop_off_window and end_pickup_drop_off_window, and two more attach a booking rule to a stop time, pickup_booking_rule_id and drop_off_booking_rule_id. All four files are marked Optional, and both window fields are Conditionally Required, meaning they become mandatory once a trip stops at a zone or a location group.

US publishers have settled firmly on one of the two options. Of the 78 US feeds publishing Flex, 75 use GeoJSON zones, 1,666 polygons in total, and only six use location groups. The handful we found outside the US lean the other way: seven of the eight hang booking rules off ordinary stops and draw no polygons at all. Eight feeds is too few to call it a regional convention, but it is a real difference in how the same file set gets used, and a consumer that only handles polygons will miss those services entirely.

None of this describes where the vehicle is right now. Flex is a statement of what can be requested and when, which is the schedule side of GTFS. Live position and delay travel separately, in GTFS-Realtime.

Counting who publishes it

Two cheap methods are available for answering this, and both get it badly wrong in opposite directions.

The first is the Mobility Database’s own features column, which flags which feeds carry which optional parts of GTFS. It flags 36 sources as having Flex. Only 12 of those actually publish a Flex record, and 74 of the feeds that do publish one are not flagged at all. Most of the false positives carry the value flex-v1, which refers to continuous_pickup and continuous_drop_off, an older and much narrower idea that has nothing to do with the four files above.

The second method, opening the feeds and checking which ones contain the Flex files, is worse. It gives 333 for the US. When we read those files rather than just listing them, 255 turned out to hold a header row and nothing else.

The empty files are not agencies claiming service they do not run. They are a template. Trillium Transit, which hosts 422 of the readable feeds in this catalog, ships the Flex headers in every dataset it produces and fills them in for the customers that have flexible service to describe. That explains 248 of the 255 blanks, and it also explains the concentration on the other side of the ledger: 72 of the 78 US feeds that publish real Flex records are Trillium-hosted, and four more come from Cal-ITP, the California state program.

By state, the 78 are more concentrated still. Colorado accounts for 40 of them and Virginia for 15, so two states hold seventy percent of American GTFS-Flex feeds. In Virginia’s case the reason is documented: the Department of Rail and Public Transportation sponsored a pilot project to build Flex feeds for a selection of agencies along with a trip planner that could read them. Colorado’s Flex feeds are all served from a statewide Trillium download site. Adoption here looks less like a market reaching a tipping point than like a short list of places where somebody above the agency decided this was worth paying for.

Worldwide the same measurement gives 86 feeds. The eight outside the US are Adelaide Metro, Switzerland’s SKI+, Berlin-Brandenburg’s VBB, Reus Transport in Spain, and four French feeds including Ile-de-France Mobilites.

What the booking rules say

booking_rules.txt is the file that makes Flex more than a map of shaded areas, because it encodes the thing a rider actually needs to know. We read all 209 booking rules in the 78 US feeds.

The shape is unambiguous. 144 of the 209 rules close booking the day before travel, and the most common deadline is 5 p.m. Dolores County in Colorado will take a request up to 30 days out and stops accepting at 5 p.m. the previous day. Broomfield’s Easy Ride service closes three days before travel at 10 a.m. Cape Cod Regional Transit Authority is unusual in publishing all three booking types in one feed, with some services bookable in real time, some needing two hours, and some closing at 5 p.m. the day before.

The field that says the most, though, is the one almost nobody fills in. Of the 209 rules, 187 carry a phone number and 16 carry a booking URL. At the feed level, 74 of the 78 agencies give a number to call and nine give a link. Flex exists so that demand-responsive service can appear in a trip planner, and the overwhelming majority of what it currently describes ends with the instruction to pick up the phone.

That is worth sitting with rather than treating as a failure. Rural dial-a-ride is dispatched by people, often with eligibility rules that no booking form captures, and a phone number is an honest description of how the service works. It does mean that the promise of end-to-end trip planning across fixed route and demand-responsive service, which is the reason the spec exists, is not what these feeds are delivering yet.

The validator polices Flex harder than anyone publishes it

The canonical GTFS validator, now at version 8, documents 178 active notices. Twenty-nine of them exist only to check Flex constructs: unparsable polygons in locations.geojson, unsupported GeoJSON geometry types, a shape_dist_traveled attached to a zone rather than a stop, a prior-day booking rule missing its deadline, a pickup window on a stop time whose pickup type says the trip is regularly scheduled.

That is one check in six aimed at a feature 8.7 percent of readable US feeds use. An agency that publishes a malformed Flex feed will be told precisely what is wrong with it. Whatever is holding Flex back sits somewhere else.

Google will not take it

Google’s participation requirements for transit partners are blunt about this. The page states that “Google Transit does not currently implement the GTFS-Flex specification. GTFS-Flex datasets cannot be accepted at this time.”

Elsewhere the picture is better but narrower. OpenTripPlanner implements the version merged in March 2024, though flex routing is a sandbox feature that has to be switched on in otp-config.json rather than something a deployment gets by default. Transit describes itself as the first major consumer app to render Flex, working with Minnesota DOT and fifteen rural agencies to put pickup zones, service hours, and a call button in front of riders.

So an agency that does the work of publishing Flex gets picked up by Transit and by whichever OpenTripPlanner deployments have the flag turned on, and stays invisible in the app most of its riders already have on their phone. Whether that trade justifies a procurement is a fair question for a rural agency with one data person to ask, and it is the most plausible reason the count sits where it does.

How much service is missing

The National Transit Database’s monthly ridership file covers 523 agencies reporting active service in the year to June 2026, almost all of them full reporters. Of those, 410 operate demand-response or demand-response-taxi service. Four in five agencies in the monthly panel run something a rider has to book. The monthly panel is also only part of the industry: the 2024 annual database counts 524 full reporters alongside 603 reduced reporters and 1,111 rural reporters, and the reduced and rural ones do not appear in the 523 at all.

Set 410 against 78 and the size of the gap is clear enough. This is also what N-CATT’s Flex guidebook was pointing at in 2023 when it noted that the services missing from trip planners are disproportionately the ones used by people with disabilities, seniors, and rural riders. The guidebook put the number of agencies with Flex data produced for them at “well over a hundred.” Our count is of feeds published and registered, which is a narrower thing, and the difference between the two is probably the most useful number nobody has: data that exists somewhere but never reaches a public feed does not put a bus on anyone’s map.

What to watch

The single event that would change the arithmetic is Google reversing its position, and there is no sign of it. Its own reference page on where Google Transit differs from GTFS carries a December 2022 cutoff, fifteen months before Flex was voted in, and has not been revisited.

Short of that, watch the state programs. Colorado and Virginia produced 55 of the 78 feeds between them, which suggests that Flex adoption is driven by whoever is paying for the feed rather than by individual agency decisions. California’s transit data guidelines currently say providers “should aim to” code demand-responsive service, with no deadline attached. A state that made it a condition of funding would move the national number more than any amount of tooling.

And watch booking_url. Nine feeds out of 78 currently publish a link a rider can act on. Until that field fills in, GTFS-Flex is doing the first half of its job, telling a rider that a service exists and roughly where it goes, then handing the second half to a phone call and a weekday afternoon deadline.

For an agency weighing whether to bother, the honest summary is that the format is finished, the validator is thorough, the largest consumer is closed, and the places where Flex has actually shipped are the places where a state paid for it. Nothing on that list is a data problem.