`BlockTripsWithOverlappingStopTimesNotice` error not being caught
Bug report
Describe the bug
Trillium Solutions is building a UI for the gtfs-validator. During our QA process, we encountered a potential bug in which the validator tool doesn't catch overlapping blocks and the BlockTripsWithOverlappingStopTimesNotice rule doesn't get triggered. We've created a GTFS dataset with purposely "bad" data to test the validator.
How we reproduce the bug Steps to reproduce the behaviour:
- Find a GTFS dataset with known block overlaps or use the file we created (gtfs-validator-test-us.zip).
- Run your GTFS dataset of choice through the gtfs-validator.
- Read through the output searching for the
BlockTripsWithOverlappingStopTimesNoticeerror but not find the error message.
Expected behaviour
We would expect the BlockTripsWithOverlappingStopTimesNotice error message to appear with all necessary identifying data points to allow a user to make corrections to the dataset.
Observed behaviour
BlockTripsWithOverlappingStopTimesNotice doesn't appear to be working properly.
Screenshots:
Image is from Trillium Solutions GTFS Manager software
There are six block overlaps that our own software is catching but gtfs-validator isn't.
We think investigating this possible bug at this file location would be a good start main/src/test/java/org/mobilitydata/gtfsvalidator/validator/ and adding more test cases here.
Environment versions
- validator version: 3.0
- Java version: 11
- OS versions: macOS 10.15.7
Please let me know if there's any other info y'all need.
Thank you for your reporting a bug. The issue has been placed in triage, the MobilityData team will follow-up on it.
Thanks for flagging this @rpedraza01 - From the first steps of the troubleshooting it appears that the root of the problem might be deeper than checking the rule's logic We might have to design additional tests to verify that validators were invoked. I'll check with @isabelle-dr and will get back to you shortly.
Hi @rpedraza01! After testing the validator with your dataset, I found the problem. Currently, the validator uses the first and last stop times of each trip to compute the overlap intervals. If at least one arrival or departure time is missing for these stop times, the trip is excluded from the validation process. Specifically for your dataset, the problem is that the last stop time for each trip is missing both arrival and departure times, so the BlockTripsWithOverlappingStopTimesNotice is never generated.
Since the specification is allowing missing arrival and departure times, we should be considering this use case. Here are some options we can consider:
- Select the nearest stop time in the trip if the first or last one is missing time information. This would reduce the time window of the trip, but would still validate the trip. If the arrival or departure time is missing for each stop time in a trip, the trip would still be excluded.
- Keep the rule as is, but generate a
WARNINGnotice, something likeBlockTripsWithStopTimesWithoutTimesNotice, which would indicate a problem with the first or last stop time of a trip. - Implement option 1 and generate a
WARNINGnotice similarly to option 2 if the arrival or departure time is missing for each stop time of a trip.
These are ideas and should also be discussed with @isabelle-dr. She is currently out of the office, back on July 18. @rpedraza01 if you have other ideas or think any of these options would better solve your use case, please let us know :)
Hi @maximearmstrong, just a quick note on your reply:
Since the specification is allowing missing arrival and departure times, we should be considering this use case.
Currently the specification for stop_times arrival_time reads:
(...) An arrival time must be specified for the first and the last stop in a trip.
It also reads for departure_time:
(...) If there are not separate times for arrival and departure at a stop, enter the same value for
arrival_timeanddeparture_time. (...)
So my interpretation of the specification is that it does not allow missing arrival and departure times as in the case of the sample GTFS provided. It allows missing arrival/departure times when they are not the first and last stops of a trip. The trip t_2027500_b_33665_tn_1, for example, is missing the second and the last stop times.
Hi @dhersz, you're right. I missed that yesterday.
In that case, we may need a new ERROR notice, such as stop_time_trip_without_times, which would allow us to detect this problem and indicate that we can't generate the ERROR notice block_trips_with_overlapping_stop_times for the same trip because we are missing time information.
Closing, this is replaced by https://github.com/MobilityData/gtfs-validator/issues/1485