Propagating delays on dynamically blocked trips triggers E047

[jxeeno]

Summary:

It is not currently possible to provide propagated delays for dynamically blocked services where the vehicle.id is provided for subsequent trips without triggering E047.

For example, an operator wants to communicate delays for subsequent services which are not blocked together in the block_id field in GTFS-static because vehicle allocations are dynamic/day of operation decisions.

In this example, the operator is currently using vehicle.id 1 to operate trip.trip_id A. This trip is currently delayed by 120 seconds. The next service which has been dynamically allocated to vehicle.id 1 is trip.trip_id B.

The recommended best practice is to include TripUpdate for trip.trip_id B to avoid prediction "pop-in". As per docs, VehiclePosition for trip.trip_id B should only be provided for the trip the vehicle is currently serving.

The trip that the vehicle is currently serving should be given through a TripDescriptor.

Steps to reproduce:

TripUpdate feed

entity {
  trip_update {
    trip {
      trip_id: "A"
    }
    stop_time_update {
      stop_sequence: 1
      departure {
        delay: 120
      }
    }
    vehicle {
      id: "1"
    }
  }
}
entity {
  trip_update {
    trip {
      trip_id: "B"
    }
    stop_time_update {
      stop_sequence: 1
      departure {
        delay: 120
      }
    }
    vehicle {
      id: "1"
    }
  }
}

VehiclePosition feed

entity {
  vehicle {
    trip {
      trip_id: "A"
    }
    position {
       ...
    }
    vehicle {
      id: "1"
    }
  }
}

Expected behavior:

The trip.trip_id to vehicle.id matching logic is currently inverted.

The validator should check to see if the trip.trip_id specified in VehiclePosition for a particular vehicle.id is also present in TripUpdate feed. It should not throw an error if the vehicle.id is used in one or more trip.trip_id where block_id is not specified in GTFS static.

Observed behavior:

E047 is triggered:

E047 - VehiclePosition and TripUpdate ID pairing mismatch trip_id A and vehicle_id 1 pairing in VehiclePositions does not match trip_id B and vehicle_id 1 pairing in TripUpdates feed and trip block_ids aren't the same - ID pairing between feeds should match

Platform:

N/A

[e-lo]

This does indeed look like a bug...