Joint MDS Working Group

• Every week call at 9am PT / 12pm ET / 6pm CET

Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Note: We are now collecting attendees upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:

32 Attendees

Main Topics

• Discussion of new modes in MDS 2.0
  • Review draft Extending MDS to New Modes document - Jascha Franklin-Hodge
    • Previous topics of discussion
• Previous WG discussions about modes
  • Web conference, 2021.07.01 - New Modes Discussion
  • Web conference, 2021.01.28 - Modes, Robots

WGSC Meeting Organizers

• Host: Michael Schnuerle
• Facilitator: Jascha Franklin-Hodge
• Outreach: Michael Schnuerle
• Note taker: Joseph Yawn

Resources

• Slides
• Discussion and Feedback
• Draft Extending MDS to New Modes document
• Meeting Recording - Passcode: C71*9gZ=

Action Items

• Leave your feedback in the discussion area
• Leave specific inline text suggests in the draft Extending MDS to New Modes document

Notes

Supporting New Modes In MDS:

1. How to add new modes?
   1. Car Sharing
   2. Delivery Bots
   3. On-Demand Vehicles
   4. Taxis
2. Design Goals
   1. Flexibility
      1. Flexible architecture
   2. Legibility
      1. Preserve MDS straightforward API
   3. Single-mode Implementation
      1. Should still work for those using one mode (i.e. just using scooters)
   4. Cross-mode Analysis
      1. Understanding how different modes combines into a transportation network. (i.e. looking at Taxi vs E-Scooter trips, carbon impacts, what trips were for, etc).
3. Each mode has its own operating model.
   1. Micromobility is easiest (point-to-point)
   2. Delivery bots do multi-leg trips
   3. Ridehail can be pooled
   4. Car share can have many trips
4. A mode-specific state machine is needed
   1. Matching event-type and reason codes to the specifics of the mode, mode-specific information can be conveyed.
5. Mechanism to describe complex trips is needed
6. Components of a trip differ by mode
7. Flexible relationship model is needed
8. Modes have their own types of vehicles and relevant vehicle characteristics
9. Each mode should have its own set of vehicle types
10. The Policy API is optimized for micromobility
11. Even rule types are similar, each mode will have its own rules

Proposed Changes

1. All possible state and events defined in a single list in /modes/event_types.md and modes/vehicle_states.md. Global list of event types and vehicles states makes it possible to analyze data across modes.
2. Each mode will have its own defined rules for state transitions.
   1. MDS currently defines what state transitions are allowed, but only for micromobility (i.e. currently allowable on_trip to available event_type: trip_end).
3. Global vehicle_type and propulsion_type will remain
   1. Cross-modal analysis may wish to unpack broad patterns in mobility, having a global taxonomy for vehicles and propulsion is valuable.
4. New vehicle_attributes field allows for mode-specific data
   1. Policy-relevant characteristics of a vehicle differ by mode, each mode will be able to define its own with a set of key/value pairs.
5. Every trip record or trip-related event can optionally specify a related_trip_id and a trip_type field
   1. Flexible mechanism for creating relationships and hierarchy within and between trip records.
6. Meaning of related_trip_id and allowable trip_type values are specified on a per mode basis
   1. Each mode can define how to use these fields based on the needs and characteristics of the mode.
7. Policy API
   1. Establish a mode filter for policies
   2. New Policy rule types
8. Create a new Modes Directory that will be a top-level directory that will be added to the MDS repository and will contain mode-specific definitions.

Open Questions:

1. What is a mode?
2. What do we call a mode?

Implementation Questions

1. Does the related_trip_id approach make sense? Or should we formally encode different trip types/elements in the data model?
2. How are modes specified when interacting with APIs and Data?
3. Do we need a mechanism to support more mode-specific data?

Leaving Feedback:

• Document: Extending MDS to New Modes document (share suggested edits)
• Discussion: #652 “Mode Specification Framework in MDS”

Questions from audience:

• Suggestion to use a separate directory to allow alignment between different modes.
• Taxi’s vs Car Share: The driver-mode vs passenger-mode
• We need to define what a trip really is. What is the information that we are looking to gather by breaking this up into trips?
• Ride-hailing is interesting data because we have clear examples and templates on how to analyze these trips and make policy decisions from. Delivery bots, however, are more challenging because the technology and policy are still emerging and lack case studies on analysis. It would be helpful for those working in new modes comment and make suggestions on analysis for these emerging modes.
• Microtransit as a mode between ride-hailing and public transportation could be a place where a mode is needed to be defined.

OMF Announcements

• Next week's meeting is an overview of the Requirements endpoint

New Attendees

• Omar Kabbani (MobilityData)
• Hayden Sutherland | Open Transport
• Mike King: Director of Louisville Metro Office of Advanced Planning and Sustainability