-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bring rich telemetry data to Trips Endpoint in order to improve accuracy of historical analysis #589
Comments
See notes from the WG call this week.
|
Based on the conversation today, I've edited this issue to focus only on the use case of improving the accuracy of historical analysis of route data. This really only applies to the trips endpoint, so I've removed the language requesting equivalent changes to /status. I've filed #616 to track possible changes to /status, based on the possible use case of wanting to assess compliance with speed-related rules. We see improving historical analysis as the more urgent and pressing use case, but if others are seeing important regulatory use cases please chime in on that issue! |
For some more context, here is what is currently supported in Agency. Note the requirements are all listed as "Required if Available" from the provider.
|
We'll be talking about this at today's Working Group meeting. |
Does anyone feel comfortable making a pull request for this, adding the Required if Available fields and others discussed to Provider Trips? There is a PR #73 but I think it's out of date (and the CLA needs to be signed). |
Addressed by #653. |
Is your feature request related to a problem? Please describe.
Currently, the Trips endpoint does not include full telemetry data including Accuracy, Heading and Speed data. This data is included in Agency via the Telemetry object. Without this additional data, analyzing trip data is limited to only using long/lat coordinate information. Adding the full data (particularly accuracy, heading and speed) would allow for much improved accuracy and a higher success rate, particularly when snapping route data to the road network.
Describe the solution you'd like
Bring full telemetry data to the Trips endpoint, either by replacing GeoJSON points with Telemetry objects or by adding the extra fields as properties in the GeoJSON.
Is this a breaking change
Not-breaking. If the fields were added as properties in the GeoJSON this could be phased in as an optional thing and eventually be made required.
Impacted Spec
provider
Additional context
When cleaning up GPS data to remove erroneous points and snap it to the street grid, it is helpful to have these extra fields as inputs. An obvious implementation that is currently not possible would be to simply throw out points below a certain accuracy, or where heading data is suddenly missing or discontinuous. With slightly more complex approaches, such as a Kalman Filter, having additional inputs to weight on can improve the output. When training a predictive model, features based on heading and speed data perform can particularly well.
This issue supersedes #51, which requested accuracy data for the trips endpoint.
The text was updated successfully, but these errors were encountered: