openmobilityfoundation/mobility-data-specification

guidance on how to use telemetry data for compliance

jean-populus opened this issue · 3 comments

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

Telemetry is used to calculate compliance for No Ride and Slow Ride policies but there's no standard for reporting this information. The description -

To represent trip telemetry, the data should include every observed point in the trip...

Allows for a lot of variability in how this information is reported which can affect compliance with these policies.

Cities need guidance on how to use these "pings" for compliance when there might not be enough represent the possible route traveled. For example, we receive telemetry with "ping" on either side of a No Ride zone but none in the middle even though the zone encompasses a large area. Has the scooter gone in a straight line through the No Ride zone? Or has it taken the long way around it?

Describe the solution you'd like

I don't have a proposed solution though we can consider how to increase the frequency (quality) of telemetry when in-trip or formally allowing for the use of generated trip traces for compliance.

Is this a breaking change

  • I'm not sure

Impacted Spec

  • agency
  • provider

Describe alternatives you've considered

none

Additional context

none

Are you thinking there should be guidance on how cities can request this, eg. "telemetry points must be sent at least every 5 seconds"? Or recommendations on how cities should rely on the pings they do get when they are infrequent or inaccurate?

There could be guidance on minimum telemetry points frequency, or acceptance of using best-guess trip trace for compliance.

Currently we've run into a situation where the provider only wants compliance verified using telemetry points but then there's a disincentive to provide good data so the city is pushing back.

It would be great if we could provide guidance on this or incentivize providers to send good data.

With 2.1 we have a chance to add this guidance if you'd like it to be part of the spec itself. If you can propose a wording for this that might get us started.