Frequency type 0 trips must not have delay values

[isabelle-dr]

Issue by barbeau
Sep 11, 2018
Originally opened as CUTR-at-USF#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 a time 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 validator

Expected behavior:

Frequency type 0 trips with delay values should be flagged as an error

Observed behavior:

Frequency type 0 trips with delay values are not flagged as an error.

Platform:

N/A

[isabelle-dr]

Comment by scrudden
Sep 15, 2018

---

Have started working on this on this branch.

[isabelle-dr]

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.

[e-lo]

Suggest updating issue description to include:

Relevant Best Practice text

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.

[e-lo]

Since this is a "best practice" and not in the spec itself (I think), suggest making this a warning not an error.

[barbeau]

@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 with exact_times=0 or omitting the exact_times field - use time for these trips instead.

...or just copy the entire best practice text over.

[barbeau]

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.