Hi - I’ve noticed for some bus routes and train journeys that sometimes the Trip Planner API returns a journey with a RealtimeTripId, but that the associated GTFS source doesn’t have an associated entry.
I’ve seen it for regional buses and Sydney trains. I’m aware that there are multiple regional buses URLs and that the Sydney trains GTFS feed is on v2, but still there are times when this happens.
Is this expected? I understand that some journeys might not have real time positioning for whatever reason, but if that’s the case I’d expect the journey API to not include a RealtimeTripId value…
A little info addition - I’m also seeing a scenario where a bus making its way to the first stop of its route is sending location info, and then as soon as it gets to the first stop the tracking stops… although the RealtimeTripId remains…
Hi - now that I understand a bit more about routes, trips and whatnot I believe I understand what’s happening.
Let’s assume that there’s a route from Hornsby to Central and there’s a train on it right now with a RealtimeTripId of 100A.B.C.etc. When the train gets to Central and then starts going to, say, Gordon it might be on a different route and it will definitely have a different RealtimeTripId (let’s say the new RealtimeTripId is 321X.Y.Z)
If I ask the API about a trip from Central to Gordon in 10 minutes or so it will give me all the details about the trip including the RealtimeTripId of 321X.Y.Z because that’s what it WILL be when the trip starts, but the GTFS feed doesn’t contain any information for 321X.Y.Z because it hasn’t actually started yet!
So here’s my question: is it possible for the /trip API to also return the currentRealtimeTripId of the actual physical train set that will ultimately be servicing the trip that I’m interested in? Or, is it possible for me to determine this information in a consistent way that works for ALL transport types, given that Trains, Buses and Ferries all have quite different RealtimeTripId formats.
Second question: I’m seeing a new value type being returned, gtfsTripId (eg,3001.nsw-2-T1-N.1.TA.1839.sj2) but I can’t see how that relates to anything in either of the GTFS feeds that I’m aware of (/gtfs/realtime/ and /gtfs/vehiclepos/).
thanks for your correspondence - will try and answer to the best of my ability!
For those realtime trip Ids with no corresponding GTFS data, they might be schedule_relationship: ADDED trips. This occurs time to time and details can be viewed here.
The missing realtime on the first stop is a known issue that Transport has been trying to resolve for a while. Driver behaviour plays a part, while also the ending of one trip and beginning of the next creates a few issues. Transport are commencing a big project to overhaul bus realtime feeds - watch this space!
For your question on trains trip ids have you had a look at the sydney trains spec, here?
gtfsTripId (eg,3001.nsw-2-T1-N.1.TA.1839.sj2) is a code generated by internal scheduling system used by the .info Trip Planner. It is not intended to be used by downstream systems. could you show a screenshot of the whole entity?
Thanks for the two links Marcela - and yes, I’m aware of them and (for train trip IDs at least) I’m aware of the data that’s embedded in them but I can’t really use that to consistently guess what the previous trip ID was in order to see if I can determine where the train is right now. All good.
Re gtfsTripId I noticed it appear in the API output a couple of months ago I think, I’m pretty sure it didn’t used to be. I’ve attached some example output for you, but below is the property itself in context with its peers, found under journeys[0].legs[0].transportation.properties.gtfsTripId:
