Skip to content

Web conference notes, 2021.12.02 (MDS Working Group)

Jump to bottom
Michael Schnuerle edited this page Dec 3, 2021 · 21 revisions

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:

26 Attendees

Agenda

Main Topics

Preparatory work

  • Policy ideas based on real-world usage

    • See LADOT work to incorporate taxis via a 'modality' option. Updates to existing Rules
      • In Policy API Rules, they add modality, accessibility_options array, and service_type (essentially, if the vehicle is on a trip, is it a luxury, shared, or standard ride - not in spec draft yet)
      • Modality has 'micromobility' and taxi' as options. And this note "Given the nature of the differing operational flows, and need for regulators to capture this information, each modality may have different state machines, and different data requirements throughout MDS."
      • Accessibility Options has one option 'wheelchair_accessible' and note "currently only used by the Taxi mode, and is not used by micromobility".
      • Includes different state machines per mode. Micromobility and Taxi.
      • Taxi gets its own state machine diagram too.
      • What about geographies? Any other rule changes needed?

  • Previous WG discussions about modes

WGSC Meeting Organizers

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

Action Items and Decisions

Minutes

Michael summary of the policy document with real use cases. Suggestion to add new real use case from other cities.

Jascha reviewing Modes document

Document here. What is a Mode section is new.

  • Clear rules to determine when a new mode is required
  • note an exact science
  • proposed split of approach :
    • provider api: adding a mode for each query, specify a mode in the request
    • agency api: each vehicles is associated to a mode upon registration
  • rationale: agency has already the look up mechanism in place

Defined by data framework needed by regulators, so micromobility can be bikes and scooters if regulated the same. Review of changes:

  • How to extend the spec
  • Put modes in Provider mode field in request and response
  • In Agency it is not there and instead looked up by ID since Agency has this already
  • Only data for a single mode in an endpoint, not combined
    • JFH don't think multiple modes for the same vehicle will happen frequently
  • Trips now have a trip_type and journey_id
  • journey_id does not have properties, just an ID to link trips
  • Trip attributes - custom array per mode
  • Outstanding items
    • How does policy work in multimodal world? Are they specific to a mode?

Question in chat: but what is the latest thinking on reconciling Agency and Provider in 2.0? It is concerning to me that we would have more operators/modes building implementation on our a fractured scheme

  • Goal? Don’t want new modes to have that
    • WH we turned a technical flavor (push pull) into some functional complexity
  • Push and pull is split? Could be reconciled so there is one system with some push functionality and some pull for history?
  • Marie don’t need them to be identical, but need data aligned, like adding end of trip info in agency
  • Credentials in MDS is easier in Agency for cities. Who is doing the burden of storage? Burden to holder, taxis don’t want Provider to
  • Need more discussion about this… Could be part of MDS 3.0 but we need to talk about it now
  • Ensure gap between them is at least not getting bigger
  • WH Reminder that MDS 1.0 did reconciliation work over a year ago and has yet to be adopted by the majority of operators and cities The reality is that reconciliation work offers very little benefit to individual cities or operators, and is thus unlikely to be prioritized.
  • JFH point of WH very well taken. fair point not an ideal way of starting. We should be talking more about agency provider convergence. Having a dedicated discussion on the matter would be good at WG meeting or separate meeting.
  • Michael - Create issue to discuss

Question: how do you expose a list of supported modes?

  • RH For endpoints that will require a “mode” field, is there a notion of exposing a list of supported modes?
  • MS it is a good question. Could be part of the requirement api? Multiple ways to solve for this
  • JFH http headers could be used too

Policy work in LADOT for taxi modality

  • Policy already supported well
  • Accessibility was important to provide preferential access in certain areas for that in Policy. Added like vehicle type
  • States might mean different things per mode, like what non_operational means for example.
    • So need to define per mode. Put it at the Rules level like in the draft doc
    • It could instead go in the Policy level, multimodal policy not fit well with current paradigm.
    • Interaction between modes in a Policy doesn’t make sense.
  • Service type added, like trip type in suggestion. Types of rides may need different policies or locations.
  • Service type and accessibility may stay in rule instead of at Policy level
  • Could work in vehicle attributes or trip attributes
  • Need docs and policy generator to make it clear how to do very general things… Some sort of plug and play
  • OMF stance on modes, starting point for policy with 80% of common options. Lead with recipe or canonical standards/templates to get started.
    • Could do it at a modeling level
    • [] Open issue about adding to spec or docs.
  • WH Customer segmentation is needed.
  • WH little worried how abstract this can get. I don't think other cities automatically policy json. Suggest out of the box approach, super explicit for a new modes. Suggest 80 - 20 approach What if the OMF could take a more explicitly defined approaches + variations for more complex cities
  • JFH so rather of having a hyper configurable rules engine, we go for common policy and very simple while keeping a generic model for complex use cases
  • WH yes like canonical Ride Hail implementation
  • JFH echo the policy challenge about several ways for coding the same policy
  • MS suggest recipe.
  • WH not saying 1st class example. at the model level let's do different. At a modeling level, mode is a collection of policy rules.
  • BH probably need to customer segmentation as city requirements differ to adjust policy
  • Broad differences between cities like LA vs Louisville vs London, etc could be presented as different use case

omf-mds-github-footer

MDS Wiki Home

MDS Links

Working Groups

2.1.0 Release

2.0.0 Release Plan

1.2.0 Release Plan

1.1.0 Release Plan

1.0.0 Release Plan

0.4.1 Release Planning Meetings

0.4.0 Release Planning Meetings

0.3.2 and earlier Release Planning Meetings

Clone this wiki locally