MDS Working Group

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

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

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

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

24 Attendees

Main Topics

See Modes discussion, part 2 - October 14, 2021

• Discussion about adding new modes in MDS 2.0 (review before meeting)

  • Draft Extending MDS to New Modes document
  • Discussion and Feedback
  • New: Modes Open Issues document

• Modes Overview Meeting (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.07.01 - New Modes Discussion
  • Web conference, 2021.01.28 - Modes, Robots

WGSC Meeting Organizers

• Host: Jascha Franklin-Hodge
• Facilitator: Michael Schnuerle
• Outreach: Michael Schnuerle
• Note taker: Jean Kao, Populus

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

Recap

• Review the 4 Design Goals slide
• Distilled discussions from Aug WG meeting for this meeting and presentation

Open Issues Presentation

Mode

• A mode is a distinct regulator framework for a mobility service

Mode Trip Attributes

• Multi leg trips. Optional journey_id above trip_id
• Trip attributes flexible under mode
• Journey does not have other attributes

Trip data

• Key value attributes per trip

Specifying Mode

• Practically how to implement this
• Connected to provider_id or at trip/event record level
• Know what mode trips are associated with
• Explicitly know by looking at data
• Could allow multiple modes in one response, though we recommend different mode per URL

• Agency and Provider may need different solutions for the level at which to specify mode.
  • Provider at the record level since it's like a ready-to-go database structure for trips, status changes, events.
  • Agency at the vehicle level since redundant data specified elsewhere is not common in Agency
• Mode may need to be added to providers.csv, since GBFS and MDS URLs would be different per mode. But if conflict Provider mode should win over provider id.
• Trips could have multiple uses/modes at once, eg passengers in seats and food delivery in the trunk.
• Idea of 'Requirements' for Providers came up, where providers can publish info about modes, what they have possible/available, how trips overlap for a mode, how journeys work per trip
• Are there any good use cases for why to mix modes in a single endpoints? Group seemed to think no in general. May add more complexity and could have bad overlaps w/ custom state machine diagrams and other mode-specific requirements.

Specifying Mode

• Neil: get Vehicles endpoint has device information, can just define mode there
• MS: still have to cross-reference instead of just being right in there
• MS: have possibility to mix modes within a single response, maybe that’s not the preferred way to do it, for clarity each mode should have it’s own response
• JFH: each request can only request/return info for a single mode, concerned about parsing complexity if allowed multi-mode
• NG: probably more of a provider concern than city concern
• BH: specifying directly is easier than maintaining historic list of all modes, when provider looking back historically would be onerous to give a lookup to a vehicle that had been in a market at some point
• SB: why do we want a mode attached to a trip or device? Where does multimode happen? if we add mode at a very low level(?) that could add complexity
• BH: sidewalk robots
• BH: Lyft example ride-hail and micro mobility
• MS: don’t know yet how complex architecture will be, does any provider have thoughts on mixing modes
• BH: need to think about this more, need to talk to engineering
• NG: if we have one device that’s multi-modal is that even desirable? Driver taking rides for Uber and delivering for UberEats, maybe tie a device to a single mode
• BH: Citroen with different pods can be a passenger or delivery vehicle, metaphysical what constitutes a vehicle? Swap batteries is still the same scooter, but what if swap the brains?
• NG: is the UUID related to the GPS?
• MS: no, UUID can be anything
• BH: support VIN updates but not device ID updates
• BH: fundamentally the modes are coming from separate data pipelines, don’t always like driving design from implementation but in this case it makes sense to derive from what state machine looks like
• MS: to clarify, every mode would have its own state machine
• MS: why we might not want to mix modes in same endpoint, could have scenario where two things happening at same time, like Uber driver picking up passenger with food delivery in trunk
• NG: is there one device operating in multiple modes, one physical device that is actually represented as several devices in MDS
• SB: how does that work on the agency side
• BH: completely different on agency
• BH: way this works in his head, provider is a prebaked db schema, pretty simple
• MS: does anyone prefer CSV file?
• NG: only if a provider provides a single mode
• SB: provider-level is simpler if separate providers for every mode
• BH: prefer not to have providers for every mode, open to higher level representation but provider level, maybe map provider ID to mode
• SB: if same device can belong to multiple mode or worse mixing modes then we really open can of worms
• MS: if we think about adding a new column for provider table for modes, what if there is a conflict if the response contains a different mode, what’s canonical
• MS: argument for adding to CSV is that …..
• BH: big design question whether shard mode at endpoint level or data field level, status changes/micromobility vs status changes with mode as a field

related chat

Neil Goldader to Everyone (9:22 AM) I know in the past I’ve suggested just associating mode with a device. Any reason that wouldn’t work? Seems less onerous than including it on every record

Michael Schnuerle (OMF) to Everyone (9:23 AM) By vehicle_id? Where do you define that, in each endpoint response, or in a separate endpoint like /vehicles?

Neil Goldader to Everyone (9:24 AM) The way we’ve implemented it for Agency so far in our new modes work, is it’s specified on a device_id level when registering a device (POST /vehicles)

So assuming you have a trip, you know what device it’s for, and can look up the mode for that device!

Michael Schnuerle (OMF) to Everyone (9:25 AM) How are you thinking in provider?

Matt Davis (Populus, he/him) to Everyone (9:26 AM) The doc says “the spec should declare that individual API requests should only ever pertain to one mode”, that implies to me that there are separate URLs or request parameters anyway, so that’s already there and we could use it for tracking mode, but that runs counter to the other goal.

Jascha Franklin-Hodge (OMF) to Everyone (9:27 AM) /vehicles doesn’t necessarily return data about retired vehicles.

Jascha Franklin-Hodge (OMF) to Everyone (9:28 AM) /vehicles is intended for vehicles that are currently deployed, not as a historical reference of all vehicles that have ever been in service. So the needed reference data may not always be available for historical records.

Matt Davis (Populus, he/him) to Everyone (9:28 AM) ☝️

Neil Goldader to Everyone (9:28 AM) Perhaps Provider should have an endpoint which provides that info then ;P

Neil Goldader to Everyone (9:41 AM) https://github.com/openmobilityfoundation/mobility-data-specification/blob/main/general-information.md#devices is what I was thinking about

Alex Demisch (SFMTA) to Everyone (9:50 AM) Trip-level

Sébastien Berthaud Blue Systems to Everyone (9:50 AM) provider

Neil Goldader to Everyone (9:50 AM) I’d say trip level

Matt Davis (Populus, he/him) to Everyone (9:54 AM) As soon as you aren’t overloading the provider_id you’re adding a new field, it might as well be a mode identifier?

Matt Davis (Populus, he/him) to Everyone (9:56 AM) Separately, I’m wondering how local “modes” are likely to be. Is it a wild idea to think we can define modes across all jurisdictions, or are we going to need a local program concept that we track in some separate way, like a programs.csv?

Trips/Journeys

• NG: this aligns better than original proposal for taxis, how does this work for delivery robots, what does a trip really mean?
• NG: top thing is journey ID and still have individual trips
• MD: any guidance on whether trips can overlap or have to be distinct
• MS: guidance per mode, could overlap, don’t think there’s a problem with that
• BH: starting to wonder, whether there should be ability for providers themselves to publish how it works for them, allow providers to define themselves rather than WG define for them
• BH: composable state machine is bad idea but way to say these trips are going to overlap, very provider specific how they handle and order trips

related chat

Jonathan Yuan to Everyone (9:31 AM) Can you tell us more about how the journey_id structure will handle chained or overlapping trips?

Zack Bouz to Everyone (9:37 AM) How does mode identification if trips get bundled into a Journey as parent? or is it too early to ask that?