If you do the maths on this that gives you the 0.5 * train time interval. It’s basically the average of the sum of all the times from 0 to train time interval.
Is this a feature request for us? We do have interchange times between different areas of stations, e.g. the time required to get from the entrance to the concourse, the time to take the escalator to the platform, etc. So far we don’t have straightforward way to publish this data, but since it’s quite a common request, we are actively trying to find a way to make this available.
2 Likes
I believe my response to that would be hell yeah
I’m currently working on an enhanced planner and this data would be amazing to have. Also, if you let Google have it then they could incorporate in their popular planner.
.
1 Like
Hi Leon - is Pathfinder the name of the GraphDB (or) the project? Can’t see too many references to the Pathfinder DB
Pathfinder is our name for the specific graph database / project that we built internally, though we did use third-party technologies.
@LeonByford
The discussion of the travel times by different routeings brings me back to something I’ve always been puzzled by on the bus side.
If you wish to travel from A to B on a low frequency bus route, JP shows you the actual on-bus time as the travel time. If however it is high frequency route the headway on the route is added in, without it being made clear that this is happening.
There are a few consequences:
- if there are low and high frequency options (e g Enfield Town to Chase Farm Hospital - HF on W8, LF on 313 and W9) JP points you towards the LF service when the HF option would most likely be better (in this case it will send you to the wrong stop because the three services use different stops);;
- if you are making a multi-bus journey using HF services you may get such a grossly inflated estimate of total journey time, because it is adding in the headway for each leg (it might put you off travelling at all);
- more trivially, if a service switches in the evening from HF to LF. the last HF and first LF buses appear to get to the destination at pretty much the same time; conversely in the morning a double length gap appears at the destination.
What is particularly interesting is that there is no such distinction when using JP for tube services; the headway is not added in for high frequency services. Most (but not all) tube headways are small and perhaps they are less likely to bunch than buses but I’ve never grasped the differences in logic.
However, irrespective of the logic, it does seem very odd to me to add in the headways for high frequency bus routes without making it clear to the user that this is being done.
1 Like
Hi, you’re right that the headway used to be added in, but this was turned off last year, so this should no longer be happening.
As of a few months ago, Journey Planner now uses live bus data. Therefore, if you are planning a journey for ‘now’ (or within the next 30 minutes), any bus journeys should reflect the actual situation on the bus network.
@LeonByford
Well knock me down with a feather! Shows how often I actually use JP, I suppose.
A very sensible change (I had been banging on about it for years) but I must have missed the notification that a change had been made 
This was one of a few changes we made over the past couple of years that we didn’t really announce. If there’s interest, we could probably post on these forums when changes like this are made, or maintain some sort of changelog. I welcome any suggestions about this kind of thing.
That would make sense, except …
I’ve noticed that JP-recommended buses often now arrive at Chingford station leaving only 90 seconds to catch the train (which almost always departs bang on time, almost to the second). They used to allow at least several minutes.
It was made worse recently by one of those buses (which was on time according to the timetable) announcing that a bus is going to “wait here for a short time”, supposedly “to even out the service”. I did spot that the bus behind it was running late, and this was presumably a badly thought out attempt to reduce the delay between it and the next bus. But the result was that all passengers on that bus missed their train. And the delay was pointless anyway. There were only another two stops to the terminus, and no passengers boarded. So the bus could have continued its journey without delay, getting the passengers to its destination on time. Isn’t that more important than the cosmetic appearance of a more regular service?
It’s not JP’s fault that the bus didn’t behave as JP and traffic conditions predicted it to behave along that final stretch, but a bigger safety margin is needed.
hi @harry
Do you have an example journey we can look at? It would be good to understand that the source data is serving us well there or if there are any interchange time values that are not quite right. Usually Journey Planner gives a conservative estimate of the interchange time so this would be surprising.
Thanks,
James
@LeonByford
Thanks. The shift to using live data where possible is quite a big change, I think, even more so than stripping out the headway, so some sort of notification or log would have been useful. Having said that, I can remember from my working days sometimes being reluctant to make a big deal of an improvement, on the grounds that it invited the response “why on earth were you doing it that way in the first place?”, which sometimes was a very fair question!
I suppose that switching to live data means that if a bus is not reporting due to faulty equipment or some variation of the Chingford Conundrum JP is going to show the same gaps or inconsistencies as Countdown, though I suspect that the various apps available are used much more than JP for imminent journeys
I may have some recent screenshots but can immediately report a different observation relating to predictions for closed bus stops on a journey yesterday evening – which I will do later, in a separate thread, to avoid drifting off topic in this one.
1 Like
I appreciate your thoughts on this.
With regards to the use of live bus data, it is designed so that if there is an outage of the source system, or a problem with a given route, then Journey Planner falls back on using the bus schedules. The data is also normalised to handle any inconsistencies. But you’re right that if a particular vehicle is not reporting at all, then it wouldn’t appear in Journey Planner.
Could elaborate a bit more on what is distinction/purpose of both arrays stopPointSequences and orderedLineRoutes and how to use data to get “sequence of stops” to later retrieve each ones Timetabes. https://api.tfl.gov.uk/Line/229/Route/Sequence/all looks like an interesting case of “variety” - 3 lineStrings (2 of those identical values) with 6 arrays of orderedLineRoutes and 4 of stopPointSequence
Hi, the stopPointSequences array represents branches of a route. Think about how the Northern line has the Bank branch, the Charing Cross branch and the Battersea extension (amongst others). These aren’t complete end-to-end routes, but you can form a complete route by combining branches in different combinations. Note, however, that the branches in the Unified API don’t always match how we would typically think of a branch. For example, the API will have separate branches for each direction, and different parts of the ‘trunk’ of a line will also be represented by separate branches.
On the TfL website, stopPointSequences is typically used for bus routes. For example, if you take a look at the route page for Route 229 (inbound), you’ll see the three branches that make up that route in the inbound direction:
- Sidcup / Queen Mary’s Hospital to Carlton Road
- King Henry School to Carlton Road
- Carlton Road to Thamesmead Town Centre
By combining these branches, you can produce the full end-to-end routes:
- Branches 0+2 = Sidcup / Queen Mary’s Hospital to Thamesmead Town Centre
- Branches 1+2 = King Henry School to Thamesmead Town Centre
The orderedLineRoutes array, on the other hand, provides the end-to-end routes that are constructed by combining branches. On the website, these are typically used for non-bus lines, e.g. bus routes. For example, take a look at the Northern line route page. Notice the “View stations by” drop-down that allows you to select a route. You’ll see the following end-to-end routes:
- Battersea Power Station ↔ Edgware
- Battersea Power Station ↔ High Barnet
- Morden ↔ Edgware via Bank
- Morden ↔ Mill Hill East via Bank
- Morden ↔ High Barnet via Bank
- Morden ↔ Edgware via Charing Cross
- Morden ↔ Mill Hill East via Charing Cross
- Morden ↔ High Barnet via Charing Cross
Whether you should use stopPointSequences or orderedLineRoutes depends on your use case: Are you interested in distinct sections of route, or are you interested in complete end-to-end routes?
To query timetables, you’ll need to at least know the line ID and a stop ID (potentially obtained from a Route Sequence request), and make a request to:
https://api.tfl.gov.uk/Line/{id}/Timetable/{fromStopPointId}
If you want timetables between two known stops, you can make a request to:
https://api.tfl.gov.uk/Line/{id}/Timetable/{fromStopPointId}/to/{toStopPointId}
I hope this helps. Please let me know if you have any further questions.