Web conference notes, 2022.02.03 (MDS Working Group)
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:
X attendees
Main Topics
- Kickoff - Sébastien Berthaud, Blue Systems
- Summary based on last meeting - Michael Schnuerle (OMF)
- MDS Task Force recruiting - Michael Schnuerle (OMF), Angela Giacchetti (OMF)
- Task Force Status and Next Steps - Task Force Members
- Modes Architecture Task Force
- Policy Reimagining Task Force
- Unification Task Force
WGSC Meeting Organizers
- Host: Sébastien Berthaud, Blue Systems
- Facilitator: Michael Schnuerle, OMF
- Outreach: N/A
- Note taker: Jean Kao, Populus
...
Modes Task Force
-
Alex Demisch (co-lead)
- Top down approach - architecture white paper
- Bottom up approach - some work with taxi, sidewalk robots, carshare
- participation from people who have worked on MDS with all three modes to drive adoption
-
Sanjiv (co-lead)
- want to elicit input based on implementations that have already occurred with other modes
- continue to revisit architecture paper
- back/forth to make sure architecture maintains or find out where it constrains
-
Michael (OMF)
- if we can get over hurdle of how do we add new modes then can get into details of each new mode
- we have enough info to take a first pass at the architecture
- get pull request to start convo on what framework is going to come
- take what’s in technical documentation and put it into spec
- see wiki link to review work done so far and comment
Policy Reimagining
-
Seb (co-lead)
- mission: increase adoption by a) cover all main use cases, and b) simplify and make sure it’s easy to implement
- next steps
- Creating right participation group
- want to make sure cities are represented, SFMTA, DDOT, want a few more cities
- everything is for adoption so want operator feedback as well
- Which use cases matter
-
Sanjiv
- Do cities expect operators to implement the policy API
- Seb: some cities are asking for this
- In addition to documenting use cases somehow capture value or why, why digitally instead of manually
- Seb: solve for key uses, reason for policy and reason for implementation
- 2 reasons, accuracy, dynamic nature
- Seb: if hard to implement from operator maybe it’s the bottom of the list
API Unification
-
Marie (lead)
- Provider conceived as historical database
- Agency build in parallel more of a real-time active management
- some discrepancies between them, some resolved in v1.0
- shape of API, some fields, some things missing
- mission: rest of cleanup, APIs should be symmetrical so that they work mostly the same
- push vs pull
- cities can implement what makes the most sense but the implementation is the same
- goals
- full data parity so both APIs can cover same use cases
- document design decisions
- straightforward to implement
- don’t want to cause any migration headaches
-
Michael (OMF)
- traditionally cities have to choose either provider or agency
- now a number of cities are using both, provider to get historical data to do analysis, agency to do more dynamic management
- by unifying will be less of a burden on both
Taxi Work at LA
-
Todd Petersen
- how does API Unification intersect with taxi work at LA?
-
Marie: main driver at LA is to be able to implement use cases around taxis that needs trip data - in provider but not available in agency
-
ideal taxi companies are sitting here with us instead they’re being reactive
-
having to act as proxies because they aren’t here
-
Sanjiv
- when proposing taxi for LA are you thinking agency or provider?
- Marie: could be either but initial implementation will be agency
