Anyone using GTFS-rt trip.schedule_relationship=ADDED?

[barbeau]

Is anyone currently using the GTFS-rt TripDescriptor.ScheduleRelationship = ADDED value?

It's defined here:
https://github.com/google/transit/blob/master/gtfs-realtime/spec/en/reference.md#enum-schedulerelationship-1

...as:

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.

And text above that says:

If a trip is done in accordance with temporary schedule, not reflected in GTFS, then it shouldn't be marked as SCHEDULED, but marked as ADDED.

Also posted to Google Group at https://groups.google.com/forum/#!topic/gtfs-realtime/W6bm2Xj3p-Q.

[gcamp]

We don't support it right in Transit, but we plan to do so. The folks at @mbta uses it

[dmaltzan]

At the MBTA we use the ADDED value for certain trips our subway routes. We primarily use it because the underlying data we get from our signaling system on some subway lines does not contain any way of matching up live trips to scheduled trips. On other lines, we do have schedule data, but there's no real guarantee that it'll match up with our GTFS schedule because it comes from a system that does not reflect shuttle-bus diversions etc. (whereas that information is put into our GTFS file).

Because of this, we use our own algorithm to search for a GTFS trip_id that matches up with each subway trip as soon as we need to make predictions for it. Currently we look for a trip that starts within plus or minus ten minutes of the time that we're predicting this trip will start, and has the same pattern of service. If no GTFS trip exists matching those criteria (or if one exists but has already been used) then we will create an ADDED trip.

In particular, this means that certain patterns of service will never match up with a GTFS trip. For example, we run some Green Line trips from Kenmore to Park Street on a "run as directed" basis during Red Sox games, but these are not scheduled so they will never match and will always show up as an ADDED trip.

Hope this helps.

[minhhpham]

We performed an analysis using transit-feed-quality-calculator and found 4 agencies that have trip.schedule_relationship=ADDED:

Feed	Location
OVapi Train Trip Updates	The Netherlands
OVapi Vehicle Positions	The Netherlands
YRTViva Trip Updates	York, Toronto, ON, Canada
YRTViva Vehicle Positions	York, Toronto, ON, Canada
MetroTransit Trip Updates	Halifax, NS, Canada
MetroTransit Vehicle Positions	Halifax, NS, Canada
MBTA Trip Updates	Boston, MA, USA
MBTA Vehicle Positions	Boston, MA, USA

Here are the feeds that have trip.schedule_relationship=ADDED: https://gist.github.com/minhhpham/6d792f1a33eb8fc8db472b4bb3d91921

[barbeau]

Thanks everyone for your responses. I'm closing this issue, but have referenced it in the issue on the larger debate of how we provide full support for added trips going forward - #113 (comment).

[barbeau]

@skinkie Do you currently have an implementation of ADDED trips?

From your recent comments (#216, #221) it sounds like you do. We're trying to collect existing implementations of ADDED trips in this issue, given that ADDED trips are not well-described in the current GTFS-RT spec.

If you do have an implementation, could you please provide a detailed explanation of exactly how you're using ADDED in your feeds as a producer and/or consumer?

[skinkie]

I'll check it from our sourcecode later but these are our three use cases.

1. reinforcement trips for bus, tram and metro (very very few, operators do not implement it)
2. cancelled and then added trips for trains (very often, effectively the default, changes "trip_id")
3. added as completly new trip, with a different pattern (regular)

[hbruch]

MFDZ works on using GTFS-RT ADDED trip updates to feed carpool offers to OTP. OTP itself currently handles ADDED trips. In case the route_id is not yet existent, it creates a new route, assuming a bus route_type.

We'd prefer an explicit route_type in GTFS-RT.

Other restrictions we currently work around is that GTFS-RT does not define additional stops, nor schedule, nor shapes.

[nathan-reynolds]

At Trapeze we support the "ADDED" value in the GTFS-RT feed whenever the control center 'copies' a piece of work. This is mostly for use cases 1 & 2 that @skinkie mentioned for reinforcement trips or trips that are cancelled and then copied for other vehicles.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[skinkie]

@barbeau can be closed?

[barbeau]

Yes, I think we can close this. If anyone is still using ADDED please feel free to comment on this thread, but note that in PR #230 we agreed that ADDED is currently underspecified and as a result isn't officially supported in the spec. ("behavior is unspecified for feeds that use this mode").

[miklcct]

MFDZ works on using GTFS-RT ADDED trip updates to feed carpool offers to OTP. OTP itself currently handles ADDED trips. In case the route_id is not yet existent, it creates a new route, assuming a bus route_type.

We'd prefer an explicit route_type in GTFS-RT.

Other restrictions we currently work around is that GTFS-RT does not define additional stops, nor schedule, nor shapes.

I have just submitted a proposal #490 which can define a schedule for ADDED (and DUPLICATED) trips. However, headsigns remain a limitation that we can't implement yet.

[2martens]

In our situation we have regularly additional journeys that are not represented in the schedule data. It appears that currently that cannot be modelled with GTFS-RT correctly, right?

[miklcct]

In our situation we have regularly additional journeys that are not represented in the schedule data. It appears that currently that cannot be modelled with GTFS-RT correctly, right?

OpenTripPlanner uses schedule_relationship=ADDED for this purpose, however, it is not possible to specify some information such as trip_short_name, trip_headsign, etc. The trip_id must not exist in the GTFS in such situation.

It also supports scheduled_relationship=REPLACEMENT which is equivalent to deleting the trip with the specified trip_id for the specified departure date, and add it back with the replaced trip using the same trip_id for the particular date. It can be used to specify diverted services.