Skip to content
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

Closed
quicklywilliam opened this issue Oct 22, 2020 · 6 comments · Fixed by #653
Labels
Provider Specific to the Provider API Schema Implications for JSON Schema or OpenAPI
Milestone

Comments

@quicklywilliam
Copy link
Contributor

quicklywilliam commented Oct 22, 2020

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.

@schnuerle schnuerle added Schema Implications for JSON Schema or OpenAPI Provider Specific to the Provider API labels Oct 26, 2020
@schnuerle schnuerle added this to the Future milestone Oct 26, 2020
@schnuerle schnuerle modified the milestones: Future, 2.0.0 Nov 9, 2020
@schnuerle
Copy link
Member

See notes from the WG call this week.

  • Providers, is this possible? Speed, heading, accuracy
  • Some could be captured without GPS accuracy
  • Spin doesn’t save this currently
  • Useful to cities to get speed with breadcrumbs from an operator compliance perspective, but also for infrastructure planning to see where speed is too low/high. DC compare corridor speed to bus speed. Baltimore uses radar gun for speed due to being unreliable.
  • Is this possible to capture and save this, is it possible? Can be an optional field for cities to request.
  • London wanted max speed reached per trip.
  • What is real value for cities?
  • Needs more exploring about what is possible, how accurate, who’s doing it. Then use cases for cities. Then how to implement in MDS.
  • Spin will look, OMF can reach out to other operators.
  • Utility from other operators (Ride Report created this discussion)
  • Note PR #73brings this up and adds altitude, vertical/horizontal accuracy.

@quicklywilliam quicklywilliam changed the title Bring rich telemetry data to Provider Bring rich telemetry data to Trips Endpoint in order to improve accuracy of historical analysis Jan 21, 2021
@quicklywilliam
Copy link
Contributor Author

quicklywilliam commented Jan 21, 2021

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!

@schnuerle
Copy link
Member

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.

https://github.com/openmobilityfoundation/mobility-data-specification/tree/release-1.1.0/agency#telemetry-data

Name Type Required? Description
gps.lat Double Required Latitude of the location
gps.lng Double Required Longitude of the location
gps.altitude Double Required if Available Altitude above mean sea level in meters
gps.heading Double Required if Available Degrees - clockwise starting at 0 degrees at true North
gps.speed Float Required if Available Speed in meters / sec
gps.accuracy Float Required if Available Accuracy in meters
gps.hdop Float Required if Available Horizontal GPS or GNSS accuracy value (see hdop)
gps.satellites Integer Required if Available Number of GPS or GNSS satellites

@schnuerle schnuerle modified the milestones: 2.0.0, Next Release Jan 25, 2021
@schnuerle schnuerle modified the milestones: Next Release, 1.2.0 Feb 12, 2021
@schnuerle
Copy link
Member

We'll be talking about this at today's Working Group meeting.

@schnuerle
Copy link
Member

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

@quicklywilliam
Copy link
Contributor Author

Addressed by #653.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Provider Specific to the Provider API Schema Implications for JSON Schema or OpenAPI
Projects
None yet
2 participants