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:

1. 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.
2. Keep the rule as is, but generate a WARNING notice, something like BlockTripsWithStopTimesWithoutTimesNotice, which would indicate a problem with the first or last stop time of a trip.
3. Implement option 1 and generate a WARNING notice 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_time and departure_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 #1485