Release 2.0.0
- Specification
- Release Notes
- 2.0.0 Milestone: Issues and Pull Requests
- Working Group Meetings
According to our semantic versioning, this is a major release and includes items that will break the previous functionality of 1.x.
Working Group members can align to each of these task forces, in scope for MDS 2.0, based on their interest, and report progress back to the WG.
The 2.0.0 major release includes the following features.
Updating MDS to support multiple modes
- #574 - Support for multiple modes/services in MDS
- #652 - Discussion area
- Extending MDS to New Modes - planning document
✏️ Updates the base of MDS to have some shared objects and fields, and specific fields as needed for each mode.
- Mode Attributes - Some fields used across MDS APIs are defined in more detail within each mode.
- Journey ID - allows multiple trip segments to be referentially linked together.
- Trip Type - allows the purpose of each trip segment to be described.
- Trip Attributes - allows additional mode-specific information about the nature of a trip to be described, a list of allowed attributes and values.
- Vehicle Attributes - returns a list of allowed vehicle attributes and values for the operative mode.
- Accessibility Options - returns a list of allowed accessibility attributes and values for the operative mode.
- Mode Properties - Defined properties within each mode, and pulled from options defined in a global location.
- Vehicle States - Vehicle states are used to define the disposition of individual vehicles and fleets of vehicles.
- Event Types - Event types are the possible transitions between vehicle states.
- State Transitions - Possible combinations of how the vehicle state changes in response to each event type.
- State Machine Diagram - The State Machine Diagram visually shows the state transitions.
✏️ Adds specific modes to MDS, with help from Member Networks, and existing real world data exchanges between operators, agencies, and solution providers.
✏️ Operators must register a unique UUID for each mode they operate under. E.g. "Mobility Company A" may operate bike share and taxis, so they would need to register a provider ID for each of these modes: micromobility, passenger-services.
Passenger Services
- #95 - Passenger services/TNC/taxi support
Delivery Robots
- #782 - Support for self driving or remotely piloted vehicles like delivery robots
Car Share
- #640 - Carshare Support including bringing some vehicle properties from GBFS
Work to bring modes together
- #805 - Add a "Data Provider UUID" to MDS
✏️ New data provider id allows endpoints to include who is producing and serving up the data. Software companies and solution providers are encouraged to register for their own global UUID now to serve up operator or agency data with MDS.
- #614 - Support for Modes in Policy, specify which mode your policy applies to
A reimagining of Policy, including:
- #620 - Support utilization policies
- #619 - Clarify minimum vehicle distribution
- #618 - Support vehicle distribution by percent
- #614 - Multimodal support in Policy
- #711 - Clarification on dwell time duration
- #704 - Clarification on possible values of rule_units
- #674 - Move Stops out of beta
- #824 - Policy is now public
- #834 - Updating and ending policy clarification
- #749 - Lookback period clarification
✏️ Top ten most common policies are clearly defined, edge cases (dwell time, trip definition, rule units, updating/ending policies, lookback periods) are clarified, Stops is out of beta, and Policy feeds are public.
✏️ Requirements now supports linking to external use cases, and is moved out of beta because of adoption.
- #759 - MDS Agency and Provider Unification
- Endpoints are now identical
- Data objects are now identical, referenced in new data-type.md file
- Distinction between Agency and Provider is now simply pushing data to agencies, or pulling data from operators
- #550 - Agency trips (related to Unification)
- #722 - Adding trip data to Agency (https://github.com/openmobilityfoundation/mobility-data-specification/issues/770)
✏️ The only difference between Agency and Provider is that with Agency operators PUSH data to cities, and with Provider cities PULL data from operators. Both share the same data types, referenced in a new file, with the same endpoints and fields available.
✏️ Trip telemetry points are no longer in the trips endpoint directly, instead referenced in their own telemetry endpoint. Start and end location only is available in trips.
- #Updates to provider reports including header, date format, column names, and adaptive scooter special group type
✏️ Reports have a new adaptive scooter special group type, and improved formatting.
- #824 - Geography is now public, and removed from Policy
✏️ The Geography endpoint is public.
- #824 - Jurisdiction is now public
✏️ The Jurisdiction endpoint is public.
- Update state machine diagram and create 3 new diagrams for each new modes
- Remove Schema and instead link to OpenAPI repo #281
- Remove Geography from Policy #816
- Authorization consistency across MDS #584
- Make GBFS optional for some modes #769
- Align vehicle types to GBFS #692
- Added maintenance_pick_up event for out of PROW work #595
- Ability to send tip overs, surface type, and parking validation data if available from sensors #829
- Vertical accuracy for GPS telemetry #661
- All vehicle states are now clearly in or out of the right of way, no unknown state #770
- Lots of new provider IDs added
✏️ OpenAPI support in place of JSON Schema allows easier building of real-time MDS endpoint validation, and interactive documentation on Stoplight.
✏️ Updated MDS alignment with GBFS to include all of their vehicle types (including seated scooter) and the addition of new ones for modes (bus, truck, delivery robot, motorcycle), all propulsion types, and to require GBFS for only micromobility and car share (delivery robots and passenger services are option, but not well supported in GBFS).
✏️ New optional fields to include sensors now available and in use in the field by many micromobility companies for tip overs, surface type, and parking validation.
✏️ All vehicle states are clearly in or out of the right of way, no "unknown" state.
Full details are in the Working Group Meetings agendas, and topics are listed in the description of each OMF public calendar event.
See a full list of all release meetings.
| Date | Name | |
|---|---|---|
| 🟥 | June | Start next release work |
| ✅ | 2023-05-09 | Official Release Published |
| ✅ | 2023-05-05 | Board Approval |
| ✅ | 2023-03-29 | Technology Council Recommend to Board |
| ✅ | 2023-03-09 | Technology Council Review |
| Date | Name | |
|---|---|---|
| ✅ | 2023-02-16 | Release Candidate ready |
| ✅ | Jan-Feb | RC Finalization |
| ✅ | 2023-02-09 | Checkpoint 4 - Review - WGSC |
| ✅ | Dec-Jan | Decisions and Consensus |
| ✅ | 2023-01-12 | Checkpoint 3 - Consensus - WGSC |
| ✅ | 2022-10-20 | Checkpoint 2 - Midway - WGSC |
| ✅ | Feb - Nov 2022 | Implementation and Coding |
| Date | Name | |
|---|---|---|
| ✅ | Jan - Feb 2022 | Feature Proposals |
| ✅ | 2022-02-24 | Checkpoint 1 - Plan - WGSC |
| ✅ | Oct - Dec | Set Goals |
| ✅ | 2021-11-04 | MDS 1.2.0 Released |
| ✅ | 2021-10-28 | Release start |
| ✅ | October 2021 | Release preparation |
Status Key:
- ✅ Complete
- 🟡 In Progress
- 🟥 Not Started
