Using the example journey of Gadigal Metro to Gordon Station, I’ve recently seen examples of the trip API quite correctly returning a journey that’s actually from Town Hall to Gordon (because it will get to Gordon more quickly), but NOT returning leg 0 of the journey as a walking leg (class 99).
The returned JSON has leg 0 literally starting at Town Hall station. And as the API doesn’t seem to allow you to disable walking as an option, it makes it potentially challenging for a user to understand what’s happening.
Obviously I can use exclMOT_1=True to force a start from Gadigal in this scenario, but I think this is a change to the API returned dataset itself. Is this expected behaviour?
The official Trip Planner site shows the same behaviour (ie Town Hall as the origin) but it also shows that a walk is required, and the actual directions, so IT is getting the right info.
Be aware that there’s also an issue with the results relating to the departure times. In the API call I’ve specified a time 10 minutes into the future, using (for example) depArrMacro=dep&itdDate=20260203&itdTime=1546 which was called at 15:36.
The problem is that I’m getting journeys whose departure time is earlier than 1546 (taken from the JSON return): departure_time = 2026-02-03T04:43:36Z departure_time (local) = 2026-02-03 15:43:36+11:00
From my testing I believe that the missing walking distance is a factor somehow - the maximum ‘wait time’ I’ve seen with a ten-minute in-the-future API request is 5 minutes, and 5 minutes just happens to be the walking time between Gadigal and Town Hall. I don’t know, maybe that’s a coincidence…
Unfortunately not - the doco talks about the presence of walking legs as expected, but there’s no option to specifically weight walking as ‘bad’ it seems.
I’m interstate at the moment - when I get some time I’ll generate a trip using a lat/long as the origin that’s a reasonable distance from a train stop or a bus stop and see if the first leg is a walk (as it should be) or assumes that we’re already at the ultimate origin:
Hi Andy, @Marcie has called me here to help Can you please send me the trip plan request you are using so I can get a better understanding of what’s going on.
Regarding the departure times prior to the specified departure time, the trip planner does have logic which in certain circumstances will give you options which it believes are good options even if it does not comply with the constraints you have specified. This is just in case it is useful to you or your user.
Hi Vic - sorry about the delay, I’ve had a lot on!
Thanks for the update re the planner offering options that don’t comply, that’s interesting. Here’s a specific example, although something has definitely changed recently as my testing wasn’t getting a ‘walking’ leg[0], but it is now.
Anyway - here’s an example of a URL calling the API. Trip from Gadigal to Gordon, wanting departures that are 15 minutes or more from now (based on the time that the API was called today):
I’ve attached the full raw output, but here’s the TL;DR:
First leg is a walk, the departure time is way before the requested earliest departure time but that’s OK, maybe it’s factoring in walking time?
Second leg is Town Hall, the estimated departure time is 1230 which is before the requested earliest departure time. Only two minutes, to be fair, but I’ve seen it as much as five minutes earlier - would this be expected to fall within the ‘outside of constraints’?
So I think you’ve fixed the main issue (leg[0] wasn’t a walking leg, it was the post-walk origin leg), so we’ve now got the lower-impacting scenario where (only for walking legs, it seems) the origin is earlier than that requested.
While I accept that offering an alternative origin via a walk is valid, starting journeys that are before the explicitly-request time is probably less so? Also, there’s no way in the API, that I can tell, to explicitly exclude walking legs… is that the case?
Can you please send me the trip plan request you are using so I can get a better understanding of what’s going on.