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

> The Mobility Data Interoperability Principles define an open standard with five tests. A new registry grades 55 specifications against them. We counted the verdicts: free and documented is common, open governance is not, and passing all five does not make a standard adopted.

Published 2026-10-09 by Nick Sawinyh.
Explainer in Interoperability.
Canonical: https://its-feed.com/articles/mobility-data-interoperability/
Keywords: mobility data interoperability, mobility data interoperability principles, MDIP, open standards transit, transit data interoperability, open data standards mobility, interoperable procurement

---

On September 30, the coalition behind the [Mobility Data Interoperability
Principles](https://www.interoperablemobility.org/) added a page to its site
that is not in the site's navigation. It is a [registry of mobility
specifications](https://www.interoperablemobility.org/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](https://www.interoperablemobility.org/governance/) 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](https://its-feed.com/articles/transit-operational-data-standard/) to it. MobilityData also
maintains GTFS and, as the [shared-mobility data
stack](https://its-feed.com/articles/shared-mobility-data-stack/) piece covers, GBFS.

## The five tests

MDIP's [glossary](https://www.interoperablemobility.org/definitions/) 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.

![Stacked bar chart of MDIP verdicts on five criteria across 55 specifications. Structured releases: 37 compliant, 2 partial, 9 not compliant, 7 unassessed. Free of cost restrictions: 34, 1, 7, 13. Publicly documented: 33, 3, 11, 8. Independent maintainer: 28, 9, 10, 8. Open governance: 20 compliant, 7 partial, 20 not compliant, 8 unassessed.](https://its-feed.com/charts/mobility-data-interoperability-criteria.png)

*Free, documented, and versioned are the common case. On open governance, as many specifications fail as pass. Source: ITS Feed analysis of the MDIP specification registry, build of 2026-10-01, fetched 2026-10-09. The registry is marked a work in progress.*

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](https://www.cencenelec.eu/about-cen/) 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](https://its-feed.com/articles/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](https://www.interoperablemobility.org/implementation/) 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](https://www.interoperablemobility.org/procurement/) 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.

## Frequently asked questions

### What are the Mobility Data Interoperability Principles?

MDIP is a set of five principles, written in 2021 by a coalition of transit agencies, state DOTs and nonprofits, stating that every system that creates, changes or consumes mobility data should be interoperable through open standards. Cal-ITP incubated it with CalSTA and Caltrans. MobilityData has managed it since 2024 under a memorandum of understanding, and the coalition of public and nonprofit coauthors governs it. Companies can sign on as co-signatories but cannot be coauthors.

### What counts as an open standard under MDIP?

MDIP's glossary sets five tests. The standard must be free of cost and restrictions to use, publicly documented in its entirety, actively maintained by an independent organization with no business interest in its contents, published with structured releases or changelogs, and governed by an open community with transparent, inclusive decision-making. A specification that meets all five is marked MDIP compliant.

### Which mobility data standards are MDIP compliant?

In the registry build of 2026-10-01, 13 of 55 specifications were marked compliant: GTFS Schedule, GTFS Realtime, GTFS-Flex, GBFS, GOFS, TIDES, TODS, MDS, CDS, OpenStreetMap, OpenSidewalks, the OSM BNA Guide, and the OpenStreetMap US Pedestrian Working Group's entry. The registry says its evaluations are a work in progress and findings may change.

### Why is SIRI not MDIP compliant when it is so widely used?

The registry marks SIRI as not compliant on public documentation, because it found schemas but no full public documentation, and on open governance, because it could not find how changes are decided after a pull request. Its cost test is marked unknown because no licence is stated in the repository. Adoption is a separate field: SIRI is listed with more than 100 known adopters.

### Is an open standard enough for interoperability?

MDIP's own documents say no. Its definition of interoperability is about components exchanging data, which requires vendors to implement the standard, export it on demand, and keep up with new versions. The coalition's answer is procurement: agencies write the requirements into contracts, including data ownership, open-standard export, validation on export, and support for a new standard version within 90 days of approval.

---

Source: ITS Feed, https://its-feed.com/articles/mobility-data-interoperability/
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