MDS Crash Report Data in trips and status changes

[tybaltspark]

Is your feature request related to a problem? Please describe.

Several cities are inquiring about crash data. We have been supporting them in linking this data with street usage and existing infrastructure. Crash data are today issued from manual reporting at hospitals. It provides timestamp, location and type of vehicles. This data however is not of high quality, and it is difficult to make meaningful statistics out of it and hence support decision-making on infrastructure or policies.

Describe the solution you'd like

I believe it could be valuable to add this to the /status_changes endpoint. For example, I would see a transition from on_trip to unavailable with event_type = accident/crash.
I don't know to which extent providers can obtain this information "live". Clearly a survey just after a crash is difficult. Some providers have reporting process through the website. I wonder whether the (next generation) vehicles are (will be) able to detect crash with accelerometer & speed data. A good question to operators.
Ideally this would be part of the /status_changes endpoint. However we could also imagine a separate reporting but it may add complexity.

Today, this would be very useful as historical data to get analytics on crash for shared micro-mobility and link it to street segment. However, tomorrow, in a broader context, I believe this is a great step for connected vehicles to report 'live' crash to roadway authorities and emergency services.

Is this a breaking change

I don't believe this is breaking.

Impacted Spec

Provider

Describe alternatives you've considered

An alternative could again be separate monthly reporting in csv by providers where we would see the number of crashes. However this would be left to goodwill reporting by users & providers.

[joshuaandrewjohnson1]

Currently operators rely on users to self-report crashes, with users providing varying levels of detail and accuracy, so reliability of this data can be questionable. Many cities already require us to provide this through a monthly report.

[marie-x]

This would apply to Agency as well

[schnuerle]

As @joshuaandrewjohnson1 says many cities do ask for this as part of a monthly report from providers. So this could be added to the Provider Reports part of the spec. Though in this scenario the result would be in aggregate counts, and not tied to specific trips. Though like mentioned it may not be possible to attach crash info to a trip or status changes in real time - though maybe they could be added a month later so they'd show up in historic data pulls?

[tybaltspark]

@schnuerle could this be discussed at the next working group? ideally with operators
I'd like to understand what is possible technically today and... tomorrow. And how we can serve this objective today with technical constraints and available endpoints. Provider Reports could be a good middle-ground if we can't get this data live at first

[bhandzo]

We (Bird) would not be able to provide crash data via a provider type endpoint, now, or in the future, for a variety of reasons. We do provide this as monthly reporting to many cities.

What constitutes a "crash" is very poorly defined, and there are significant legal requirements about when and how we share information about crashes. We currently rely on riders to report their crashes to us, however even if we had vehicle diagnostics that indicated some sort of collision, that wouldn't be something that could be reported as a "crash" because we would need to know the specifics of what happened (person fell off, scooter fell over when parked, etc.). For all these reasons it wouldn't make sense to add this to provider.

Adding this to a monthly reporting standard makes sense as we are currently reporting it, and it would be helpful for OMF to help standardize the definition of what constitutes a "crash".

[joshuaandrewjohnson1]

Happy to have further discussion, but would like to add a couple considerations on the idea of getting "live" crash data:

• Aside from the question of what can operators actually record from sensor data, as Ben mentioned above, what are we considering to be indicative of a crash? Taking sudden deceleration as an example, this could produce a lot of false positives where a crash didn't actually occur.

• What actions or use cases would a city have with that "live" data? There is a privacy risk with that location data being shared with other departments or agencies if the intention is for some sort of immediate response, in addition to the question of whether or not a crash actually occurred. If it would be used for planning purposes, realistically any actions taken would be based on historical data.

[tybaltspark]

Thanks @bhandzo & @joshuaandrewjohnson1 for the insight.
Today I don't have use case expressed by cities for live data, to be clear. Historical reporting would be enough for the planning and statistics needs asked by authorities. (Live data was an idea for a future need for emergency response)

For the cities we support, we get the "crash" data from the hospitals which label e-scooters, the street location and the date/time. The main goal is to map the crash data with current infrastructure and car traffic data, to get a crash risk analysis and drive investment. The other objective is also to relate that to the actual number of trips vs sometimes misinformed headlines in the press.
--> Monthly reporting is good for these purposes

[tybaltspark]

@schnuerle could this be discussed in the our next calls ? When would be good ?

[schnuerle]

I'll ask the Working Group Steering Committee if it can be a topic for next week's meeting. We can focus on the idea of this in monthly reporting (vs real-time) based on the feedback above from providers.

[tybaltspark]

Sure sounds good with next week's meeting

[schnuerle]

Ok let's talk about this on tomorrow's WG call.

[andrearjona]

It would be useful to cities to obtain acceleration data to inform a host of potential issues (e.g. high pedestrian volume and lack of bikeway infrastructure, and/or a potential barrier or crash). Most cities already obtain higher quality crash reports from other sources- it is the minor collisions that we do not know about because typically these are not reported to companies and/or cities.

[schnuerle]

From the WG Call yesterday:

• 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.

@dirkdk @bhandzo and other providers: would like feedback with your thoughts on what could be useful to you, how you gather crash data, and if you have sudden deceleration hardware/data.

[dirkdk]

Using accelerometer data for crash detection would be flawed. Too many false positives I would guess
I'm not aware of Spin's current vehicles being able to detect deceleration or any plans to work on this.

Crash data for us is human reported and hence fairly delayed. If we would want to include this in MDS, monthly aggregated reports would be my suggestion.

[joshuaandrewjohnson1]

Given the significant challenges that are agreed upon among providers as noted in previous comments, and prior to proceeding further down this road, I'd be interested to hear from cities on current use cases and policy relevance for accelerometer data specifically. Based on the working group discussion, it seems that aggregated monthly data shared by providers satisfies current needs.

[schnuerle]

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track. 

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

This proposal needs work across the board, since currently 3 options are proposed, and there is not agreement on implementation or how it would work, within MDS or from equipment/data available from providers. Agencies certainly would like this data, but people self report and it's not real time so data is minimal. What city would use the sensor data in a meaningful way and rely on it?

Actions: Create a clear proposal based on discussions and see if it's possible and multiple orgs can commit to it.

[mschwartzie]

Even if the consensus is to continue monthly reporting, some standardization of what/how data is collected would be useful. I recommend consulting with entities like Pedestrian and Bicycle Information Center and/or Vision Zero Network research leads as part of this effort.

[bhandzo]

I'm still quite strongly opposed to this. Not because we aren't willing to share information about crashes, but because the definitions here are not nearly well enough defined for this to work.

Sending through raw accelerometer data, or an indication of "sudden decelerations" is not going to be useful to cities, as every provider will define this differently, uses different hardware, and will process this data differently.

[marie-x]

Having come from Zipcar and been hip-deep in telematics, I agree with @bhandzo. IMHO there is no way to make consistent sense of accelerometer data.

[schnuerle]

Elevating this issue again because it has come up numerous times recently in conversations around the MDS passenger services mode, specifically autonomous vehicles and robotaxis where they are equipped with sensors and remote monitoring to pretty accurately know both in real time and historically if a crash occurred. Also applicable to taxis with human drivers. So adding information about if a trip or status_change had a crash and some info about that crash is very possible in these cases, so they could be made optional fields for use in this mode.

[schnuerle]

Per our Working Group meeting last week, there was discussion about this again in the context of road safety.

OMF member Vianova is looking into this with their Road Safety Survey, and this issue is relevant.