Determine Sydney Train Delay Information

2

I’m in the process of writing some detailed docs so I don’t forget all the little quirks in the system. Here’s an edited extract, with some examples.

For scheduled services

Services running as scheduled (that is, there are no transpositions causing changes to the stopping pattern) have a trip schedule_relationship of SCHEDULED:

entity {
  id: "92AE.1487.104.124.K.4.44060407"
  trip_update {
    trip {
      trip_id: "92AE.1487.104.124.K.4.44060407"
      schedule_relationship: SCHEDULED
      route_id: "CUL_1b"
    }[...]

For these trips, only a delay field is provided. You should obtain the scheduled arrival time and departure time from stop_times.txt (in the GTFS-static for realtime dataset) and add the delay seconds. Negative value denotes the vehicle is expected to arrive or depart ahead of schedule:

entity {
  id: "92AE.1487.104.124.K.4.44060407"
  trip_update {
    trip {
      trip_id: "92AE.1487.104.124.K.4.44060407"
      schedule_relationship: SCHEDULED
      route_id: "CUL_1b"
    }
    stop_time_update {
      arrival {
        delay: 45
      }
      departure {
        delay: 45
      }
      stop_id: "2560702"
      schedule_relationship: SCHEDULED
    }[...]
    timestamp: 1484886561
  }
}

Match each stop_time_update by the stop_id provided in the realtime and static feeds.

For replacement services

A replacement service is where the trip is an additional service or has had its scheduled stopping pattern altered. These trips have a trip schedule_relationship of REPLACEMENT.

REPLACEMENT for scheduled services are intended to slot-in and replace all or a section of an existing service. They include a timestamp for arrival and departure. delay is also provided for stops which were already part of the schedule (in stop_times.txt) and have not been skipped, added or replaced.

entity {
  id: "W557.1487.104.64.V.4.44060591"
  trip_update {
    trip {
      trip_id: "W557.1487.104.64.V.4.44060591"
      schedule_relationship: REPLACEMENT
      route_id: "BML_1"
    }
    stop_time_update {
      arrival {
        time: 1484886212 // <-- no delay provided, this stop is either added, or replaces another stop
      }
      departure {
        time: 1484886305
      }
      stop_id: "2148536"
    }
    stop_time_update {
      arrival {
        delay: 163 // <-- delay provided, this stop is listed in the existing schedule
        time: 1484887076
      }
      departure {
        delay: 133
        time: 1484887106
      }
      stop_id: "2750513"
    }

Replacement and additional stops are not denoted in any way in the stop_time_update entity. You must back check with the static schedule to determine which stops have been added or replaced.

(Replaced stops are platform changes. They can be linked using the stop’s parent_station field, except in some City Circle services which stop at Central twice.)

Stops which are skipped without replacement (e.g. a Bondi Junction to Waterfall service commencing at Central) will have its first stops (Bondi Junction to Town Hall) appear as SKIPPED (under stop_time_update > schedule_relationship).

Upon completion of the section of stops with added stops, replacement stops or skipped stops, the trip_update may resume reporting a SCHEDULED relationship.

4 Likes