As discussed in #51 - currently there is an undocumented use case for GTFS-RT where some consumers support real-time platform re-assignment by changing the stop_id in the TripUpdate. Some producers such as MBTA are producing this type of data.
We should allow a mismatch without throwing an error if the original stop_id and the new stop_id belong to the same parent station. Otherwise, it should still be considered an error.
Issue by barbeau Feb 14, 2020 Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/368
Summary:
As discussed in #51 - currently there is an undocumented use case for GTFS-RT where some consumers support real-time platform re-assignment by changing the stop_id in the TripUpdate. Some producers such as MBTA are producing this type of data.
Currently, E045 flags any case where the stop_id and stop_sequence do not match GTFS: https://github.com/CUTR-at-USF/gtfs-realtime-validator/blob/master/RULES.md#E045
We should allow a mismatch without throwing an error if the original stop_id and the new stop_id belong to the same parent station. Otherwise, it should still be considered an error.
Steps to reproduce:
Run validator on MBTA TripUpdates feed:
Expected behavior:
Don't throw E045 on platform changes
Observed behavior:
Eo45 is thrown on platform changes