One of the most important aspects of launching and sustaining a successful micromobility program is being able to make data-informed decisions to achieve a program’s objectives. To create a foundation of trust and to build a common methodology for understanding and utilizing data, cities and operators need a data sharing standard — that’s where MDS comes in. 

What is Mobility Data Specification (MDS)?

MDS is a framework for standardizing and measuring data. More specifically, MDS is a data specification for sharing micromobility data that agencies and operators can use. It helps them exchange information in a standard format so they can ingest data and build systems to understand program success. 

The Mobility Data Specification (MDS) was originally proposed by the Los Angeles Department of Transportation (LADOT), and created by LADOT and Ellis and Associates. Initially envisioned as an approach to managing autonomous vehicles, Los Angeles refocused testing the specification for micromobility in 2018 with the launch of Bird scooters in Santa Monica, California. MDS is now managed by the Open Mobility Foundation (OMF).

Potential benefits of micromobility data

Micromobility data can help to enforce existing policies — like permit requirements — and inform the basis of new ones — like opportunities to adjust requirements based on data from operations on the ground.

Data can inform the need for infrastructure improvements such as bike lanes or scooter parking. This is especially helpful for cities wanting to understand the first and last-mile utilization and its relationship to public transit. Data can be used to ensure that targeted communities, including those in equity areas, are effectively served. 

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.

Mobility Data Specification overview

MDS consists of a number of Application Programming Interfaces (APIs), including Provider, Agency, and Policy.  

Provider: The most broadly used of the three sub specifications, the Provider API was the first available API and is designed for implementation by micromobility operators, such as Lime and Bird. The Provider API enables regulators to query and attain historical information on trips and vehicle status.

Provider API has two main concepts: status changes and trips. 

What is a status change? 

A status change describes a single micromobility-device-related action that happened at a specific place and time. Think of them as moments in time, such as a device being reserved for use, therefore becoming unavailable. Or a trip being completed and a device becoming available. 

An example of a status change: a user at the intersection of Second and Main streets ends their ride at 2 p.m., making that scooter available for use. When we connect several status changes, we can reconstruct what happened. The status change prior to the one just described may be that the user began their ride at 10th and Cherry streets at 1:45 p.m., making that scooter unavailable for use. 

What is a trip? 

A trip, simply put, is a single journey that was made with a micromobility vehicle. Potential fields for trips include: duration, distance, start and end times, route, cost and parking url. 

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 sets down local rules for mobility service operators. 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.

General Bikeshare Feed Specification (GBFS) vs. MDS

Before MDS, the General Bikeshare Feed Specification (GBFS) was developed to serve bikeshare systems. The spec gives a current snapshot of vehicles on the ground, such as which bikes are available and where, but doesn’t tell you what happened along the way. Its intent was to make bikeshare information publicly available online.

GBFS is limited in its ability to reconstruct or retroactively view data, but is simpler and easier to get started with. GBFS is required as part of MDS. It’s widely used by third-party consumer apps such as transit and map apps to display vehicles from many operators to individual customers. 

Thank you for reading part one of our series on MDS. Here's part 2.

Prefer video learning? Download part 1 and part 2 of our webinar series about MDS.