Add duplicated trips in GTFS-realtime

[ghost]

Case: An added trip is created in a CAD/AVL system by duplicating an existing trip or block and then assigning a schedule offset (so the duplicated trip operates XX mins before or after the original trip)

Question: What is the best way to represent such added trips in GTFS-realtime?

Two possible approaches are (1) assigning a unique entity_id and unique trip_id to the duplicated trip or (2) assigning a unique entity_id with the same trip_id from the schedule but a different start_time than the scheduled trip.

Approach 2 seems better since then consumers would know which trip (and so its shape and stop_times) was duplicated, but 1) can two trips in the same GTFS-realtime feed have the same trip_id? 2) If yes, does this cause any issues for consumers?

Is there a better approach?

[skinkie]

@ritesh-warade-ibigroup the approach that you lay out might even depend on the case. The added trip that you describe is a reinforcement trip. For that I could imagine using 2 concurrently. But for really added or modified trips (different route) I would say that 1 is preferable.

[barbeau]

@ritesh-warade-ibigroup In short, there isn't an official way to duplicate trips in the current GTFS-RT spec. Google supports (2) with ADDED schedule_relationship, but we actually want to move away from this to a more robust solution (one reason being that others use ADDED differently).

Goining forward, the "right" way to duplicate a trip in GTFS-realtime is the new DUPLICATED schedule_relationship in ServiceChanges v3.1:
https://docs.google.com/document/d/1oPfQ6Xvui0g3xiy1pNiyu5cWFLhvrTVyvYsMVKGyGWM/edit#bookmark=id.46iq4ddo589j

I'm actually in the process of working on a new PR that's a subset of Service Changes, pulling out the fields to support DUPLICATED, so we could move this forward and deprecate ADDED for this reason. Is this something that you could use?

[skinkie]

@barbeau I hope we can still use ADDED for the other purpose :)

[barbeau]

@skinkie ADDED will be soft-deprecated in the .proto, meaning that you could still consume and produce it if you like for your own purposes. But no promises on a community consensus on what it actually means :).

[sunny-lirr]

Is the goal for ServiceChanges to not only represent near-term temporary conditions such as detours or rail replacement buses but also true real time operating conditions that require adding trips or skipping stops? The current ADDED field can also be used for real time extra trips or added stops that only affect the current instance of a trip.

As an LIRR example, when a train (A) is canceled ad-hoc (unplanned), the next train (B) will often add stops to handle the passengers of the first train. In both our internal systems and our forthcoming GTFS-RT release, the output will consist of marking both A and B as CANCELED and creating a copy of B with the added stops under a new trip ID as ADDED.

[barbeau]

Is the goal for ServiceChanges to not only represent near-term temporary conditions such as detours or rail replacement buses but also true real time operating conditions that require adding trips or skipping stops?

Yes, ServiceChanges can add entire new trips in real-time via a new Trip object. It mirrors the contents in trips.txt and, similarly, there is a new StopTime that mirrors stop_times.txt too.

There is a draft .proto here with the additions if you want to take a look:
MobilityData#47

...as well as draft Java bindings for prototyping here:
MobilityData/gtfs-realtime-bindings#58

As an LIRR example, when a train (A) is canceled ad-hoc (unplanned), the next train (B) will often add stops to handle the passengers of the first train. In both our internal systems and our forthcoming GTFS-RT release, the output will consist of marking both A and B as CANCELED and creating a copy of B with the added stops under a new trip ID as ADDED.

Yes, with the full ServiceChanges additions you'd mark A and B as CANCELED, and then add the new trip (which is similar to B but adds stops) as a completely new Trip entity, complete with StopTime entities that include all stops (including the "new" stops).

If it was a detour with new stops that aren't in static GTFS CSV files, you can add new Stop entities as well in the protobuf feed.

[paulswartz]

MBTA uses ADDED trips with the first pattern (new entity ID, new trip ID).

[ghost]

Thank you all!

@barbeau re:

I'm actually in the process of working on a new PR that's a subset of Service Changes, pulling out the fields to support DUPLICATED, so we could move this forward and deprecate ADDED for this reason. Is this something that you could use?

Yes, this is probably something that we can use. (Hopefully what you come up with is not super complicated)

[barbeau]

@ritesh-warade-ibigroup Not complicated at all - essentially you'd swap ADDED for DUPLICATED, identify the trip from CSV GTFS via TripDescriptor.trip_id, and specify the new service date and/or time to run in two new fields. I'll work on publishing the draft shortly.

[ghost]

@barbeau sounds good. can you post a link to the draft here when you publish?

[barbeau]

@ritesh-warade-ibigroup Will do.

[barbeau]

@ritesh-warade-ibigroup I've opened a PR for a proposal to support DUPLICATED trips at #221.

[barbeau]

The proposal supporting DUPLICATED trips at #221 was voted on and adopted as an experimental feature, so I'm going to close this out.