MDS - CDSM-WG/CDS-M GitHub Wiki

The Mobility Data Specification (MDS) helps cities interact with companies who operate vehicles in the public right-of-way. MDS is a key piece of digital infrastructure that supports the effective implementation of mobility policies for over 115 cities around the world.

Reference

source

Data concepts

MDS has described the endpoints for cities and mobility providers. The mobility provider has a 'provider' module, and the city ('regulatory agencies') has the other modules: 'agency', 'policy', 'geography', 'jurisdiction' and 'metrics'.

Provider

Concept	Remark
trips	A trip represents a journey taken by a mobility as a service customer with a geo-tagged start and stop point.
routes	Geographical representation of the trip
status changes	The status of the inventory of vehicles available for customer use.
reports	aggregated monthly file
special groups	to be used in the reports
events	The /events endpoint is a near-realtime feed of status changes, designed to give access to as recent as possible series of events.
stops	Stop information should be updated on a near-realtime basis by providers who operate docked mobility devices in a given municipality.
vehicles	The /vehicles is a near-realtime endpoint and returns the current status of vehicles in an agency's Jurisdiction and/or area of agency responsibility

Agency

Concept	Remark
vehicles	administer vehicles
telemetry	locations of vehicles
Stop	registration of city-managed stops

Policy

Concept	Remark
Policy
Geography
Requirement	Description of the implementation
Rule (&types & units)

Jurisdiction

Concept	Remark
Jurisdiction

CDS-M Applicable standards

for GDPR related information, see https://www.openmobilityfoundation.org/using-mds-under-gdpr/.

`provider - status changes`

When an asset changes state, it reports it using this endpoint. The asset has a fixed ID, so it can be traced. Pseudo-personal information.

`provider - status changes without IDs`

When an asset changes state, it reports it using this endpoint. The asset has no fixed ID. It is possible to find out where assets are starting a rental or returned.

In the /provider/requirements endpoint you can specify this behavior using the field 'disallowed_fields'. Snippet below:

{
  "metadata": { ... },
  "programs": [
    { ... ,
      "required_data_specs": [
        {
          "data_spec_name": "MDS",
          "version": "1.2.0",
          "required_apis": [
            {
              "api_name": "provider",
              "required_endpoints": [
                {
                  "endpoint_name": "status_changes.json",
                  "disallowed_fields": [
                    "device_id", "vehicle_id", "trip_id"
                  ]
                }
              ...
}

`provider - stops`

All stops are actually reporting the availability on 'stations' or 'hubs'. It doesn't contain any personal information, but, when scraping it, it can tell a bit about the success (or failure) of its operations.

`provider - trips`

Completed trips are reported using this endpoint. It contains personal movements (even trackable due to the fixed ID) and thereby personal information.

`provider - trips without IDs and route`

Similar to the previous one, but now completely stripped.

In the /provider/requirements endpoint you can specify this behavior using the field 'disallowed_fields'. Snippet below:

{
  "metadata": { ... },
  "programs": [
    { ... ,
      "required_data_specs": [
        {
          "data_spec_name": "MDS",
          "version": "1.2.0",
          "required_apis": [
            {
              "api_name": "provider",
              "required_endpoints": [
                {
                  "endpoint_name": "trips.json",
                  "disallowed_fields": [
                    "device_id", "vehicle_id", "route", "parking_verification_url"
                  ]
                }
              ...
}

`provider - trips without IDs and blurred start and end`

It is the same as provider - trips without IDs and route, but now it contains the route, but the start and end MUST be blurred/displaced.

`provider - trips without IDs and start and end`

It is the same as provider - trips without IDs and route, but now it contains the route, but the start and end of the trip MUST be stripped off (randomized number of meters).

`provider - vehicles`

This endpoint contains the current status & position of a vehicle but also specifies characteristics like vehicle type or propulsion type.

`provider - vehicles without IDs`

Same as the previous, but without the IDs and locations (device_id, vehicle_id, last_event_location, current_location)

In the /provider/requirements endpoint you can specify this behavior using the field 'disallowed_fields'. Snippet below:

{
  "metadata": { ... },
  "programs": [
    { ... ,
      "required_data_specs": [
        {
          "data_spec_name": "MDS",
          "version": "1.2.0",
          "required_apis": [
            {
              "api_name": "provider",
              "required_endpoints": [
                {
                  "endpoint_name": "vehicles.json",
                  "disallowed_fields": [
                    "device_id", "vehicle_id", "last_event_location", "current_location"
                  ]
                }
              ...
}

`provider - vehicles non-booked`

Same as the original one, except for the fact that only vehicles are returned that are non-booked (in other words, on the move with people driving it).

`provider - vehicles without IDs and non-booked`

The most strict one. Only the non-booked ones, even without IDs and locations (device_id, vehicle_id, last_event_location, current_location).

MDS Details

Configurable fields

The fields in the JSON are described here, but only those that need explanation. The values in the building block, are fixed, unless they are between square brackets ([]).

name	required	value	description
version	*	[version]	The allowed version(s), comma separated. Replace this value by f.x. "1.2,2.0,2.1"
url	*	[url]	The URL where this file (or endpoint) can be found, f.x. "https://example.transporter.com/gbfs/system_regions.json"
refreshRate		[refresh rate]	The refresh frequency. Specified in 8601 Duration (see https://en.wikipedia.org/wiki/ISO_8601#Durations). f.x. "PT5M" for 5 minutes.

Dimensions

name	value	argumentation
privacy	A	for all endpoints containing data without the combination location/timestamp
	B	for all endpoints containing data with location/timestamp
implementationEffort	D	When it is implemented as separate files, it is the simplest implementation, an A. This limits also the possibility to authenticate, and the available assets files more or less require an API endpoint solution. Therefore it is marked as a D.
reusability	E	This is a domain-specific interface, with very limited possibilities to use outside the scope of city-mobility provider
interoperability	A	This is a worldwide standard (A).
domain	A	Applied in the domain city-transport operator, it is absolutely an A