Fair enough, if that’s the fastest possible journey between . And it must be, because it says it’s the fastest with all possible transport modes were enabled.
Except that it isn’t.
Let’s plan the exact same journey but enabling only London Overground and Elizabeth Line modes,
Result: a 52 minute journey involving only two trains:
So, in what way is the 55 minute journey faster than the simpler 52 minute journey?
Presumably it’s because the API hasn’t taken into account that there’s a fair bit of walking between London Overground and Liz Line at Liverpool Street.
But … why include it in the calculation that determines the fastest route, and then ignore it when it’s displayed?
There is no issue here as this is the fastest journey at the time you have planned.
The journey you have planned is for departing at 11am, JP is designed to give you a journey that is sometimes slightly earlier in this case at 1057 or the bus as this is the nearest departure to the time selected, if you then select later journeys more options are shown, including journeys at 1107 and 1108 that are both 52 minutes.
@MScanlon
I wonder how many users understand that JP is trying to be that clever? Arguably people aren’t that being that precise when they specify a start time. IIRC JP actually encourages you to select a quarter-hour.
Harry’s sample journey would not come out as fastest of the 397 ran every 12 rather than 20 minutes as JP would (by design, it seems) add 12 minutes to the expected journey time on the bus. Again, not many JP users will understand that subtlety (which does not apply to tube journeys). For a journey involving several high frequency bus route stages, you’ll get such a high expected journey time that you’ll probably give up and stay on the sofa.
A thought sparked off by this is that often what people value more is reliability rather than actual speed. If the tube goes wrong it really goes wrong but most of the time journey times are pretty reliable. Buses, at least in some parts of London, are much less predictable and a journey that is supposed to take 20 minutes could take 15 (if the driver is trying to make up time) or 40 (if the traffic is, to use a technical expression, screwed). Also the number of changes between modes (other than walking) increases unreliability. The user can control selections by filtering on mode or number of connections; other than that I have no idea how you could build that sort of thing into JP without confusing users further!
@Leo
I have to guess that you are responding to my first message on this thread not the second, which I hope cleared your seriousness bar. That was essentially about the mismatches in understanding that can occur between the innovators and the users, I would also suggest that if the only discussions are serious and logical ones between the innovators that increases the chance of such mismatches occurring.
One point that I could have mentioned was that the way people use a facility can change rapidly. I would imagine that smartphone apps have greatly reduced the proportion of JP requests where people are looking for the time of the next bus as of now, for example.
Personally I think forums benefit from people sometimes dropping their serious face occasionally but maybe I am in a minority of one.
Your explanation might make sense if the heading at the top was better constrained, eg “Fastest Journey starting between 10:55 and 11:10”. It might also make some sense if it said “Arriving soonest”. But it says categorically that it’s the Fastest Journey which to most people implies that a journey a few minutes earlier of later would always take longer
Anyway, to demolish that argument completely, I’m continuing to see examples where Elizabeth Line is being ignored in favour of slower routes.
To take an obvious example: try planning Liverpool Street to Paddington at 3pm today:
with all modes selected, journeys of 25, 25, 26, 25, 25 and 25 minutes are shown and 25 minutes is stated to be the fastest, with no Eliz line journeys included at all
replanning with identical settings but only Elizabeth line selected, journeys of 21,21,21,21,21 and 21 minutes are returned
I checked, and the Eliz journeys have included extra time for getting from “Liverpool Street” to the Liz platform, and extra time at Paddington too. So, the Liz line is genuinely faster at all times within the next half hour. Yet it’s still not shown as the fastest journey, nor indeed are any of the faster Liz line journeys shown at any time during the next half hour.
I’ve attempted to recreate your journeys and only get the Elizabeth line returned first and at 21 minutes journey.
With regards to Fastest Journey v Arriving Soonest, a customers journey would start when they leave the arrival point for example their home or station and a slightly longer train journey would still be faster if it departs first and arrives before the shorter train journey. As if for example you left at 3pm and there was a train at 3pm which is 4 minutes slower than a train at 3:04 it would still arrive at your destination before the Faster train so would be classified as a faster journey.
As I’ve just written a TfL/NRE/Google journey planner plugin into our (“award winning”) webapp, I can see these results for the trip you’ve asked for (11am next day) all of which come though as 50 minuets
The parameters I’m using are 910GCHINGFD/to/940GZZLUCYF?date=20220714&time=1100&timeIs=departing&journeyPreference=leasttime&mode=overground%2Ctube%2Ccoach%2Cdlr%2Ctram%2Celizabeth-line%2Cnational-rail%2Criver-bus&accessibilityPreference=&walkingSpeed=average
I’m also getting Elizabeth Line journeys returned when planning an All Modes journey for 3pm this afternoon. But that wasn’t the case on 7th July when I posted that report. I tried it several times to verify before posting the report.
Could it be that somebody else has reported a problem and it has been fixed?
