TFL thinks 52 > 55 ...?

Unified API
#1

Let’s plan a journey:

image

The result: a complicated 55 minute journey involving a bus and two trains:

2022-06-07 17_05_41-Journey results - Transport for London — Mozilla Firefox
2022-06-07 17_05_41-Journey results - Transport for London — Mozilla Firefox395×596 19.7 KB

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:

image
image390×516 15.1 KB

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?

#2

Programmed by Dianne Abbott, perhaps?

#3

Hi Harry,

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.

1 Like
#4

@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!

#5

Not funny !! , logical and innovative discussions are appreciated better on this forum. :roll_eyes:

#6

@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.