ITSFeed

The data, standards, and technology behind mobility.

ITS
Intelligent transportation systems
Feed
The live data layer

Roundup · Feeds & Standards

October 2026 roundup: GTFS changes hands on paper, and the validator catches up with the spec

What moved on the transportation data layer from early September to early October 2026: Google hands GTFS ownership to MobilityData, shapes.txt becomes conditionally required, the canonical validator picks up five unreleased rules, and the licence proposal's first vote closes with the result pending.

By
Nick Sawinyh
Filed

A monthly scan of what actually moved on the data and technology layer of transportation. This edition runs from the first week of September to the start of October 2026. Last month the thread was the specification text itself. This month it is custody: who owns the specification, who enforces it, and who gets to say that a feed is official.

GTFS changes hands, on paper

MobilityData announced on September 23 that Google has transferred ownership of GTFS to the Montréal nonprofit, which has maintained the specification since it was founded in April 2019. The announcement was timed to the International Mobility Data Summit in Montréal that week, which MobilityData says drew more than 200 transit professionals from 20 countries. The release recounts the familiar history: work started in 2005 between Google and TriMet in Portland, the format went public in 2006, and by 2015 agencies and vendors were extending it in uncoordinated directions, which is the problem MobilityData was created to solve. By its own count the format is now used by more than 10,000 agencies in over 100 countries.

Élisabeth Poirier-Defoy, MobilityData’s executive director, is quoted saying GTFS “now belongs to the thousands of app developers, agencies, governments, vendors, and researchers who have built it into what it is today.” Google’s Andrew Stober, a strategic partner manager, said the company is “thrilled that MobilityData is taking official ownership of the standard.” We found no statement from Google outside that quote, and as of this writing no coverage of the transfer outside MobilityData’s own channels.

The release says that for people who use GTFS every day, nothing about it changes, and that the public proposal process, working groups, and contributor base continue as they are. What it does not say is what, concretely, was transferred. There is no mention of the repository, the name, the mailing lists, or the contributor agreement.

The repository is where you can check. As of October 2, the specification still lives at github.com/google/transit. The contributing guide still requires every proposer to sign Google’s individual or corporate Contributor License Agreement before a change can merge, and the change process still names that agreement as a condition of the final step. The governance text has described MobilityData as the Maintainer since the governance rewrite merged in July 2025, so the day-to-day role the release formalizes was already written down more than a year ago. Google’s own developer page for GTFS, last updated in October 2024, does not mention MobilityData at all.

None of that makes the announcement empty. Ownership of an open standard is a question that only matters at the moment someone disputes it, and a nonprofit holding it is a more comfortable answer than a company holding it. But the practical markers of the change, a repository under a different organization and a contributor agreement that does not route through Google, had not appeared a week later.

shapes.txt is now conditionally required

A one-line change to the Dataset Files table in the GTFS Schedule reference merged on September 16. shapes.txt, which had been Optional since the specification was written, is now Conditionally Required: required if any trip has continuous pickup or drop-off behavior defined in routes.txt or stop_times.txt, and recommended otherwise.

The reasoning is transitive. The shape_id field in trips.txt was already conditionally required under exactly that condition, because a consumer cannot place a rider along a route segment between stops without knowing where the segment runs. A required shape_id with no shapes.txt to resolve it against is incoherent, so the file was always required in practice whenever the field was. The proposal, opened September 9 by a contributor, made the consequence explicit in the file table and at the top of the file’s own section. The “recommended otherwise” carries forward a 2024 change to the reference that said shapes should be included for all route-based service.

The change went through the documentation-maintenance track of the governance process, which calls for a comment period of at least seven days rather than a vote, and the maintainer merged it the day the week was up. It adds no capability. A feed that already passes the trip-level check passes this one.

The canonical validator got to the trip-level check first. On September 4 it gained a rule that raises missing_required_field on trips.shape_id whenever a trip has continuous pickup or drop-off and no shape, reading the stop-time value where one is set and the route value otherwise, and treating the value 1 and an empty cell both as “no continuous stopping.” So the validator enforced the field-level rule twelve days before the specification spelled out the file-level one. They are two different rules that describe the same feeds: a trip with continuous stopping has to carry its shape.

The validator catches up with August

The canonical GTFS Schedule validator took six commits on its main branch between September 4 and the end of the month, and five of them change what the tool reports. The shape rule above is one. We wrote about what the validator checks at the end of September using the v8.0.1 release from May. None of these rules are in it.

The first implements the specification change we covered last month. Since September 16 the validator treats min_transfer_time in transfers.txt as required whenever transfer_type is 2, and reports a missing or empty value as a missing_required_field error. A value of zero remains valid. The gap between the specification text merging on August 17 and the validator enforcing it was one month, which is the ordinary order of events: the spec changes first, the tool follows, and the feeds that were non-compliant without knowing it find out at the next validation run.

The second closes an older gap in the same file. A specification change merged in February made from_stop_id and to_stop_id required when transfer_type is empty, not only when it is 0 through 3, but the validator skipped any row whose transfer_type was blank. From September 16 those rows are checked like the rest. In-seat transfer types keep their exemption.

The third, merged September 17, marks trip_headsign as a recommended field, so a feed that includes the column but leaves it empty now gets a missing_recommended_field warning. The fourth, merged September 29, adds a new file-level error for text files whose line endings are neither LF nor CRLF. A carriage return followed by a second carriage return and a line feed used to parse silently. It is now reported.

None of this is in a release. The last tagged version is still v8.0.1 from May 12, so until MobilityData cuts the next one the new rules exist for anyone building from source and for nobody else. Agencies that use timed transfers and have never populated the duration field have a window to fix it before the number shows up on their report.

The licence proposal finishes its first vote

The proposal to add a licenses.txt file to GTFS Schedule, which we flagged in last month’s queue, spent September going through the governance process it was written under. A one-week review period ended September 15. The vote-to-test, the first of two votes a functional change needs, opened on September 17 and closed at the end of October 1, UTC.

That vote requires unanimity: it passes only if every vote cast is in favor, with at least five votes, at least two from producers and two from consumers, and the advocate barred from voting. The thread shows seven votes and no dissent: OpenGeo, SEPTA, FlashWeb IT, Avail, and Codeando México as producers, Transitous and OpenTripPlanner as consumers. On the face of the thread the count, the composition, and the unanimity rule are all satisfied. The process puts the formal result in the advocate’s hands, announced in the pull request and on the mailing list, and as of October 2 that announcement had not been posted. If it confirms what the thread shows, the proposal moves to testing by at least one producer and one consumer in public, and then to an adoption vote at an 80 percent threshold.

The OpenTripPlanner vote came with a line worth keeping: it is unlikely the router will do anything with the field, but it is good to create clarity. That is the case for the file: a place to look, for a volunteer or a researcher who wants to reuse the data, which is the gap we measured in US feeds when we looked at transit in OpenStreetMap.

The Mobility Database decides what counts as official

MobilityData’s catalog had two episodes this month about the same question: what the catalog should assert when the feed itself says nothing.

The first is a flag. The catalog schema has an is_official field, defined as true when a feed “comes from the agency as an authorized source” and false when it was “created by researchers or partners unaffiliated with the agency or municipality,” with an unset value treated as false. On September 10 two pull requests set it on every MobilityData-sourced feed that had been left blank: 284 marked official and 30 marked unofficial, across active and inactive feeds, with a mix of automated classification and human review, and the feeds the notes label as transitfeed imports deliberately left unassigned. The review notes record one correction, a set of Maryland feeds hosted on GitHub that had been marked unofficial in error and were fixed. For anyone who builds on the catalog, the default just changed meaning: an unset flag used to mean “nobody has looked,” and now, for the MobilityData-sourced feeds, it means “we looked.”

The second is a licence. On September 22 the GBFS systems catalog added twenty feeds, fifteen of them Slovenian feeds served from one source and published as GBFS 2.3. The next day all fifteen were removed. The Mobility Database had displayed them as CC-BY-4.0, because that is its fallback when a GBFS feed carries no licence information, but only from GBFS 3.0 does the specification say that a missing licence means CC0. For a 2.3 feed, a missing licence means nothing at all, and the pull request removing them cites the operators’ requirements. The issue to fix the display, blank for pre-3.0 feeds and CC0 for 3.0 and later, was open at the end of the month, and a Nantes feed we checked on October 2 still showed CC-BY-4.0. This is the shared-mobility side of the same problem the GTFS licence file is trying to solve, and we covered where GBFS sits in that stack in our shared mobility data explainer.

TIDES publishes a roadmap with a deadline already behind it

When we published our TIDES explainer on September 11, the pull request publishing the board’s 2026 to 2027 roadmap had been open for three months. It merged on September 16, as a commentable Google Doc and a PDF, with the board members’ approvals on the pull request serving as the ratification record.

The document targets the v2.0 release for August 2026, timed to APTAtech, a date that had passed before the roadmap was published, and no v2.0 tag existed on October 2. Its funding paragraph says MobilityData’s bridge funding sustained community management at a baseline level through July 2026, at roughly two hours a week by the end, and that every other workstream, including v2.0 release work, depends on funding not yet secured. In its own words, nothing in the roadmap beyond baseline community management should be read as a MobilityData commitment to deliver.

The specification work did move. On September 10 the stub operators table became a crew table with a role and a date range, and on September 15 the companion vehicle_crew table was re-keyed on service date, vehicle, crew member, and start time, with the performed trip made optional so one assignment can span interlined trips. Both landed on the feature branch feeding the v2.0 proposal, which remains open against the development branch and has been recirculated to reviewers twice under the project’s 72-hour rule. On September 30 a reviewer supported the design and asked for clarification of role precedence before it is finalized. A governance update approved by the board on August 27 merged the same day as the roadmap, adding board-chartered working groups and renaming the Issue Working Group to the Issue Resolution Group. The shape of v2.0 we described last month still holds.

In the queue

The GTFS Notices proposal, which would let a feed attach short free-text messages such as “bike reservation recommended” to a trip, a segment of a trip, or a route, moved toward a vote. By September 24 Metro Transit in Minneapolis had published a feed for verification and OpenTripPlanner was exposing the notices in its API. On September 28 the advocate asked the maintainer to confirm the conditions for a vote, and the next day dropped stop-level notices and notice groups from the proposal for lack of test data. MobilityData’s position, stated in the thread, is that a passenger-facing screenshot is recommended before a vote but not yet required by the governance text.

A new proposal opened September 9 would add an optional service_id to transfers.txt, so a transfer rule can apply only on some service days. The motivating case is French rail, where guaranteed connections hold on some days and not others, and producers whose trip identifiers are shared with their real-time feeds will not split trips to express it. A reviewer raised a case that would need the new field in the primary key, which the advocate says would make it a breaking change, and the discussion period was extended two weeks on September 24.

The carriage-position proposal picked up detailed edge cases from the Paris region, where trips sharing a direction can cross a station in opposite directions at dozens of stations. The bike-rack availability fields for GTFS-Realtime were renamed bike_spaces_available and bike_spaces_capacity on September 24. The vehicles.txt proposal and the one for real-time routes that do not exist in the schedule, both in last month’s queue, saw no activity in September. And the GTFS-Realtime revision history we noted as unpublished last month merged on September 9, so the August changes are now in the changelog.

On the calendar

The full list is on our events calendar.

The usual note on shelf life. The merged specification text and the validator rules will age well. The licence vote result, the ownership transfer’s paper trail, and the TIDES branch could all look different by the next edition.