September 2026 roundup: alert images go final and an unwritten GTFS rule gets written

A monthly scan of what actually moved on the data and technology layer of transportation. This edition runs from early August to the first week of September 2026. Last month the thread was reporting, who publishes what and who reads it. This month it is the specification itself. GTFS merged two changes on the same August afternoon, and both land on the desk of whoever maintains your feed.

Service alert images stop being experimental

GTFS-Realtime service alerts have been able to carry a picture since 2021, from a proposal filed that September and merged in November. The image field, the image_alternative_text field that describes it, and the TranslatedImage message that holds per-language versions all arrived together, and all three carried the same caution in the reference: still experimental, subject to change, may be formally adopted in the future.

That caution is gone. The proposal removed the experimental note from the protocol buffer definition and from the specification text, and it merged on August 17. The fields are ordinary parts of GTFS-Realtime now.

Experimental status in this specification is not a formality. It is the reason a consumer can reasonably decline to build against a field, and the reason an agency can reasonably decline to populate one, for years at a stretch. Removing it does not change a single byte in anyone’s feed. It changes the answer to “is this safe to depend on,” which is the question that has held both sides back.

The proposal lists Metro Transit in Minneapolis, TransLink in Vancouver, the MBTA, VTA in the Bay Area, and Mecatran as producers already publishing images, with Transit as a consumer that parses them. Those are the proposer’s own testing notes rather than an independent survey, and the consumer side comes with a caveat worth knowing before anyone plans around it: Transit reads both fields and can show the image next to the alert text, but the display is off by default and has to be turned on, and the proposal names only two of those agencies whose images it renders today.

The specification is clear about what the picture is for. It exists to explain the effect of a detour or a station closure visually, and images that are mostly text, or that are marketing and branding with no added information, are discouraged. Anything essential in the picture has to appear in the alert text as well, so the rule is about accessibility as much as design. An agency that already draws a detour map for its website has the source material sitting there.

One note for anyone who reads the changelog instead of the reference. The pull request updating the GTFS-Realtime revision history for August was still open at the end of the month, so this change does not show up there yet.

An unwritten rule finally gets written down

The second merge that afternoon is one line in a table and much larger in practice. min_transfer_time in transfers.txt moved from Optional to Conditionally Required: required whenever transfer_type is 2, optional otherwise. Transfer type 2 is the one that says a connection needs a minimum amount of time between arrival and departure, and the amount is what min_transfer_time holds. Declaring that kind of transfer and then leaving the duration blank was always incoherent. Until August 17 it was also, formally, allowed.

The proposal came from a developer at the MBTA, and the stated reason is worth reading twice. The agency’s feed had been rejected by Google for not meeting a requirement that the specification never actually imposed. Google’s consumer read the wording as a rule. The reference said the field was optional. Both were defensible readings of the same paragraph, and the agency sitting between them found out which one counted at rejection time.

This is the most useful category of spec change for anyone who runs a feed. A de facto rule enforced by the consumer most feeds are built to satisfy became text you can cite in a ticket and validate against. The change is classified as non-functional, so it adds no capability, and a feed that Google already accepts almost certainly meets it. Feeds that use timed transfers and left the field empty now have a documented defect instead of an undocumented one, which is the better problem to have.

MDS 2.1 meets the 911 dispatch system

The Open Mobility Foundation published a walkthrough on August 27 of what the MDS 2.1 Policy API does with an emergency. We covered the 2.1 release when it shipped in July, alongside the rest of the shared mobility data stack. This is the first account we have seen of it wired to a dispatch system.

A city’s computer-aided dispatch system, the 911 software, takes a fire or medical call and translates it into MDS with a standard set of fields covering severity, location, and type of emergency. Where the response closes streets, an associated geofence goes out with it, and the Policy API delivers both to autonomous vehicle operators so they can route around the scene, slow down, or limit pickups and dropoffs inside it. The geofence resizes as the response grows or shrinks, and an all clear retires it when the incident ends.

What it replaces is the interesting part. By the OMF’s description of current practice in California, one city sends alerts by text message, another by email or phone call, and another posts to social media, none of it in a form a machine can act on without a person in the middle. The foundation also points to new California rules requiring AV companies to honor city-generated geofences around emergency response zones, which is the deadline pressure behind this. Waymo and Zoox are both named, and both are OMF members, so read the enthusiasm accordingly.

The prototype ran in a test environment in Seattle, built by the city’s transportation department with Seattle Fire and Blue Systems, the department’s software vendor, and shown at the MDS working group meeting on July 9. A test environment is not a deployment. The path from a working prototype to dispatchers leaning on it during a real warehouse fire runs through procurement and training, which is slower work than writing the field was.

In the queue

The GTFS repository has three open proposals that would each change what a feed carries, and all three saw activity in August.

The first would add licence information to the feed itself, through a licenses.txt file that names an SPDX identifier, the standard machine-readable name for a common licence, or a URL for a custom one, with the option of different terms for different files. This is the spec side of a gap we measured last month. Licence declaration in the Mobility Database sits at 138 of 914 non-deprecated US feeds, roughly 15 percent, against 76 of 90 in France and every one of Sweden’s 59. Declaring a licence does not by itself get an agency’s stops into OpenStreetMap, since Sweden manages a perfect declaration rate and only 707 tagged stops, but a volunteer who can find no terms at all has to leave the data alone. The word licence does not appear anywhere in the GTFS Schedule reference today, so an agency willing to grant permission has nowhere in the feed to say so.

The second would add a vehicles.txt file describing the capacity, accessibility, appearance, and features of individual vehicles, so that a real-time vehicle label can be joined to what the rider will actually see pull up: the size and color of the bus, whether it has bike storage or a restroom, and which accessibility features it carries. It had drawn 34 comments by the end of August and is the most actively argued of the three.

The third would let a real-time feed define routes that do not exist in the schedule. Today, service invented on the day has to borrow an unrelated static identifier or go unrepresented, which is a familiar problem for anyone working on flexible and demand-responsive service. Clever Devices is running a producer test feed and Transit is building the consumer side.

None of the three has merged, and open proposals in this repository can sit for years. The licence one has been open since February.

On the calendar

NEORide’s annual meeting runs September 8 and 9 in Cincinnati, and Mpact Transit + Community follows September 14 to 17 in Toronto. MobilityData’s International Mobility Data Summit is September 22 and 23 in Montréal, overlapping MOVE America on the 23rd and 24th in Detroit. APTA TRANSform is October 4 to 7 in Chicago. All are on our events calendar.

The usual note on shelf life. The merged specification text will age well. The prototype and the queue could both look different by the next edition.