Photo by Mika Baumeister on Unsplash
What is Mobility Data Specification (MDS)?
MDS is a framework for standardizing and sharing mobility data that agencies and operators can use. It helps operators and cities exchange information in a standard format so they can ingest data and build systems to understand program success. MDS has three sub-specifications: Provider, Agency and Policy.
What do the three MDS sub-specifications, Provider, Agency and Policy, do?
Provider: The most broadly used of the three sub-specifications, the Provider API was the first available API and is designed for implementation by mobility operators, such as Lime and Bird. The Provider API enables regulators to query historical information on trips and vehicle status.
Agency: The Agency API was designed for regulatory agencies to capture specific events, such as trip starts, and allows for the monitoring of mobility services in real-time. Due to significant privacy concerns, such as its requirement of real-time telemetry provided at the start and end of every trip, the Agency API has not been widely implemented.
Policy: Designed for implementation by regulatory agencies, the Policy API allows regulatory agencies to publish clearly-defined rules for mobility service operators to follow.. It enables regulators to set and amend policy guidance by specific geographies, such as speed limits, off-limit areas, differential caps by geographic zone, or equity zones. To protect user privacy as well as limit the information cities collect, Policy does not require real-time service.
What can the MDS Policy API do?
The MDS Policy API differs markedly from the Provider and Agency APIs. Provider and Agency express a common language about how data should be shaped. The Policy API is a common language for rules and regulations. Most communication of rules and regulations regarding micromobility is currently done by cities in formats like email, phone calls, and city ordinances. These formats can be cumbersome, and make rules difficult to enforce.
The Policy API lets cities set rules that operators’ devices need to abide by. It gives them options to ensure distribution of vehicles and coverage for specific geographic areas. The Policy API does this through an open-source standard, GeoJSON, which lets agencies communicate geographies unambiguously.
Our white paper 4 ways cities can put mobility data to work will equip you to better lead your program, define goal metrics, and generate revenue.
Do cities have concerns about privacy issues and MDS?
MDS includes a lot of potential personally identifiable information, especially the full route information contained in trip data, so there are a lot of privacy matters to consider. Ride Report manages the data for many cities and has restrictions on accessing raw MDS data to ensure that data is kept private. The Open Mobility Foundation (OMF) standards group meets monthly to discuss this topic.
What is the difference between public GBFS feeds and the authenticated MDS API?
One of the main differences is that the vehicle IDs are not static in public GBFS feeds. This makes it very difficult to track individual vehicles over time and alleviates some privacy concerns. Cities often require GBFS to allow third parties, such as Google Maps, a way to show the availability of those vehicles.
How much are operators involved in MDS creation and testing?
Operators are heavily involved. The development of the MDS spec takes place on GitHub and biweekly conference calls through OMF. All the major operators are active in the MDS community.
Do operators see feed issues as they arise or do cities or Ride Report have to alert them?
Our MDS Health feature allows cities to see how well their operators’ systems are functioning. From our experience, operators take errors seriously and look to improve them. From time to time we do need to bring an issue to their attention in order to get it fixed. You can learn more about the most common feed issues in this blog post about problem data.
