Web conference notes, 2021.10.14 (MDS Working Group)

Web Conference

MDS Working Group

• Every other Thursday at 9am PT / 12pm ET / 6pm CET

Conference Call Info

Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom

Attendees

Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:

xx Attendees

Agenda

Main Topics

• MDS releases (Michael)
  • Status on MDS 1.2 release - reviewed by board, could be approved by end of Oct
  • Release plan page for MDS 2.0
  • Change to WG meetings every other week, starting today. How the Provider/Agency WGs used to be.
  • Oct 28 will be first 2.0 meeting, kickoff and planning
• Continuation of discussion about adding new modes in MDS 2.0 (review before meeting)
  • Part 1 notes and summary
  • Draft Extending MDS to New Modes document
  • Discussion and Feedback
  • New: Modes Open Issues document

Preparatory work

• Last week's Modes meeting

  • Meeting notes and summary
  • Slides
  • Meeting Recording and Chat - Password: !7SM0Y3p

• Modes Overview Meeting in August (please watch recording and view slides to prepare for this meeting)

  • Modes in 2.0 meeting details and notes
  • Slides
  • Meeting Recording - Passcode: C71*9gZ=

• Previous WG discussions about modes

  • Web conference, 2021.10.07 - New Modes Discussion, part 1
  • Web conference, 2021.07.01 - New Modes Discussion
  • Web conference, 2021.01.28 - Modes, Robots

WGSC Meeting Organizers

• Host: Jascha Franklin-Hodge
• Facilitator: Sébastien Berthaud, Blue Systems
• Outreach: Michael Schnuerle
• Note taker: Alex Demisch, SFMTA

Minutes

MDS Releases

• 1.2 Reviewed by Tech Council, and under review by board
• 2.0 Release page is up, with tentative features. WGSC will meet next week and potentially revise
• WGSC moved to MDS WG meetings to bi-weekly. WGSC will meet on alternate weeks for planning.

Trip_id and Journey_id

• Initial idea was to use same trip_id object for both lower-level and higher-level trips. However, this can be confusing, so the proposal was modified to add a separate higher-level journey_id that can link individual trip_ids together. Attributes of the individual trip_ids would be used to describe each trip.
• For micromobility, the use of trip_id largely stays the same.
• For a sidewalk robot, a round trip would have two trip_ids under one journey_id. Relationships may differ for carshare, ridehail, and others.
• How do we define journey_id? Is a journey_id about a payload? What you care about has to be defined at the mode level. This is a policy decision. Would be defined in the modal defining file that also defines the state machine and relevant attributes. Just as we can't currently interpret status change events without the state machine, the modal defining file would define relationships between trip_id and journey_id.
• Are there operator-specific data models that would made this difficult? Need more discussion amongst operators. MM: Per-operator anything sounds potentially very complex and a real challenge to regulate. BH: Regulatory needs should drive each the journey_id/trip_id relationships.
• JFH: OMF's goal is to have framework that can enable multiple modes that meets needs for all members. We will likely have to revisit whatever our initial proposal is.
• MS: These ideas for mode structure will be run by providers and cities already using MDS in some way for sidewalk robots, taxis, carshare as we share the proposal/structures that come out of these conversations. So we will have operators there to validate as we work on MDS 2.0.
• Currently, journey_id doesn't have any properties of its own. But as we move along, we may want to provide attributes to journey_id so that trip_ids aren't overloaded with attributes.
• How would default attributes be assigned? We can set by mode. For micromobility, default passenger count is assumed to be 1, and the data would not actually be populated. For car trips, there would be no assumed value and it would need to be populated.
• MS: For ‘passengers’ each mode may not have that attribute. Like robots would not, and that’s ok. There won’t even be a ‘passengers’ attribute with delivery robots.
• Passengers may also be challenging for ride share. How will you know if there is a group of 2/3 passengers? A journey could be defined by number of passengers. A journey could remain the same as long as there are passengers. But we need to discuss this further.
• For rideshare, it may be difficult to know how many passengers there. For pooled rides, customers need to indicate how many passengers there are. But since in an exclusive/non-pooled ride, customers don't indicate this so total passengers isn't known unless the driver were to collect it.
• SN: Is trip is associated with the payload (e.g., a passenger) OR is the trip associated with the state of the vehicle (e.g., number of passengers)? Both ways can be made to work, but I'd like to understand what we are thinking.
• Trip_id might be more related to a transaction. E.g., a delivery truck might be delivering three packages to three customers -- this would be three separate trips.
• MDS 2.0 focus will be on three modes: ridehail, car share, and delivery robots.
• As the group has further thoughts, leave feedback/comments on Slides and Planning Notes.