Joint Working Group - City Services

• Every other week call at 9am PT / 12pm ET / 6pm CET

NOTE NEW ZOOM MEETING ID/LINK/PHONE! (as of Jan 1, 2021)

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)

Add your own name, link, and organization during call

• Michael Schnuerle, OMF
• Matt Davis, Populus
• William Henderson, Ride Report
• Steve Brining, BlueSystems
• Marie Maxham, Ellis & Associates
• 18 attendees

Main Topics

1. Temporary City Services WG chair and open position
2. Discussion of any unresolved issues that are a priority
   • Clarifying provider API: https://github.com/openmobilityfoundation/mobility-data-specification/pull/437
   • Crash reporting: https://github.com/openmobilityfoundation/mobility-data-specification/issues/613
   • Provider Operating date-ranges: https://github.com/openmobilityfoundation/mobility-data-specification/issues/628
3. Ending a bit early for the OMF Federal Transportation webinar.
4. Reminder: Take the State of MDS Survey and share it to your partners!

Provider API "data processing" message - Issue 437

• Would be good to add more things.
• Adding new codes would be a non breaking change for 1.2.
• Will tag providers on the issue to see if this is possible/know. Spin and Superpedestrian on the call and looking into it.
• Most operators are sending back 200 response.
• Suggestion to add a 102 response - server is working on this - more appropriate and clear than anything in the 400s
• 400 class errors don’t capture this. It’s not an error, it's that the data/processing hasn't happened yet.

Crash Reporting - Issue 613

• Accident info for cities. Knowing where the crashes occur can be acted on.
• Already requested from many cities in different ways, and received from providers.
  • Some ask for nature of crash, types of vehicles, location/date/time, alcohol.
  • SF takes in self reported data knowing it has data quality issues. Pulling in other sources, try to link incident at hospital with where/it happens.
  • Use cases: infrastructure and public communication of issues/fixes, Europe press/issues with intoxication
  • San Jose gets collision data. Including if someone was under influence.
  • Minneapolis used it for quick build opportunities
• Agree it could be monthly but needs to have more granular data
  • to be useful, at least lat/lon where it happened and time of day. Date in the month is not as important.
• What is a crash, need to define what it is
• Could add injury to capture more data
• Agree it should be aggregate for sure, not on individual trips
• Maybe give exact location and hour, but not day would be possible?
• Police reports are sometimes public record. But other injuries may not be reported for a specific reason by the rider.
• Does it save providers any work? Not if it loses data cities get now, and cities still ask for the more detailed reports. Could help replace requests from new/some cities.
• Quality of data is an issue, since crashes are self reported.
• Could add more data with everything that could be a crash, eg, ‘sudden deceleration’, so there are lots of data points to mask real crash incidents, but provide a novel, useful data stream.
• Deceleration events - providers on call say their hardware doesn't have this yet.

Three main ways this crash data idea could go now:

1. detailed location info for crashes. Privacy a concern. But cities may get this internally and probably more reliably already when there are injuries through police reports
2. aggregated Provider Reports, useful for some cities
3. sudden deceleration data - may not have this info, maybe for future
   • Spin and Superpedestrian on the call don't do/have this.
   • Note from time at Zipcar it's a hard problem.

Issue 628 moved to a future meeting