Open isabelle-dr opened 2 years ago
A PR was open on the CUTR-at-USF GitHub repository to fix this issue. I recommend finishing the work there, merging the PR and fetching the results to this repository.
Suggest updating issue description to include:
For trips denoted in GTFS frequency.txt as frequency-based by setting exact_times=0 or omitting the exact_times field In TripUpdate.StopTimeUpdate, the StopTimeEvent for arrival and departure should not contain delay because frequency-based trips do not follow a fixed schedule. Instead, time should be provided to indicate arrival/departure predictions.
Since this is a "best practice" and not in the spec itself (I think), suggest making this a warning
not an error
.
@e-lo I think this best practice text was created as improved language we wanted to incorporate directly into the spec, but that step just hasn't happened yet.
I'd certainly like the spec to be clearer than it currently is right now, but I'd argue that this should still be an error
. StopTimeEvent currently says:
delay should be used when the prediction is given relative to some existing schedule in GTFS.
It logically doesn't make sense to have a delay for an exact_times=0 trip (because there is no schedule to apply the delay to). So a consumer can't process this information.
Ideally the above spec text should be clarified to something like:
delay should be used when the prediction is given relative to some existing schedule in GTFS. It must not be used for trips defined in
frequencies.txt
withexact_times=0
or omitting theexact_times
field - usetime
for these trips instead.
...or just copy the entire best practice text over.
Also, note that after a conversion to RFC2119, the above "should" should become a "must":
delay must be used when the prediction is given relative to some existing schedule in GTFS. It must not be used for trips defined in frequencies.txt with exact_times=0 or omitting the exact_times field - use time for these trips instead.
I recall that an RFC2119 update in on the roadmap for GTFS Realtime but I don't know what that timeline is.
Agreed with above @barbeau. I updated the labels to reflect the need to clarify the spec (and BP) respectfully.
Issue by barbeau Sep 11, 2018 Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/335
Summary:
New rule - If a frequency type 0 trip (a trip defined in frequencies.txt with exact_times=0 or empty) TripUpdate has an arrival or departure
delay
value, this is an error. Arrival and departure times within stop_time_updates for these trips must only have atime
value. This is because by definition frequency type 0 trips do not have a schedule, and therefore they can't be "delayed".cc @scrudden
Steps to reproduce:
Run a feed for a trip defined in frequencies.txt with exact_times=0 or empty that contains an arrival or departure
delay
in a TripUpdate through the validatorExpected behavior:
Frequency type 0 trips with
delay
values should be flagged as an errorObserved behavior:
Frequency type 0 trips with
delay
values are not flagged as an error.Platform:
N/A