Since its launch in 2018, The Mobility Data Specification (MDS) has adapted to the real-world needs of cities and agencies. The specification started with an initial focus on understanding trips and vehicle movements and evolved to support more sophisticated use cases like dynamic pricing, real-time policy changes, and equitable distribution of shared mobility assets.
Now, MDS is taking another major step forward: helping cities better understand and respond to crashes, hazards, and other safety-related incidents.
Building on a Strong Foundation
This is a natural evolution for MDS. At the start, MDS was designed to create a real-time digital feedback loop between cities and the companies that operate in the public right-of-way. As mobility services have matured, cities have increasingly used MDS not just to monitor activity, but to actively shape and enforce policy. Recent discussion topics in the MDS working group introduced concepts like “policy-driven geographies” and “digital rules of the road” (see: Digitally Defining the Right-of-Way).
These policy functions of MDS have helped cities ensure that vehicles stay out of restricted areas — temporary or permanent — respect speed limits, and avoid conflicts with pedestrians and other vulnerable road users. But what happens when things don’t go as expected?
Expanding the Specification to Include Incidents
Recent discussions in the MDS Working Group have centered on a new goal: supporting city efforts to collect and act on crash and incident data. During the July 10th meeting, participants explored the potential for MDS to capture information about things like:
- Collisions involving micromobility, delivery robots, or autonomous vehicles
- Hazards reported by riders, operators, or the public
- Near-misses that suggest safety concerns before a crash happens
The motivation is clear: cities need timely, structured, and privacy-conscious data to inform Vision Zero strategies, infrastructure improvements, and safety policy. But this type of data introduces new challenges, too, like:
- What constitutes a crash versus a hazard?
- How should reports from different sources like vehicles, operators, and users, be reconciled?
- And how can this information be standardized while still preserving individual privacy?
Lessons from Past Development
This is not the first time MDS has adapted to new needs. MDS 2.1, which is currently in development (see: Designing MDS 2.1), introduces a more flexible architecture. This architecture allows core components of MDS — like APIs and data models — to be extended or adapted without breaking compatibility, giving cities more control over which data they collect and how they use it. This modular approach is now helping pave the way for the addition of safety-related data.
Similarly, efforts to expand MDS to cover taxis and autonomous vehicles (see: Taxi, AVs, and MDS Policy) highlighted the importance of designing standards that work across modes, operators, and regulatory frameworks. Those lessons inform today’s conversation about how to handle crash reports from fleets that operate very differently and generate different types of data.
What Comes Next
The inclusion of crash and incident data in MDS is still under active discussion. But the momentum is real. Working group participants are currently exploring how a structured incident endpoint might function, how it could align with other existing standards, specifications, and reporting — and how cities could begin piloting this kind of data exchange.
As with all MDS updates, this evolution is being shaped through open discussion and public participation. Get involved in this work by signing up for the MDS working group mailing list — and by registering for our next meeting on August 28.
This is the first in a three-part series about the Read more
Technology and data offer new tools to proactively manage curbs Read more
The 1.1.0 release adds new top level APIs, privacy options, Read more