Roundup · Quality & Compliance
August 2026 roundup: the NTD goes public, MDS 2.1 ships, and alerts get a clock
What moved on the transportation data layer from mid-July to early August 2026: FTA's Transit Moves America dashboard, a federal question about whether real-time data counts as service quality, the MDS 2.1 release, and two new GTFS-Realtime alert fields.
A monthly scan of what actually moved on the data and technology layer of transportation. This edition runs from roughly mid-July to the first week of August 2026. The thread running through it is reporting: who has to publish what, in which format, and who reads it. Federal transit data that used to require a spreadsheet download got a consumer-facing front end, the shared-mobility spec shipped the release it previewed a month ago, and GTFS-Realtime resolved a long-standing ambiguity in how service alerts describe time.
The National Transit Database gets a consumer front end
The FTA launched Transit Moves America on July 23, a public dashboard built on National Transit Database submissions. It puts national safety and security averages next to agency-level figures, separates bus from rail so systems are compared against their own mode, and shows operating cost per passenger trip for the 25 largest urban areas. Safety and security figures refresh monthly; accessibility and efficiency measures refresh annually.
FTA Acting Deputy Administrator Matthew Cahill said the dashboard “brings key performance data out of obscure spreadsheets and puts it in the hands of American transit customers”. The collection itself is not new. These are NTD submissions, and anyone willing to download the annual data products could already work them out. What changed is the distance between an agency’s filing and a rider looking at it, which is now about one click. An annual compliance obligation and a public comparison built on the same numbers put very different pressure on the people who prepare them, and that is the part operators should plan around.
Real-time data availability, as a scored attribute
The dashboard did not appear on its own. It follows a June 4 request for information on family-friendly transit, docket FTA-2026-0232, which asked the industry and the public how service quality should be assessed across five areas: safety and security, cleanliness, universal accessibility, real-time service data availability, and system reliability. Comments closed on August 3.
The fourth one is our beat. Real-time service data availability is listed alongside cleanliness and reliability as a property of the service itself, not as an IT deliverable sitting behind it. If that framing survives into whatever measurement comes out of the docket, the practical consequence is that an agency’s GTFS-Realtime feed stops being an optional nicety maintained by one person on the planning side and becomes something the agency is scored on. Worth watching, though an RFI is the earliest possible stage of anything.
MDS 2.1 is out of preview
The Open Mobility Foundation released MDS 2.1 on July 20. We covered the preview last month, and the shipped version tracks it: an endpoint for safety incidents covering collisions, near misses, harsh braking, remote takeovers, autonomous-driving disengagements, obstructions, theft, vandalism, and unplanned stops; broader delivery support spanning app delivery, goods, freight, and packages rather than only sidewalk robots; clearer handling of for-hire autonomous services; and improved geofencing for real-time digital policy. OMF puts the development at two years and hundreds of contributions.
Two additions matter more than the headline features. The release adds an external references mechanism for cross-linking to other specifications, and it adds fixed-route transit integration with GTFS. Both point the same direction. MDS is being wired to sit alongside the other specs a city or agency already runs, rather than standing apart as its own regulatory island.
GTFS-Realtime learns the difference between telling and happening
A small change landed in the GTFS spec that anyone building alert displays will feel. The
active_period field on a service alert was always ambiguous: it could mean the window in
which the alert should be displayed to a rider, or the window in which the service is
actually disrupted. Producers read it both ways, so consumers could not tell which they were
getting.
Two new fields resolve it. communication_period
is when the alert should be shown for informative reasons, and impact_period is when
services are actually affected by the disruption. They are mutually exclusive with
active_period, so existing feeds keep working. The change merged June 30 and appeared in
the specification’s June revision history on July 9.
Anyone who has tried to build a rider-facing alert display, or to measure how far in advance an agency warns people about a planned outage, has run into this. A two-week heads-up about a weekend shutdown and a shutdown currently in progress were the same shape in the data, and now they do not have to be.
On the calendar
APTAtech runs August 9-12 in St. Louis, with fare payment, data governance, and cybersecurity on the program, and it is co-located with the scheduling and operations planning workshop. MobilityData’s International Mobility Data Summit follows on September 22-23 in Montréal. Both are on our events calendar.
The usual note on shelf life. An RFI is a long way from a rule, and the first cut of a public dashboard usually gets revised once agencies see how they look on it. The direction each of these points is steadier than any single date here.