VehiclePositions - Check that there is at most one vehicle assigned to each trip

[barbeau]

For VehiclePosition - there should be at most one Vehicle assigned to each trip_id in TripDescriptor. If there is more than one VehiclePosition with the same trip_id, this would generate an error. See https://groups.google.com/d/msg/gtfs-realtime/qNc7ButQbW8/tDwanvClBQAJ.

Note that this is different from vehicle.id being unique, which is ticketed at https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/254.

[barbeau]

From https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/vehicle-positions.md:

A single vehicle position should be provided for every vehicle that is capable of providing it.

...but this doesn't address if more than one vehicle can be assigned to the same trip.

I saw the following in MBTA's VehiclePostions feed, which has more than one vehicle assigned to the same trip prior to the trip starting:

{
      "id": "1499450801_y0512",
      "vehicle": {
        "trip": {
          "trip_id": "34616300",
          "start_date": "20170707",
          "route_id": "110",
          "direction_id": 0
        },
        "position": {
          "latitude": 42.402454,
         "longitude": -71.075714,
          "bearing": 217
        },
        "current_stop_sequence": 1,
        "current_status": "STOPPED_AT",
        "timestamp": 1499450711,
        "stop_id": "5271",
        "vehicle": {
          "id": "y0512",
          "label": "0512"
        }
      }
    },
    {
      "id": "1499450801_y1446",
      "vehicle": {
        "trip": {
          "trip_id": "34616300",
          "start_date": "20170707",
          "route_id": "110",
          "direction_id": 0
        },
        "position": {
          "latitude": 42.402485,
          "longitude": -71.07634,
          "bearing": 217
        },
        "current_stop_sequence": 1,
        "current_status": "STOPPED_AT",
        "timestamp": 1499450753,
        "stop_id": "5271",
        "vehicle": {
          "id": "y1446",
          "label": "1446"
        }
      }
    },

[barbeau]

https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/trip-updates.md says:

There should be at most one trip update for each scheduled trip.

It seems to me that this, plus the ADDED documentation -

ADDED - An extra trip that was added in addition to a running schedule, for example, to replace a broken vehicle or to respond to sudden passenger load.

...implies that only one vehicle should be assigned to each trip.

About the above data, MBTA says:

At the time NextBus (which produces a gtfs-realtime bus data feed for us) was making a prediction that both of those buses would be operating on that trip. That prediction was almost certainly incorrect, but the data in the feed was correctly representing that prediction.

NextBus will represent multiple vehicles on a trip to handle cases in which an agency assigns puts extra service on the street. The way they represent this in their API spilled over into the way they represent this in their GTFS-realtime feed, and we weren't aware of a precedent saying that that wasn't allowed, so that's how it went into production.

If we missed a precedent or if future best practices indicate that that shouldn't be done, then we'll make plans to change the behavior in the future. And it probably would make more sense to have a rule that each trip_id can only appear once, although GTFS-realtime needs to have a way to add trips (with headsigns and directions) somehow.

[barbeau]

From further discussion with MBTA, there is agreement that this is an error and should be flagged as such in the validator.

[barbeau]

In discussions with Metro Transit (Minneapolis), there are cases where one vehicle will serve one half of the trip and then be pulled out of service for an emergency maintenance issues, and another vehicle will take over the 2nd half of the trip. After discussions with two consumers, it seems that this is a valid use that that won't break anything.

We should clarify in the spec that this is allowed.

For the validator, we could flag this as a warning.