GTFS-RT trip updates compatibility

[mmathieum]

We would expect to receive trip updates for all trips you have scheduled that are realtime-capable.
There should be at most one trip update for each scheduled trip.

Links:

• https://gtfs.org/documentation/realtime/feed-entities/trip-updates/
• https://developers.google.com/transit/gtfs-realtime/examples/trip-updates-full

Static <> Real-time match:

• TripUpdate
  • trip ID ⏫
  • start data & time
  • route/direction ID (fall back when no trip ID) (not frequency based)
  • modified trip
    • affected trip ID
    • ...
  • schedule relationship
    • SCHEDULED == static data ⏫
    • ADDED (deprecated ≈DUPLICATED): known trip from static data added
    • UNSCHEDULED: brand new trip not related to static data #frequency
    • CANCELED🔼: removed -> remove from real-time schedule (or show as 00:00)
    • REPLACEMENT #experimental : trip that replaces an existing trip in the schedule
    • DUPLICATED: copy of static data except 1st stop time date&time
    • DELETED🔼: (≈CANCELED) but not shown to users in UI
    • NEW #experimental : extra trip unrelated to any existing trips

Support:

• TripUpdate delay ⏫ (in secs) #experimental (overridden by 1st stop matching StopTimeUpdate info)
• StopTimeUpdate
  • stop ID ⏫ (match with regex+hash)
  • stop sequence🔼 ⚠️ (currently not available locally, can extrapolate or would have to be added)
  • schedule relationship
    • SCHEDULED⏫ (default)
    • SKIPPED🔼: stop skipped > vehicle will not stop at this sto
    • NO_DATA:⏫ show static data
    • UNSCHEDULED: #frequency
  • arrival ⏫
    • delay ⏫ (in secs)
    • time ⏫ (in secs)
    • uncertainty (in secs) (≈ precision) (window of error divided in 2 before/after: 15 min delay w/ 4 min uncertainty = 2 min
  • departure ⏫
    • delay ⏫ (in secs)
    • time ⏫ (in secs)
    • uncertainty (in secs) (≈ precision) (window of error divided in 2 before/after: 15 min delay w/ 4 min uncertainty = 2 min before/after)
  • StopTimeProperties
    • stop headsign
    • pick-up/drop-off type

Use case:

• if static data stop sequence not available (yet), generate "min stop sequence" while iterating over RT stop time update?
• positive delay (late) ⏫
• 0 delay (on time) ⏫
• negative delay (early) 🔼
• 1 StopTimeUpdate for the 1st stop only
• firsts stops with no info then multiple StopTimeUpdate then another one with NO_DATA schedule relationship
• arrival/departure (stop time event) with only delay ⏫
• arrival/departure (stop time event) with only time ⏫
• stop time update with only arrival ⏫
• stop time update with only departure ⏫
• re-using StopTimeUpdate from previous stop ⏫
  • compute reminder delay for next stop arrival
  • diff between arrival & departure can consume delay (if delay 5 min and diff 3 min -> remaining delay 2 min)
  • for negative delay (early), assuming driver waits at next stop? or will continue to be early until proven otherwise? P1 is that user don't miss the trip by being too late at the stop but also don't want to show negative countdown when vehicle hasn't actually passed because driver waits at previous stop... 🤔

Examples:

• https://gtfsrt.ttc.ca/trips/update?format=text
• curl -X GET 'https://nextrip-public-api.azure-api.net/octranspo/gtfs-rt-tp/beta/v1/TripUpdates?format=json' -H 'Ocp-Apim-Subscription-Key: <SUBSCRIPTION_KEY>'
• https://api.openmetrolinx.com/OpenDataAPI/api/V1/UP/Gtfs/Feed/TripUpdates?key=API_KEY_HERE
• https://api.openmetrolinx.com/OpenDataAPI/api/V1/Gtfs/Feed/TripUpdates?key=API_KEY_HERE

Similar to:

• Real-time🛰️ vehicle locations/positions 🚌  mtransit-for-android#80