Mobility data interoperability, and why an open standard is not enough

On September 30, the coalition behind the Mobility Data Interoperability Principles added a page to its site that is not in the site’s navigation. It is a registry of mobility specifications, 55 of them, each graded against the five tests MDIP uses to decide whether a standard is open. Of those, 13 pass all five. A banner at the top says the evaluations are a work in progress and that findings may change as assessments are reviewed.

The registry is unfinished, and it says so. It is also specific: every assessed verdict comes with written reasoning, and the data behind the page is public. We pulled that data and counted the verdicts. Most specifications clear the tests that people usually mean by open: the text is free and you can read it. The test that splits the field is who gets to decide what the standard says next. And passing every test is a different thing from being used. Several of the most widely deployed standards in the registry fail, and most of the compliant ones have fewer than a hundred known adopters.

MDIP’s own documents have said as much since the start: the Principles “cannot succeed unless they are accompanied by a plan for their implementation.” An open standard is necessary for interoperability and nowhere near sufficient, because interoperability is a property of the systems an agency buys, and a standard cannot make a vendor implement it.

What MDIP is

The Principles were written in the summer and fall of 2021, incubated by the California Integrated Travel Project with CalSTA and Caltrans. They state a vision in which “all mobility data is communicated by interoperable technology components using open standards,” and they set out five principles: every system that creates, changes, or consumes mobility data should be interoperable; interoperability should come through open standards; agencies should have tools that present good data to travelers; agencies and travelers should be free to choose their technology; and the public should be served by well-distributed data while keeping its privacy.

MDIP has two kinds of member. The coauthor coalition is the governing body, and it is limited to public agencies and nonprofits. As of this writing it has 22 members, including LA Metro, the MBTA, TriMet, Sound Transit, Denver RTD, and the state DOTs of Michigan, Minnesota, North Carolina, Oregon, Vermont, and Washington. Companies cannot be coauthors. They can be co-signatories, and the co-signatory list carries 74 organizations and 12 individuals, among them Cubic, Clever Devices, Avail, Optibus, Swiftly, Littlepay, and Transit App.

Day-to-day management sits with MobilityData. The governance page names it MDIP Manager under a memorandum of understanding, and its staff fill the program manager role. MobilityData took over MDIP in 2024, in the same handover from Cal-ITP that moved TIDES and the Transit Operational Data Standard to it. MobilityData also maintains GTFS and, as the shared-mobility data stack piece covers, GBFS.

The five tests

MDIP’s glossary defines interoperability as “the ability for any mobility technology component to exchange data in an open standard or schema with other components” in the same system, and then defines an open standard by five conditions. The registry turns each condition into a graded criterion with written thresholds.

Criterion	Compliant when	Partially compliant when
Free of cost restrictions	It can be obtained, implemented, and redistributed at no cost under an open licence, with no membership or registration	It is free, but needs registration or membership, or the licence limits use
Publicly documented	The complete text is public, with no account or payment	Some sections, profiles, or schemas are available only on request or for a fee
Independent maintainer	An identified organization maintains it and its business interests are not affected by the contents	Industry leads the governing body, one company or agency keeps significant control, or maintenance is irregular
Structured releases	Numbered versions with a public changelog	Changes are visible, but there are no numbered releases or no changelog
Open governance	Anyone can propose changes and take part in decisions on equal terms, through a documented public process	Anyone can comment in public, but a closed group decides, or the process is undocumented

The first two are what most people mean when they call a standard open. The last is the one that decides whether an agency can change the standard it depends on.

What the registry found

The registry publishes its data as static JSON under /api/, built from one Markdown file per specification in the coalition’s public GitHub repository, where changes go through pull requests. We read the build dated 2026-10-01 on 2026-10-09.

Of the 55 specifications, 13 are marked MDIP compliant, 8 partially compliant, and 24 not compliant. Another 9 are marked as inactive projects, and one, a carpooling feed specification, is under review. Most of those last ten have no assessed criteria.

Structured releases is the easiest test: 37 specifications pass it. Cost and documentation follow, at 34 and 33. Open governance is where the field divides, with 20 compliant and 20 not compliant. For four specifications it is the only test they fail outright: MQTT, Overture Maps, GMNS, and SUTI. The registry’s reasoning on the first two shows what the test is asking. MQTT is published free by OASIS, but only paying members can contribute. Overture’s schema is CC BY 4.0 under a Linux Foundation nonprofit, but voting is reserved for its steering and general members.

The European transit standards fail differently. NeTEx, SIRI, OJP, and OpRa, all maintained under CEN, are marked not compliant on open governance. The rationales cite “one vote per EU and some neighbouring countries” and the absence of any public record of how changes are adopted after a pull request. NeTEx and OJP are also marked not compliant on independence, with the maintainer described as a “governmental institution.” CEN describes itself as an association of the national standardization bodies of 34 European countries.

The hard failures are on access. VDV’s eTicket specifications fail four of the five tests: the registry records manufacturer subscriptions from €359 to €1,790 a month and schemas behind a login. ITxPT, an IT architecture for on-vehicle communication in public transport, fails three, with released versions behind a login and in-development versions restricted to members. SAE J2735, the connected-vehicle message set, also fails three, two of them because the full text has to be bought.

Openness and adoption are different axes

The registry records adoption separately from openness, as a tier, and 15 specifications are in the top tier, 100 or more known adopters. Their verdicts spread across every status.

Specification	Maintainer	MDIP status	Criteria failed outright
GTFS Schedule	MobilityData	Compliant	none
GTFS Realtime	MobilityData	Compliant	none
GBFS	MobilityData	Compliant	none
MDS	Open Mobility Foundation	Compliant	none
OpenStreetMap	OSM Foundation	Compliant	none
TOMP API	TOMP working group	Partially compliant	none
IMDF	OGC, Apple	Partially compliant	none
ASAM OpenDRIVE	ASAM	Partially compliant	none
MQTT	OASIS Open	Not compliant	governance
Overture Maps	Overture Maps Foundation	Not compliant	governance
French cycle facilities schema	Etalab	Not compliant	independence
SIRI	CEN	Not compliant	documentation, governance
ITxPT	ITxPT	Not compliant	cost, documentation, governance
VDV eTicket	VDV eTicket Service	Not compliant	cost, documentation, independence, governance
TransXChange	UK Department for Transport	Inactive	independence, governance

Of the fifteen, five pass everything and six are marked not compliant. SIRI, a standard for exchanging real-time vehicle, schedule, and service status information, sits in the top adoption tier alongside ITxPT, and both fail on openness. In the other direction, only 5 of the 13 compliant specifications reach 100 known adopters. Of the rest, six are at early adoption, TIDES is at pilot, and one has none.

The adoption data is the thinnest part of the registry. Only three entries carry an actual count: GTFS Schedule at 2,950 adopters and GTFS Realtime at 632, both taken from the Mobility Database on 2026-09-29, and MDS at 258, taken from the Open Mobility Foundation’s user list on 2026-09-28. Every other entry is a tier, and 20 of the 55 are marked as confirmed by their maintainer.

Who does the grading

The registry is built and maintained by MobilityData, as MDIP Manager. It maintains or co-maintains 7 of the 13 compliant specifications: GTFS Schedule, GTFS Realtime, GTFS-Flex, GBFS, GOFS, TIDES, and TODS. Add the Open Mobility Foundation’s MDS and CDS and the Taskar Center’s OpenSidewalks, and coalition members maintain 10 of the 13. Among the 15 specifications tagged for public transport, four are compliant, and MobilityData maintains or co-maintains all four.

Readers can check that work. Every verdict carries a written rationale, most carry an evidence link, the underlying files are public, and anyone can propose a change. The entries for MobilityData’s own specifications are also candid in places. The GTFS Schedule entry passes the independence test while noting that the GitHub repository is still held by Google, which has delegated admin rights to MobilityData. That matches what we found when we checked the repository after the ownership announcement in September.

The entries for TIDES and TODS pass on independence with the note “Board does include a minority of seats for industry.” When we covered TODS in September, three of its five board seats were held by companies (INIT, Giro, and Keolis Commuter Services), with the MBTA and the Chicago Transit Authority holding the other two. The agencies’ representatives chair and coordinate the board.

The registry also has gaps, as of the 2026-10-01 build. There is no entry for WZDx, the federal work zone feed specification, for APTA’s TCIP, for GTFS-Ride, or for NTCIP 1211, the standard that lets buses and signal controllers from different vendors carry out transit signal priority.

Why an open standard is not enough

MDIP defines interoperability as something a component does: it exchanges data in an open standard. A standard that passes all five tests does nothing for an agency whose scheduling system cannot export it, or exports a version two releases old, or exports it only through a paid module. The coalition’s implementation responsibilities put that obligation on vendors: state that the agency owns the data its systems produce, use open standards to receive, store, and export it, and provide free programmatic access to it. Agencies take on two: help develop open standards where gaps exist, and require compliance with the Principles in procurement.

Procurement is where MDIP’s guidance gets concrete. The coalition publishes model procurement language for scheduling systems, CAD/AVL, and reporting software, and the clauses are specific. All data the system collects, or generates from the agency’s data, belongs to the agency, with full rights to publish it. A fixed-route scheduling system makes GTFS and TODS available in their most recent versions, best practices included. It checks every export against the canonical validator and requires an explicit override to export data that fails. When a standard the system uses publishes a new version, the system should support it within 90 days of approval. The page names three procurements that used the Principles: CALACT’s network analysis tool, Hopelink’s Find a Ride, and MnDOT’s mobility-as-a-service program.

Enforcement is light. An agency whose vendor breaks the Principles is told to notify the coalition, which can help find the loophole in the contract and can remove the vendor from its list of co-sponsors or add the product to a list of “products of concern.” The contract penalty is the agency’s own to write.

The registry says which standards are worth requiring, and the contract is what makes a vendor deliver one. A standard can pass all five tests and still reach an agency only when that agency replaces a system, which happens on a cycle of years. That is the adoption path the TODS site describes for itself, and the registry’s adoption tiers show where it has got to so far.

What to watch

The registry is unlisted and marked as provisional, and every number above is a count of the 2026-10-01 build. The first thing to watch is whether it moves into the site’s navigation and whether the verdicts change when it does. Real adopter counts would make the adoption column checkable; today most entries carry a tier, which is a judgment. Entries for WZDx, TCIP, and NTCIP 1211 would put the highway and signal side of the data layer under the same five tests. The last question is whether any public transport specification not maintained by MobilityData reaches compliant status. Until one does, every transit standard the registry calls open is one that MobilityData maintains or co-maintains.