Open barbeau opened 2 years ago
Comment by barbeau Monday Sep 10, 2018 at 19:53 GMT
@scrudden Thanks for your interest in this rule! Here is the tutorial for implementing new rules in the GTFS-realtime Validator: https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/ADDING_NEW_RULES.md
All rules for frequency-based trips (trips defined in frequencies.txt with exact_times=0 or empty) are implemented in: https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/gtfs-realtime-validator-lib/src/main/java/edu/usf/cutr/gtfsrtvalidator/lib/validation/rules/FrequencyTypeZeroValidator.java
...and unit tests are in: https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/gtfs-realtime-validator-lib/src/test/java/edu/usf/cutr/gtfsrtvalidator/lib/test/rules/FrequencyTypeZeroValidatorTest.java
Let me know if you start working on this so we don't duplicate efforts.
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.
Issue by barbeau Wednesday Apr 26, 2017 at 00:17 GMT Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/154
Summary:
From the spec (https://developers.google.com/transit/gtfs-realtime/reference/TripDescriptor):
If
start_time
changes for a trip instance that's exact_times=0 after it's created (for same start_date and vehicle_id), this is an error.This might be tricky to detect, as you need to look at the current and past updates to detect changes. We currently have access to both the current and previous feed message in the validator classes, and I'd like to try to stick to examining only these two messages if possible.
We may not be able to detect this problem in feeds with 100% confidence, so in that case we need to decide if we're comfortable still calling this an error or if we should drop it down to a warning.