Hi - I’ve started working with your API and it’s really easy to get useful data. I have got an odd query though:
I was initially using /departure_mon, finding an appropriate train journey and then using RealtimeTripId to get the lat/long via Real Time Vehicle Positions API. So far, so good but it was hard to filter down to a specific journey or destination.
I then started to explore the data returned in the /trip API, as that’s exactly what I was after. Again, all good except that, for the same journey, /trip returns a different RealtimeTripID to /departure_mon. Here’s an extract for what is 100% the same trip…
Extract from /departure_mon:
"properties": {
"WheelchairAccess": "true",
"RealtimeTripId": "146T.1287.126.32.A.8.61673356",
"AVMSTripID": "146T.1287.126.32.A.8.61673356",
"PlanLowFloorVehicle": "1",
"PlanWheelChairAccess": "1"
}
Extract from /trip:
"properties": {
"isTTB": true,
"tripCode": 799,
"RealtimeTripId": "146T.1287.126.16.A.8.61673356",
}
You’ll see that the 4th part of the trip ID is different - 16 or 32. From some testing that seems to be consistent (in that it’s only the 4th segment that changes), and the Real Time Vehicle Positions API only works for the /departure_mon variant.
If this IS 100% consistent then I can break down and rebuild the trip ID as necessary using a wildcard search against the output of the Real Time Vehicle Positions API, but this doesn’t seem right? What’s a better way of getting the outcome I’m after?
Example:
“RealtimeTripId”: “146T.1287.126.*.A.8.61673356”
Thanks in advance,
Andy
Hi @andy.stewart. The numbers 1287.126.16 and 1287.126.32 are two different calendars. One is Wednesday and on is Thursday according to the latest Sydney Trains GTFS bundle.
Are you performing the /departure mon and /trip queries with the same date?
Ah, powers of 2 for the date. That explains a few things.
Re being the same date, totally! Check this out, I ran them literally just now…
Query - /departure_mon:
curl -X GET --header ‘Accept: application/json’ --header 'Authorization: apikey xxx ‘https://api.transport.nsw.gov.au/v1/tp/ departure_mon ?outputFormat=rapidJSON&coordOutputFormat=EPSG%3A4326&mode=direct&type_dm=stop&name_dm=10101121&itdDate= 20200612 &itdTime= 1400 &departureMonitorMacro=true&excludedMeans=checkbox&exclMOT_4=1&exclMOT_5=1&exclMOT_7=1&exclMOT_9=1&exclMOT_11=1&TfNSWDM=true&version=10.2.1.42’
Result - note that there was NO RealtimeTripID property so I’ve reverted to using AVMSTripId which always seems to be the same anyway:
“AVMSTripID”: “104H.1287.126.64.T.8.61671627”
And now for /trip:
curl -X GET --header ‘Accept: application/json’ --header ‘Authorization: apikey xxx’ ‘https://api.transport.nsw.gov.au/v1/tp/ trip ?outputFormat=rapidJSON&coordOutputFormat=EPSG%3A4326&depArrMacro=dep&itdDate= 20200612 &itdTime= 1400 &type_origin=any&name_origin=10101121&type_destination=any&name_destination=10101122&calcNumberOfTrips=1&excludedMeans=checkbox&exclMOT_4=1&exclMOT_5=1&exclMOT_7=1&exclMOT_9=1&exclMOT_11=1&TfNSWTR=true&version=10.2.1.42’
Result:
“RealtimeTripId”: “104H.1287.126.32.T.8.61671627”
DepartureTimePlanned is the same for both, date AND time, so it’s definitely the same trip.
My original query was based on API calls that I ran last night. I wonder if there’s a bug in the date translation for /trip that means its always a day behind, which would explain why the actual trip isn’t able to be queried for.
Let me just run another /trip query, for yesterday:
Query:
curl -X GET --header ‘Accept: application/json’ --header ‘Authorization: apikey xxx’ ‘https://api.transport.nsw.gov.au/v1/tp/trip?outputFormat=rapidJSON&coordOutputFormat=EPSG%3A4326&depArrMacro=dep&itdDate=**20200611**&itdTime=1400&type_origin=any&name_origin=10101121&type_destination=any&name_destination=10101122&calcNumberOfTrips=1&excludedMeans=checkbox&exclMOT_4=1&exclMOT_5=1&exclMOT_7=1&exclMOT_9=1&exclMOT_11=1&TfNSWTR=true&version=10.2.1.42’
Result:
“RealtimeTripId”: “104H.1287.126.32.T.8.61671627”
It’s the same! How can that be if it’s supposed to be yesterday’s trip unless the API clips the date as today at the earliest, that would make sense as people don’t tend to query historical trips.
I’ve done a load more testing, check this out…
Using server-provided values (so 20200612, and around 1400)
/trip
“departureTimePlanned”: “2020-06-12T04:16:00Z”
“RealtimeTripId”: “138M.1287.126.32.A.8.61672274”
/departure_mon
“departureTimePlanned”: “2020-06-12T04:16:00Z”
“AVMSTripID”: “138M.1287.126.64.A.8.61672274”
Note 32 and 64, so Friday and either Saturday or Thursday - I assume Saturday if we’re going Mon, Tue, Wed etc
Trying next week, the 16th at 1000
/trip
“departureTimePlanned”: “2020-06-16T00:00:00Z”
“RealtimeTripId”: “172F.1287.126.32.T.8.61673720”
/departure_mon
“departureTimePlanned”: “2020-06-16T00:00:00Z”
No trip IDs for /depature_mon, I guess it’s too far in the future. But note that /trip is still returning 32 as the day modifier, that can’t be right – it’s supposed to be for Tuesday!
Trying next week, the 15th at 1000
/trip
“departureTimePlanned”: “2020-06-15T00:00:00Z”
“RealtimeTripId”: “172F.1287.126.32.T.8.61673720”
/departure_mon
“departureTimePlanned”: “2020-06-15T00:00:00Z”
“RealtimeTripId”: “172F.1287.126.64.T.8.61673720”
Looking at that, the 32 and 64 CAN’T be representing a date. /trip seems to return 32 in most situations, 64 just the once.
Last test for now as I’ve actually got work to do 
So in case there’s a problem with the Gordon to Pymble route (my testing so far), I tried Central to Town Hall. Date and time blank for both so the server will provide those:
/trip
“departureTimePlanned”: “2020-06-12T04:49:00Z”
“RealtimeTripId”: “605G.1287.126.48.T.8.61670290”
/departure_mon
“departureTimePlanned”: “2020-06-12T04:49:00Z”
“RealtimeTripId”: “605G.1287.126.64.T.8.61670290”
So, 48 isn’t a power of two so unless there are some other modifiers it doesn’t represent a date. Hmm, maybe it represents two dates (16+32). Regardless, there’s still a difference in the RealtimeTripId which is vexing, but as it’s super-consistent and I’m confident that both journeys are the same, I can at least work around the issue by confirming the rest of the string.
Thanks for all the info @andy.stewart! I have raised this with the team internally and will get back to you on a response!
1 Like
@andy.stewart, there was indeed an issue with the trip ID not being consistent between departure and trip-request API. A fix was deployed today. Could you try again and advise if you are still experiencing the same issue?
Looks like it’s working! Thanks for that.
Is there a public definition available re how the ID is made up? I’m just curious.
Great to hear it’s working! You can view more information on Trip IDs in our real-time technical documentation: https://opendata.transport.nsw.gov.au/sites/default/files/Realtime_Trains_technical_documentation_v2.8.pdf