Skip to content

Web conference notes, 2021.12.02 (MDS Working Group)

Jump to bottom
Michael Schnuerle edited this page Dec 2, 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:

X 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: TBD

Action Items and Decisions

...

Minutes

Jascha reviewing Modes document What is a Mode section is new. 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
  • 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
  • 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 trips 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
  • [MS] Create issue to discuss

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

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. It could instead go in the Policy level instead, 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 instead of
    • [] Open issue about adding to spec or docs. Customer segmentation is needed, LA vs Louisville vs Nashville, etc
  • MS summary of the policy document with real use cases. Suggestion to add new real use case from other cities.
  • JFH overview of the changes to the new modes document since v1 here
  • changes made based on last call + discussion thread
  • most updates were clarification, to be seen in the tracked change version
  • What is a mode section added.
    • 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
  • WH I know this is tangential, 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
  • JFH don't think multiple modes for the same vehicle will happen frequently
  • clarified hierarchy: introduction of an optional journey_id to accommodate for bots and ride hail for instance
  • addition of trip_attributes to reflect that trip properties may depend on the modes
  • key values pairs
  • example shared for a taxi
  • outstanding item: how does policy work in a multi mode approach?
  • WH suggest not to widen the gap between agency and provider.
  • SB/MS should we implement on one api only ?
  • WH if start fresh, would do similar api for push /pull. ridereport use only providers
  • MM no strong opinion, no need api to be completely identical. Getting the data aligned is what matters. Today some missing data in agency (like after trip metrics distance etc...)
  • WH we turned a technical flavor (push pull) into some functional complexity
  • 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
  • MS dedicated issue for this topic to be created
  • RH For endpoints that will require a “mode” field, is there a notion of exposing a list of supported modes?
  • JFH that could make sense. Have a way to know what mode is supported?
  • 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
  • SB best way to achieve convergence between provider and agency is not to widen the gap
  • JFH fair point but need to make sure new modes work on both
  • 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.
  • MS overview of E&A real world implementation for taxi (here) [https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2021.12.02-(MDS-Working-Group)#preparatory-work]
  • NG more option on taxi than on scooters, example access for mobility disabled travelers addign to the rules. policy requires events and states and those may differ by mode. ex non operational for taxis different than for scooters. Adding modality to policy, at the rule level. Question about the level. Are modes interacting together? might be good to move it up
  • WH +1 to moving it up a level
  • NG service type is the equivalent of trip type and added to the rules mode and accessibility part of the vehicle
  • JFH wondering if trip attributes and vehicle attributes could be used in the policy rules. for ex, accessibility in this case.
  • NG yes could be based on trip attributes. interesting ideas. today all is optional in the current taxi design
  • 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 approach ? + 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

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