search

MobilityData / gtfs-realtime-validator

Java-based tool that validates General Transit Feed Specification (GTFS)-realtime feeds
Other
41 stars 10 forks source link

Frequency type 0 trips must not have delay values #64

Open isabelle-dr opened 2 years ago

isabelle-dr commented 2 years ago

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 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 commented 2 years ago

Comment by scrudden Sep 15, 2018

Have started working on this on this branch.

isabelle-dr commented 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.

e-lo commented 2 years ago

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 commented 2 years ago

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

barbeau commented 2 years ago

@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 commented 2 years ago

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.

e-lo commented 2 years ago

Agreed with above @barbeau. I updated the labels to reflect the need to clarify the spec (and BP) respectfully.