MDS Working Group

• Every other Thursday at 9am PT, 12pm ET, 5/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:

28 Attendees

Main Topics

• Kickoff - Steve Brining, Blue Systems (5 mins)
• Extra fields for new modes: Taxis/TNCs
  • Presenter: Alex Demisch, SFMTA
  • https://github.com/openmobilityfoundation/mobility-data-specification/pull/763
• Review use cases and discuss
• Gather feedback

WGSC Meeting Organizers

• Host: Steve Brining, Blue Systems
• Facilitator: Michael Schnuerle, OMF
• Outreach: Michael Schnuerle, OMF
• Note taker: Marie Maxham, Lacuna

1. Add your use cases and data fields as comments on the pull request
2. Consolidate fields from comments into a summary document to determine details of what may need to be added to the PR

New people:

• Vladimir Gallegos - LADOT - dockless planner, GIS specialist, working on taxi stuff
• Jacob Sherman, Portland DOT - regulatory for-hire division
• Marisa Rodrigues McGill - Lyft - Autonomos policy lead
• Andrew Glass Hastings - OMF - new Exec Dir

SF has a variety of transportation management goals and enforcement through data, only scooters are on MDS, but also taxi and corporate transport services

“We’ve re-invented the wheel every time, we’re interested in moving from SF-specific spec to MDS.”

SFMTA is making recommendations to CPUC on TNC regulations, and right now it’s very bespoke-report-based which lacks flexibility

The taxi/TNC lines are getting blurrier due to e.g. Uber dispatching taxis, robot taxis, etc.

SFMTA taxi API looks a lot like provider trip structure but with a lot more info e.g. passenger count, expanded fare info

Also has a telemetry API that looks like a combination of MDS events/telemetry

Bespoke API has three buckets: fields that obviously map to existing MDS, fields that can probably be mapped sensibly based on what’s in the flexible fields, and some is potentially problematic because of personally-identifiable info (PII), whether vehicle info like VIN or driver-ID. Need to consult with the OMF privacy committee, make sure we’re within GDPR, etc.

SFMTA believes a driver in a commercial vehicle has a different standard of privacy than a passenger. Driver’s license, for example, is required to be captured for taxi. Medallions come with minimum and maximum hours driven. Driver info is needed for equity analysis, ability to measure policy impact to driver income, fraud, multiple people operating the same vehicle (among others). This collection is required by SF city/county regulation.

How does SFMTA use this data? We’ve been inventorying the use-cases (work in progress). We have a document that we will publish to a document in the OMF GitHub wiki, to compile with other cities’ use-cases.

SF Use-cases broadly fall in two buckets:

• Health/state of the industry (trip counts, locations, accessibility/paratransit, hail type, trip cost, fare type, etc.)
• Investigations into individual trips for fraud e.g. long-route fraud

Does paratransit obviously fall under taxi, or a separate mode, or … ? At minimum it would be a trip attribute or a vehicle attribute.

Are OMF cities using GTFS-flex for paratransit? Of course its use-cases are public-facing, not regulatory-facing.

Chat question: “With respect to telemetry data from taxis, is the MDS Agency API intended to collect time/location data about vehicles between trips? Or just from the start to end of each metered trip? In other words, could it be used to examine how long vehicles wait or how far they drive before picking up their next passenger?”

This still needs to be codified with respect to “what is a trip”? A trip doesn’t necessarily have to have a passenger, or it could include all of the driving ahead of pickups and drop-offs.

“Is there a way we know the type of TNC? Like is it shared --and may be paratransit can be added as one in that field?”

Yes, we just need to establish how we describe it.

Some types of data might be collectable in the Reports API that are fully aggregated

Using trip_attributes and vehicle_attributes gives a lot of flexibility to collect different data in different jurisdictions according to use-cases. We plan to codify standard as best we can but we don’t want it to be overly-prescriptive while we’re still learning on what varies from jurisdiction to jurisdiction.

“Regarding the deliveries. I think the Passenger services and deliveries' workflows are wery similar and so the definition of a trip and Journey should be the same for both so that it goes in the right direction of standardization. Also : is there a Reason why we focus only on the robots and not on all forms of deliveries ?”

Michael: Agree that similar workflows should be codified similarly. Robots first because we have a concrete example (Kiwibot/Blue/San Jose). We are still thinking about how to codify journeys.

Vlad: lots of taxi-driver records are being maintained for safety/equity for non-ambulatory transit. LA has reporting requirements that consume this sort of mobility data.

Vlad: How do we know if a driver isn’t driving an unsafe number of hours across taxi vs TNCs? Might need to use the same driver ID (eg DL#) across multiple services. Can’t regulate TNCs so can’t really perform this calculation.

Danny Y: Perhaps Lyft/Uber could submit some info on driver activity in order to lower their liability