Gtfs-realtime.proto delay value for sydney trains running a head of schedule

1

Hi Guys,

we are building an mobile application which shows the real time sydney trains time table. we are getting real time updates using https://api.transport.nsw.gov.au/v1/gtfs/realtime/sydneytrains

gtfs-realtime.proto
late running trains are showing value of delay in positive integer.
how to get the early arrival from the api for the train running a head of schedule.

1 Like
2

It’s shown as a negative integer. See the example below – it means that trip W595 is expected to depart 91 seconds earlier than scheduled from stop 278652:

entity {
  id: "W595.812.113.8.V.4.54194577"
  trip_update {
    trip {
      trip_id: "W595.812.113.8.V.4.54194577"
      schedule_relationship: SCHEDULED
      route_id: "BMT_1"
    }
    stop_time_update {
      arrival {
        delay: 0
      }
      departure {
        delay: -91
      }
      stop_id: "278652"
      schedule_relationship: SCHEDULED
    }
    timestamp: 1537285889
  }
}
3

Thanks @jxeeno :slight_smile:

But we need to display arrival time in our application instead of departure. Does delay inside arrival will come with negative integer. because we have developed based on this condition but this is not working.

our application value of stop_time_update is coming in array

[ stop_time_update {
arrival {
delay: -91
},
departure {
delay: -91
}
]

4

Yes, it’s the same for arrivals and departures – as per the GTFS-realtime specification. :slight_smile: Example below:

entity {
  id: "55AF.812.114.124.M.4.52955116"
  trip_update {
    trip {
      trip_id: "55AF.812.114.124.M.4.52955116"
      schedule_relationship: SCHEDULED
      route_id: "CMB_2a"
    }
    stop_time_update {
      arrival {
        delay: -7
      }
      departure {
        delay: -37
      }
      stop_id: "2147424"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      arrival {
        delay: 0
      }
      departure {
        delay: 0
      }
      stop_id: "2148532"
      schedule_relationship: SCHEDULED
    }

That’s right. If you check the proto “spec” you’re using to decode the buffers, you can see that stop_time_update is a repeated field. In most languages and protobuf libraries, repeated entities in protocol buffers are translated into arrays or equivalents. There should be an array of stop_time_updates, one representing each future stop in train is expected to stop at.

5

Thanks @jxeeno:

We have implemented this way in our appllication. This is working fine for late arrivals but for early arrivals this seems to be not working. As we dont have scenario to reproduce this early trains we find it to hard to fix this issue.

Do you aware of any station/ platform where we could get early trains in the timetable. Fixing the issue without getting the proper scenario is very hard for us.

6

Perhaps you can write a bit of code that puts in some dummy negative numbers for arrival to see how your app reacts?

You could also write a bit of code that reads the protobufs and finds trips with negative arrival delays? Early arrivals (by a few seconds) do occasionally appear in the feed (as per examples above) – you just need to find them.

7

@jxeeno:

I have read the gtfs documentation. As per the information provided it seems that sometimes delay field may come as null and instead of that field we may get time field in stop_time_update. Do you have any idea on this?

Fields
Field Name
Type
Required
Cardinality

Description

delay int32 Conditionally required One Delay (in seconds) can be positive (meaning that the vehicle is late) or negative (meaning that the vehicle is ahead of schedule). Delay of 0 means that the vehicle is exactly on time. Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty.
time int64 Conditionally required One Event as absolute time. In POSIX time (i.e., number of seconds since January 1st 1970 00:00:00 UTC). Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty.
uncertainty int32 Optional One If uncertainty is omitted, it is interpreted as unknown. To specify a completely certain prediction, set its uncertainty to 0.

8

That’s right. The spec requires either a delay or time field to be provided. You might find my explainer on when the feed might report one or another useful: Determine Sydney Train Delay Information - #2 by jxeeno

9

I think Katie Bell referred to inconsistencies in realtime TfNSW GTFS in her video presentation at

http://lca2018.linux.org.au/schedule/presentation/83/

This was for buses for her “Bus Shaming” site

but I think the issues might be similar for trains

I see the problem you refer to when looking at your web-site, something I view very regularly. There seems to be a lot of jumping around when things are out of whack.

Geoff Lambert