When a vehicle is serving multiple trips in a block, it is a best practice to include TripUpdates for the current and next trip. However, there will only be a VehiclePosition for the current trip, and as a result a W003 warning is thrown.
We should improve the W003 implementation so it doesn't throw warnings if there is a TripUpdate for the next trip in the block, and a VehiclePosition exists for the TripUpdate for the current trip.
The GTFS-rt spec also doesn't currently recommend having TripUpdate for next trip in the block, but it should.
Note that another new rule could potentially throw an error/warning specifically in the case where the feed does NOT provide a prediction for the next trip in the block.
Steps to reproduce:
Run validator on feed with TripUpdates for next trip in block
Issue by barbeau Jan 07, 2020 Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/360
Summary:
When a vehicle is serving multiple trips in a block, it is a best practice to include TripUpdates for the current and next trip. However, there will only be a VehiclePosition for the current trip, and as a result a W003 warning is thrown.
We should improve the W003 implementation so it doesn't throw warnings if there is a TripUpdate for the next trip in the block, and a VehiclePosition exists for the TripUpdate for the current trip.
See https://groups.google.com/forum/#!topic/gtfs-realtime/lVPOmi9A5vQ.
The GTFS-rt spec also doesn't currently recommend having TripUpdate for next trip in the block, but it should.
Note that another new rule could potentially throw an error/warning specifically in the case where the feed does NOT provide a prediction for the next trip in the block.
Steps to reproduce:
Run validator on feed with TripUpdates for next trip in block
Expected behavior:
Don't throw W003
Observed behavior:
W003 is thrown
Platform:
N/A