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

> What moved on the transportation data layer from early August to early September 2026: two GTFS merges on the same day, MDS 2.1 emergency zones prototyped in Seattle, and three proposals in the queue that would change what a feed carries.

Published 2026-09-04 by Nick Sawinyh.
Roundup in Feeds & Standards.
Canonical: https://its-feed.com/articles/roundup-2026-09/
Keywords: transit data roundup, GTFS service alerts, GTFS transfers min_transfer_time, MDS 2.1 emergency response, GTFS licenses.txt, GTFS spec changes

---

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](https://its-feed.com/articles/roundup-2026-08/) 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](https://github.com/google/transit/pull/651). 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](https://github.com/google/transit/pull/640): 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](https://www.openmobilityfoundation.org/mds-emergencies/).
We covered the 2.1 release when it shipped in July, alongside the rest of the
[shared mobility data stack](https://its-feed.com/articles/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](https://github.com/google/transit/pull/607),
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](https://its-feed.com/articles/transit-data-in-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](https://github.com/google/transit/pull/621).
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](https://its-feed.com/articles/what-is-gtfs-flex/). 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](https://its-feed.com/events/).

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.

---

Source: ITS Feed, https://its-feed.com/articles/roundup-2026-09/
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