You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The [`provider`][provider] API endpoints are intended to be implemented by mobility providers and consumed by regulatory agencies. When a municipality queries information from a mobility provider, the Provider API has a historical view of operations in a standard format. It was first released in June 2018.
39
+
The [`provider`][provider] API endpoints are intended to be implemented by mobility providers and consumed by regulatory agencies. Data is **pulled** from providers by agencies. When a municipality queries information from a mobility provider, the Provider API provides historical and recent views of operations. First released in June 2018.
The [`agency`][agency] API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Providers query the Agency API when events (such as a trip start or vehicle status change) occur in their systems. It was first released in April 2019.
45
+
The [`agency`][agency] API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Data is **pushed** to agencies by providers. Providers query the Agency API when events (such as a trip start or vehicle status change) occur in their systems. First released in April 2019.
The [`policy`][policy] API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Providers query the Policy API to get information about local rules that may affect the operation of their mobility service or which may be used to determine compliance. It was first released in October 2019.
51
+
The [`policy`][policy] API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Providers query the Policy API to get information about local rules that may affect the operation of their mobility service or which may be used to determine compliance. First released in October 2019.
The [`geography`][geography] API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Providers query the Policy API to get information about geographical regions for regulatory and other purposes. It was first released in October 2019, originally included as part of the Policy specification.
57
+
The [`geography`][geography] API endpoints are intended to be implemented by regulatory agencies and consumed by mobility providers. Providers query the Geography API to get information about geographical regions for regulatory and other purposes. First released in October 2019, as part of the Policy specification.
The [`jurisdiction`][jurisdiction] API endpoints are intended to be implemented by regulatory agencies that have a need to coordinate with each other. The jurisdiction endpoints allow cities to communicate boundaries between one another and to mobility providers. It was first released in March 2021.
63
+
The [`jurisdiction`][jurisdiction] API endpoints are intended to be implemented by regulatory agencies that have a need to coordinate with each other. The Jurisdiction API endpoints allow cities to communicate boundaries between one another and to mobility providers. First released in March 2021.
The [`metrics`](/metrics) API endpoints are intended to be implemented by regulatory agencies or their appointed third-party representatives to have a standard way to consistently describe available metrics, and create an extensible interface for querying MDS metrics. It was first released in March 2021.
69
+
The [`metrics`](/metrics) API endpoints are intended to be implemented by regulatory agencies or their appointed third-party representatives to have a standard way to consistently describe available metrics, and create an extensible interface for querying MDS metrics. First released in March 2021.
70
70
71
71
---
72
72
73
73
## Modularity
74
74
75
-
MDS is designed to be a modular kit-of-parts. Regulatory agencies can use the components of the API that are appropriate for their needs. An agency may choose to use only `agency`, `provider`, or `policy`. Other APIs like `geography`, `jurisdiction`, and `metrics` can be used in coordination as described with these APIs or sometimes on their own. Or agencies may select specific elements (endpoints) from each API to help them implement their goals. Development of the APIs takes place under the guidance of the OMF's [MDS Working Group](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/MDS-Working-Group).
75
+
MDS is designed to be a modular kit-of-parts. Regulatory agencies can use the components of the API that are appropriate for their needs. An agency may choose to use only `agency`, `provider`, and/or `policy`. Other APIs like `geography`, `jurisdiction`, and/or`metrics` can be used in coordination as described with these APIs or sometimes on their own. Or agencies may select specific elements (endpoints) from each API to help them implement their goals. Development of the APIs takes place under the guidance of the OMF's [MDS Working Group](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/MDS-Working-Group).
76
76
77
77
Many parts of the MDS definitions and APIs align across each other. In these cases, consolidated information can be found on the [General Information](/general-information.md) page.
78
78
79
79
You can read more in our **[Understanding the different MDS APIs](https://github.com/openmobilityfoundation/governance/blob/main/technical/Understanding-MDS-APIs.md)** guide.
80
80
81
-
81
+
82
82
83
83
## GBFS Requirement
84
84
@@ -97,7 +97,7 @@ MDS supports multiple "modes", defined as a distinct regulatory framework for a
@@ -107,7 +107,7 @@ MDS supports multiple "modes", defined as a distinct regulatory framework for a
107
107
108
108
# Versions
109
109
110
-
MDS has a **current release** (version 1.2.0), **previous releases** (both recommended and longer recommended for use), and **upcoming releases** in development. For a full list of releases, their status, recommended versions, and timelines, see the [Official MDS Releases](https://github.com/openmobilityfoundation/governance/wiki/Releases) page.
110
+
MDS has a **current release** (version 2.0.0), **previous releases** (both recommended and longer recommended for use), and **upcoming releases** in development. For a full list of releases, their status, recommended versions, and timelines, see the [Official MDS Releases](https://github.com/openmobilityfoundation/governance/wiki/Releases) page.
111
111
112
112
The OMF provides guidance on upgrading for cities, providers, and software companies, and sample permit language for cities. See our [MDS Version Guidance](https://github.com/openmobilityfoundation/governance/blob/main/technical/OMF-MDS-Version-Guidance.md) for best practices on how and when to upgrade MDS as new versions become available. Our complimentary [MDS Policy Language Guidance](https://github.com/openmobilityfoundation/governance/blob/main/technical/OMF-MDS-Policy-Language-Guidance.md) document is for cities writing MDS into their operating policy and includes sample policy language.
113
113
@@ -177,7 +177,9 @@ To add yourself to the provider list, please let us know [via our website](https
177
177
178
178
An open source approach to data specifications benefits cities and companies by creating a space for collaborative development, reducing costs, and nurturing a healthy, competitive ecosystem for mobility services and software tools. The open model promotes a competitive ecosystem for software tools built by dozens of software companies providing their services to cities, agencies, and providers.
179
179
180
-
- See our **[list of third party software companies using MDS](https://www.openmobilityfoundation.org/mds-users/#software-companies-using-mds)** and an article about the [benefits of an open approach](https://www.openmobilityfoundation.org/why-open-behind-omfs-unique-open-source-model/).
180
+
- See our **[list of third party software companies using MDS](https://www.openmobilityfoundation.org/mds-users/#software-companies-using-mds)** and an article about the [benefits of an open approach](https://www.openmobilityfoundation.org/why-open-behind-omfs-unique-open-source-model/). For a table list with unique IDs, see the MDS [provider list](/providers.csv) which includes both service operators and data solution providers.
181
+
182
+
To add yourself to the provider list (as a data solution providers), please let us know [via our website](https://www.openmobilityfoundation.org/get-in-touch/) or open an [Issue](https://github.com/openmobilityfoundation/mobility-data-specification/issues) or [Pull Request](https://github.com/openmobilityfoundation/mobility-data-specification/pulls). Find out how in our [Adding an Provider ID](https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Adding-an-MDS-Provider-ID) help document.
181
183
182
184
Please [let us know](https://www.openmobilityfoundation.org/get-in-touch/) if you are using MDS in your company so we can add you to the list.
183
185
@@ -233,4 +235,4 @@ Please [let us know](https://www.openmobilityfoundation.org/get-in-touch/) if yo
-`app_name` (text, optional): name of the app used to reserve the trip which could be provider's app or 3rd party app
95
+
-`reservation_type` (enumerated, required): how was the vehicle reserved, one of`phone_dispatch`, `phone`, `text`, `app`
96
+
-`app_name` (text, optional): name of the app used to reserve the vehicle which could be provider's app or 3rd party app
97
97
-`permit_license_number` (string, optional) - The permit license number of the organization that dispatched the vehicle
98
98
-`driver_id` (string, optional): Universal identifier of a specific driver, static across operators, like a driver's license number, for company employees in `reservation` or `empty` trip types, not `private` trips. Could also be used as a lookup in an agency's internal driver system.
99
99
@@ -138,6 +138,17 @@ The `vehicle_attributes` array **may** have the following key value pairs:
138
138
-`toll_transponder` (boolean, optional) - toll transponder for national/regional toll system
139
139
-`phone_charger` (boolean, optional) - a place to charge your phone
140
140
-`sunshade` (boolean, optional) - sunshade available (i.e. for windshield)
141
+
-`cargo_volume_capacity` (integer, optional) - Cargo volume available in the vehicle, expressed in liters. For cars, it corresponds to the space between the boot floor, including the storage under the hatch, to the rear shelf in the trunk.
142
+
-`cargo_load_capacity` (integer, optional) - The capacity of the vehicle cargo space (excluding passengers), expressed in kilograms.
143
+
-`door_count` (integer, optional) - number of doors this vehicle type has
144
+
-`wheel_count` (integer, optional) - number of wheels this vehicle type has
145
+
-`air_conditioning` (boolean, optional) - vehicle has air conditioning
146
+
-`gear_switch` (enum, optional) - one of `automatic`, `manual`
147
+
-`convertible` (boolean, optional) - vehicle has a retractable roof
148
+
-`cruise_control` (boolean, optional) - vehicle has a cruise control system
149
+
-`navigation` (boolean, optional) - vehicle has a built-in navigation system
150
+
151
+
Note many of these attributes come from fields in [GBFS vehicle_types](https://github.com/MobilityData/gbfs/blob/v2.3/gbfs.md#vehicle_typesjson).
141
152
142
153
[Top][toc]
143
154
@@ -182,8 +193,9 @@ Valid car share vehicle event types are
182
193
-`decommission`
183
194
-`fueling_start`
184
195
-`fueling_end`
196
+
-`maintenance`
197
+
-`maintenance_pick_up`
185
198
-`maintenance_end`
186
-
-`maintenance_start`
187
199
-`passenger_cancellation`
188
200
-`provider_cancellation`
189
201
-`recommission`
@@ -224,12 +236,13 @@ This is the list of `vehicle_state` and `event_type` pairings that constitute th
224
236
|`non_operational`|`available`| N/A |`service_start`| The vehicle has went into service (is available for-hire) |
225
237
|`non_operational`|`elsewhere`| N/A |`leave_jurisdiction`| The vehicle has left jurisdictional boundaries while not operating commercially |
226
238
|`non_operational`|`removed`| N/A |`decommissioned`| The vehicle has been removed from the Provider's fleet |
227
-
|`non_operational`|`removed`| N/A |`maintenance_start`| The vehicle has entered the depot for maintenance |
239
+
|`non_operational`|`removed`| N/A |`maintenance`| The vehicle is undergoing maintenance on site |
240
+
|`non_operational`|`removed`| N/A |`maintenance_pick_up`| The vehicle has entered the depot for maintenance |
228
241
|`non_operational`|`non_contactable`| N/A |`comms_lost`| The vehicle has went out of comms while not operating commercially |
229
242
|`on_trip`|`elsewhere`| N/A |`leave_jurisdiction`| The vehicle has left jurisdictional boundaries while on a trip |
230
243
|`on_trip`|`stopped`|`stopped`|`trip_stop`| The vehicle has stopped while on a trip |
231
244
|`on_trip`|`non_contactable`| N/A |`comms_lost`| The vehicle has gone out of comms while on a trip |
232
-
|`removed`|`non_operational`| N/A |`maintenance_end`| The vehicle has left the depot|
245
+
|`removed`|`non_operational`| N/A |`maintenance_end`| The vehicle maintenance work has ended|
233
246
|`removed`|`non_operational`| N/A |`recommissioned`| The vehicle has been re-added to the Provider's fleet after being previously `decommissioned`|
234
247
|`removed`|`non_contactable`| N/A |`comms_lost`| The vehicle has gone out of comms while removed |
235
248
|`reserved`|`available`| N/A |`driver_cancellation`| The driver has canceled the reservation |
0 commit comments