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

Clarification of TripUpdate.timestamp #263

Merged
merged 2 commits into from
Apr 9, 2021
Merged

Conversation

ericouyang
Copy link
Contributor

In scenarios where StopTimeUpdates are specified for events in the past, there may be multiple "Moment[s] at which the vehicle's real-time progress was measured" as a part of a TripUpdate when there are StopTimeUpdates for events in the past. This proposal explicitly specifies that the appropriate timestamp to use is "The most recent moment at which the vehicle's real-time progress was measured to estimate StopTimes in the future."

One scenario where this ambiguity has created challenges is when a TripUpdates consumer relies on this timestamp to understand how old a particular prediction is for the purposes of better understanding the accuracy of predictions.

StopTimeUpdates in the past are important for informing passengers about recently departed trips, especially when a vehicle is running early, as described in the TripUpdates spec:

Producers should not drop a past StopTimeUpdate if it refers to a stop with a scheduled arrival time in the future for the given trip (i.e. the vehicle has passed the stop ahead of schedule), as otherwise it will be concluded that there is no update for this stop.

As such, additional language has also been added in-line to make this behavior explicit: "When StopTimes in the past are provided, arrival/departure times may be earlier than this value."

@google-cla google-cla bot added the cla: yes label Mar 8, 2021
@ericouyang
Copy link
Contributor Author

I've called for a vote on this clarification for adoption on the Google Group (https://groups.google.com/g/gtfs-realtime/c/6wo_0jC6lQ0/m/ZyjO6DwoBQAJ).

Please vote with a +1 (in favor) or -1 (against) before Tuesday, March 30th at 23:59:59 UTC. Thanks!

@skinkie
Copy link
Contributor

skinkie commented Mar 22, 2021

+1

@brodyFlannigan
Copy link

+1 for Brody Flannigan Transit Data.

@gcamp
Copy link
Contributor

gcamp commented Mar 23, 2021

+1 Transit

@paulswartz
Copy link
Contributor

+1 MBTA

@harringtonp
Copy link

+1 YourStop

@sam-hickey-arcadis
Copy link
Contributor

+1 IBI Group

@ericouyang
Copy link
Contributor Author

Thank you all for participating! The vote ended on Tuesday, March 30th at 23:59:59 UTC with a unanimous consensus of 6 yes votes from OpenGeo (@skinkie), Brody Flannigan Transit Data (@brodyFlannigan), Transit (@gcamp), MBTA (@paulswartz), YourStop (@harringtonp), and IBI Group (@sam-hickey-ibigroup).

As per the specification amendment process, this proposal is now accepted!

@barbeau barbeau merged commit 972f306 into google:master Apr 9, 2021
@ericouyang ericouyang deleted the patch-1 branch April 10, 2021 00:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants