Joint Working Group - Provider Services

• Every other 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. A count will be posted after the meeting.

19 Attendees

Main Topics

1. Modal Specification in MDS
   • Architecture of overall MDS API schema for new modes and variants.
     • Potential future modes: carshare, passenger services/taxis, delivery robots, drones
     • How does it affect vehicles, trips, events?
     • What is the impact on the state machine? Are there new version or modifications only?
   • Related to Issue #614
   • Want to frame the right questions, discuss possible paths to take, and lay groundwork for mode inclusion.
   • Will not be discussing specific modes, except in relation to the overall topic.

WGSC Meeting Organizers

• Host: Michael Schnuerle
• Facilitator: Angela Giacchetti
• Outreach: Michael Schnuerle
• Note taker: Marie Maxham

Action Items

• Comment in this discussion area about this whole mode topic.
• Turn thoughts into a 3-5 page google doc for sharing and feedback from whole community
• Followup WG meeting to review
• OMF Staff help draft initial mode structure in MDS in an objective way for review by working group

WGSCs

• Board voted in 5 new steering group members 2d ago, 7 per WG, 14 members total
• Discussion about merging WGs but in practice the distinction has blurred; proposal to formally merge. August at earliest, needs board vote. Might go to bi-weekly meetings.

Modes Review

• Currently modes are not specified, are different from vehicles
• Tracked aspects of modes (carshare, taxi, delivery robots) are likely different
• How do we restructure MDS? How much mode-specificity will we need?
• Does it change the definitions of trips and so on?
• #614 was specific to Policy, but likely will have impacts in provider/agency

Need a framework that guides people implementing experiments that might include new/different state machines, or vehicle attributes, etc. Hopefully then new introduced modes will conform to how we think about all modes, not just a particular mode. Don't want to prematurely optimize for e.g. carshare.

Considerations

• Ideally mode work doesn't impact other modes, or as little as possible
• Taxi for example is very different. Multiple simultaneous logical trips are possible.
• From a public policy perspective, keeping modes distinct is very important, for multiple reasons including jurisdictions (e.g. taxi in LA is county, micro is city).
• Conflating modes makes for a very confusing mega-state-machine
• Even very similar modes (taxi, TNC) you have different information, resulting in a lot of "in this case, do A, in this case do B" and the complexity makes it difficult to represent.
• Jurisdiction vary per mode and definitions could be different, eg in LA

Legibility to an implementor vs. legibility (who may need only a single mode) vs legibility for cross-modal data, being able to compare apples to apples in modes. Trips should be as comparable as possible. "Segments" should be comparable. Goal would be to improve cross-modal analysis. Is a unified state machine needed? Or can we "just" have a design goal to enable cross-modal analysis?

Model Options

• Is there a "core" vs. "extension" model?
• How do we make sure that we don't blur the semantics of words in different contexts?
• Agreement in general on concept of base state machine that has modifications per mode

Taxi Example

• Taxi is radically different, with driver and multiple passengers, passenger/party, shared taxis
  • To be clear we are not talking about getting any driver or passenger information, just about how trips, events and states of vehicles are defined.
• Trip structure is very different, travel to, delivery, dwell, travel back,
  • Trip segments are different than others
  • Neil whiteboarded why segments don’t work, gets complicated quickly. Could work but need to be wary of infinite parent/child relationships.
  • Current LADOT mds-core implementation of taxi+micro is pretty clean in a way that a single-state-machine was not. We implemented each and abandoned single-state-machine. That's city-side, not provider side.
• So far mode work for Taxi has been mostly a few additional fields, and trips are similar to micro, but attached to passenger/passenger-groups.
• Single-passenger vs multi-passenger requires changes, but once you have multi, trips/segments look similar.

Questions

• You might have diverse state-machines but you'd keep the semantics of the states and events across state-machines.
• Do trips need a trip hierarchy? Linkages, parent-child, segments? The rules would need to be strict. Multiple models have been proposed in the analytics literature.
• Can we introduce new modes in a non-breaking way? Modality is optional, and defaults to micro. LADOT mds-core added taxi in a non-breaking fashion.
• We can add modality without actually adding a second (official, blessed) mode.
• Can we add another mode and still be truly non-breaking? Probably?

Final Thoughts

• Start with discussion, but turn into white paper, challenges to existing users, walk through proposed strategy. Turn into 3-5 page google doc, solicit feedback from whole community and comments in this doc.
• We should create a white-paper with the thinking about modality where we can put down all the arguments e.g. "legibility for whom". Propose strategies to move forward.
• Want to be careful about not architecting ourselves into a corner with one mode, or making mode changes 'non breaking' when they should wait and be 'breaking' in a release.
• The current 1.2.0 release could be a major release, eg, 2.0.0, if this mode structure needs to be breaking, the proposals are ready, and there is some urgency.

New Attendees

N/A