# 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.

Published 2026-10-02 by Nick Sawinyh.
Roundup in Feeds & Standards.
Canonical: https://its-feed.com/articles/roundup-2026-10/
Keywords: transit data roundup, GTFS ownership MobilityData, GTFS shapes.txt conditionally required, gtfs-validator new rules, GTFS licenses.txt vote, Mobility Database official feeds, TIDES v2.0 roadmap

---

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](https://its-feed.com/articles/roundup-2026-09/) 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](https://mobilitydata.org/transit-open-standard-format-gtfs-transferred-to-mobilitydata-making-the-worlds-leading-transit-data-standard-canadian-owned-and-globally-used/)
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](https://github.com/google/transit/pull/660). `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](https://its-feed.com/articles/what-the-gtfs-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](https://github.com/google/transit/pull/607).

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](https://its-feed.com/articles/transit-data-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](https://its-feed.com/articles/shared-mobility-data-stack/).

## TIDES publishes a roadmap with a deadline already behind it

When we published our [TIDES explainer](https://its-feed.com/articles/tides-transit-data-specification/) 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](https://tides-transit.org/main/governance/roadmap/),
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

- [APTA TRANSform](https://its-feed.com/events/apta-transform-2026/), October 4 to 7, Chicago
- [NABSA annual conference](https://its-feed.com/events/nabsa-annual-conference-2026/), October 6 to 8, Cincinnati
- [TransportationCamp New England](https://its-feed.com/events/transportationcamp-new-england-2026/), October 17, Cambridge
- [ITS World Congress](https://its-feed.com/events/its-world-congress-2026/), October 19 to 23, Gangneung, South Korea
- [TransportationCamp NYC](https://its-feed.com/events/transportationcamp-nyc-2026/), October 24, New York
- [California Transit Association fall conference](https://its-feed.com/events/cta-fall-conference-expo-2026/), October 28 to 30, Monterey
- [Vision Zero Cities](https://its-feed.com/events/vision-zero-cities-2026/), October 28 and 29, New York

The full list is on our [events calendar](https://its-feed.com/events/).

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.

---

Source: ITS Feed, https://its-feed.com/articles/roundup-2026-10/
ITS Feed is an independent editorial site on the data and technology layer of transportation, published by the team at Veodyn. Figures trace to the sources linked inline.
Site index for agents: https://its-feed.com/llms.txt