Web conference notes, 2021.03.18 (Joint Working Group)
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
- Temporary City Services WG chair and open position
- 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
- Ending a bit early for the OMF Federal Transportation webinar.
- 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:
- 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
- aggregated Provider Reports, useful for some cities
- 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
