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

[barbeau]

Issue by barbeau Wednesday Nov 30, 2016 at 18:54 GMT Originally opened as https://github.com/CUTR-at-USF/gtfs-realtime-validator/issues/38

---

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]

Comment by barbeau Thursday Jul 06, 2017 at 21:34 GMT

---

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]

Comment by barbeau Monday Jul 10, 2017 at 15:16 GMT

---

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]

Comment by barbeau Monday Jul 10, 2017 at 18:15 GMT

---

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

[barbeau]

Comment by barbeau Monday Feb 17, 2020 at 14:27 GMT

---

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.