Announcing the MDS 1.1.0 Release Candidate

December 17, 2020

This Wednesday, a Release Candidate for MDS 1.1.0 was created after 5 months of work by volunteer community members from public cities and private companies. The open source 1.1.0 release adds new top level APIs, privacy options, and transparency features as part of an effort to support requested use cases and take new steps in data privacy.

The Release Candidate is now starting OMF Technology Council and Board review. If approved, this update to the Mobility Data Specification would be released early next year. Follow the progress here and on the release plan

Some specific feature highlights include:

Provider Reports

Mobility providers run special pricing programs for low income groups, often as part of permit requirements to make services more accessible. Typically, communicating the utilization of these programs is done manually between operators and cities with ad hoc monthly reports. The new aggregated reports feature proposed by Spin would add a new endpoint within the Provider API that handles returning monthly trip counts of special groups. The response served up would be a pre-generated CSV file of the data, making the process around this existing reporting requirement more efficient and consistent for providers.

Sample of the kind of data returned via Reports

Public Endpoints

Simply put, this feature allows public agencies to make both the Policy and Geography endpoints unauthenticated and public. This allows transparency for the public to see how a given city is regulating, holds the city accountable for their policy decisions, allows third parties to ingest this valuable information into their applications and services, and also reduces the technical burden on providers to use these endpoints.

Geographic areas in a city defined by the Geography API

Geography-Driven Events

This new feature proposed by Ride Report provides an optional, alternative way to manage providers’ compliance (both real-time and historical) without precise location data. Vehicles would emit events whenever they change geographic areas defined by a city. Then, instead of sharing the exact vehicle location, these events would simply return the ID of the changed geography. While in beta, location data will be returned to allow cities to compare the efficacy of this new policy enforcement mechanism and audit events. 

Geographic areas are used to show device movement, instead of specific locations

City Metrics

There is currently no standard way to retrieve metrics calculated from MDS data or to define a set of useful MDS-based data aggregations. The Metrics API proposed by LADOT with support from Ellis and Associates would act as a standard way to describe available metrics and serve as a mechanism for consistently aggregating data. This new API is intended to help all users of the specification – cities, mobility service providers, and third-party ecosystem services – communicate and share aggregated data using definitions and methodology for certain frequently used metrics, reducing friction and miscommunications. This includes common policy calculations like vehicle counts, trip duration, trip distance, and more. For reduced privacy risk and data minimization, cities (or organizations they designate) can serve the endpoints and share them securely with designated entities. 

Raw calculated metrics data charted over time

 

The Release Candidate and full release notes may be viewed on GitHub.

Related Posts
Announcing the Inaugural State of MDS Survey

Take the survey to help us prioritize the development of Read more

A Kit of Parts: How to Use MDS Vehicles

One way that cities can take advantage of the flexibility Read more

The Vision for the Mobility Data Specification

This is the first in a three-part series about the Read more

STAY INFORMED

[]
1 Step 1
keyboard_arrow_leftPrevious
Nextkeyboard_arrow_right
FormCraft - WordPress form builder

Pin It on Pinterest