Real time trip update missing schedule_relationship field

Real-time Public Transport
1

Apologies if this has been discussed in a different topic.

I am seeing inconsistencies with the trip update returned from https://api.transport.nsw.gov.au/v1/gtfs/realtime/sydneytrains

According to the RTTA Technical Documentation v2.2 on page 14, there should always be a schedule_relationship field:
entity->trip_update->trip->schedule_relationship

However, I have seen this structure change when there are large delays. Here is an example of a trip, retrieved on 28/01/2019 at 08:28:

API Return Extract

trip_update {
trip {
trip_id: “93-A.1260.122.36.A.8.55187054”
route_id: “IWL_2d”
}
stop_time_update {
arrival {
time: 1548273660
}
departure {
time: 1548273720
}
stop_id: “217935”
}

…

stop_time_update {
arrival {
delay: 816
time: 1548279246
}
departure {
delay: 786
time: 1548279276
}
stop_id: “2000337”
}
timestamp: 1548277976
}

I believe the arrival and departure fields will switch from delay to time when it is a replacement service, but this was reported as a schedule service in previous calls to the API, then the schedule relationship disappeared.

So there are two concerns that I’d like to receive direction about:

  1. Scheduled services that have delays are being reported using time instead of delay
  2. Scheduled services do not have their schedule_relationship specified

Thanks very much!

2

Hey @jtr, are you using the proto file provided here? Sydney Trains feed uses the old REPLACEMENT schedule_relationship to denote trips with changed stopping patterns. Those usually have time instead of delay because the stops don’t necessarily match what’s in the schedule.

3

Thanks for your response.

I can now understand that the time field replaces the delay field for replacement services, but my next concern is that for some API calls, the schedule_relationship field is completely missing from entity->trip_update->trip.

I can change my process so that if the field is missing, assume it is a replacement… but from what I understand the documentation indicates that this field should always be present.

4

Hmm, I don’t think I’ve encountered scenarios where there is no schedule_relationship specified. Did you build the bindings from the .proto provided on the open data site? It could be that your bindings are missing the REPLACEMENT enum value and silently omitting the value since it doesn’t know how to decode the value?