NARRATIVE: GTFS-RT Trip Events and OTP and MOD Map and Canceled Trips (partially and fully)

Would like to eventually have a discussion on how gtfs-rt trip events will affect the MOD Map and Itinerary. For reference, there's an instance of OTP pulling in TriMet's gtfs-rt here: http://maps7.trimet.org/ui_test/

Below are notes regarding TriMet's gtfs-rt feed. I am writing this because we (TriMet) and the developers of OTP's gtfs-rt need to sync up on what events to publish, and document data/event assumptions.

1) Currently, TriMet's gtfs-rt (https://trimet.org/ws/int/v1/tripUpdate/text/true) does not publish any "ScheduledRelationship->TripDescriptor" (https://developers.google.com/transit/gtfs-realtime/reference/ScheduleRelationship-td) info...so right now, there are no "CANCELED" trip events coming thru. (From the spec: "CANCELLED - A trip that existed in the schedule but was removed." at the trip level expressed."). However, CANCELLED trip events will be published in TriMet's gtfs-rt in the coming year, once an upgraded Alerts system is deployed.

2) that said, today we publish "partially cancelled trip" events as the following (you'll occasionally see this pattern in https://trimet.org/ws/int/v1/tripUpdate/text/true):

trip_update {
    stop_time_update {
      stop_sequence: 87
      schedule_relationship: SKIPPED
    }
    stop_time_update {
      stop_sequence: 88
      schedule_relationship: SKIPPED
    }
    stop_time_update {
      stop_sequence: 89
      schedule_relationship: SKIPPED
    }
    stop_time_update {
      stop_sequence: 90
      schedule_relationship: SKIPPED
    }

2b) Orthogonal question: is there any value in having the MOD Map observe the SKIPPED stop flag, and trying to narrate to the customer such service disruptions affecting part of a route (e.g., detours, broken-down vehicles, police actions, etc...)? Note that textural alerts often describe major events (like police actions), and are part of the gtfs-rt alerts feed.

2c) there's work at both ends needed for SKIPPED, I believe, as I am not sure that OTP's gtfs-rt implementation currently observes the SKIPPED flags that TriMet publishes. In August 2017, I found some SKIPPED trip/stop events, and asked OTP to plan a trip on that trip and those stops. Unfortunately, OTP returned an itinerary that used stops as written in the schedule, but that should have been SKIPPED per gtfs-rt.

2d) Here are my notes from that SKIPPED event back in August:

skipped not skipping in otp

3) Item 2 brings up larger points of how to narrate cancelled trips that makes sense for customers. For example, if one day I can't plan a trip from my stop at a time I know the bus passes, and I'm given no reason why (e.g., "trip is cancelled ... take the next bus" or "this scheduled arrival at stop X is show as being skipped at X:YY pm"), I'd probably assume 'broken trip planner'.

4) Further, how do we communicate a long-term "cancelled route" to the customer. Firstly, the data will be a series of trip CANCELLED events in gtfs-rt. (Note: if operations does cancel a route for any length of time, have to confirm that TriMet will publish a whole slue of CANCELLED events at once, and that OTP is okay accepting all those events).

5) Need some clarity on how TriMet is publishing gtfs-rt, and whether delays published for trip A are supposed to be applied to following trip B / C / D that have the same BLOCK ID, etc... (Colleague Guy mentioned something about this, and need to follow up with him for clarity).

ibi-group / trimet-mod-otp

NARRATIVE: GTFS-RT Trip Events and OTP and MOD Map and Canceled Trips (partially and fully) #38