I note that for all bus vehicle arrivals I try, I get an empty destinationNaptanId - e.g.:
"destinationName": "Holloway, Nag's Head",
I need to be able to query the destination stop point for connecting lines and facilities etc. Unfortunately, trying to search for the stop point with the ‘destinationName’ doesn’t work in the returned format (the actual destination name is ‘Holloway / Nags Head’ - not sure why the difference?)
Is this a bug to be fixed and is there any other way I can get this from the API in the meantime, given e.g. the line and direction?
Hi Chris, welcome to the forum! (I appreciate the Bomberman picture.)
Unfortunately, Countdown (the source system) does not provide us with an ID for the destination stop, and this is why the
destinationNaptanId property is not populated.
We appreciate that it would be useful to know the ID of the destination stop, and we are therefore trying to find a way to provide this information in our open data.
As an aside: The destination name of a stop can differ quite a lot from its common name. For example, one of the possible destinations for Route 63 is “Smithfield,Farringdon Street”, and that is what you would see in the
destinationName property. However, the stop it actually refers to is 490005027N, with the common name “Snow Hill”.
OK, thanks for the info. I think I may be able to do something around the stop point where the direction changes from inbound to outbound and vice-versa for the moment.
This is why I’ve arguwd for some time that the Naptan list of stops really needs a third name field - full (long) name, short name and a new ‘Terminus name’ field.
I fear it’s a bit more complicated than that.
Let’s take a look at the Stop_In_Pattern data for two routes that share some common stops.
<Stop_In_Pattern aStop_In_Pattern_Idx="53579" aPattern_Idx="3720" aDestination_Idx="961" aStop_Point_Idx="11848">
<Stop_In_Pattern aStop_In_Pattern_Idx="75337" aPattern_Idx="5389" aDestination_Idx="822" aStop_Point_Idx="11848">
So both these routes serve the Stop_Point with
Now let’s check the Stop_Point data to check what stop that is:
<Stop_Name>Plumstead Bus Garage</Stop_Name>
<Towards>Bexleyheath, Abbey Wood Or Thamesmead</Towards>
Okay, so both Route 180 and Route 472 serve Plumstead Bus Garage (490011069A). So far so good.
But notice in the Stop_In_Pattern data that the entry for Route 180 has
aDestination_Idx="961" whereas the entry for Route 472 has
aDestination_Idx="822". Let’s look these up in the Destination data:
<Long_Destination_Name>Plumstead Bus Garage</Long_Destination_Name>
What does this mean? When a Route 180 bus terminates at Stop 490011069A, its destination blind (and the
destinationName property) will read “Plumstead Bus Garage”, whereas when a Route 472 bus terminates at the exact same stop, the destination will be “Plumstead Station”.
In other words, a bus stop can have multiple destination names, depending on the serving routes. That’s not to mention the fact that there is a Long_Destination_Name and a Short_Destination_Name (I’m not too sure where the latter is used).
Isn’t the problem here that TfL systems are ones of “arrivals” rather than “departures”.
This means that either the first or last place a bus (in this instance) stops can’t be included in such a list.
The problem is also paralleled with the tubes (arrivals) which have be recoded from their timetable data?
As I recall, I ended up using a special “DynamicDestinationDisplay” value in the TfL Bus ftp (TransXChange format) file.
This value is unique to the TfL TransXChange data bus sets.
In fact, it is not only the first stop on a route that a bus cannot terminate at. Each bus route has only a handful of possible destinations. I suspect this may be due to some bus stops not being suitable for terminating at, and also due to the limitations of mechanical destination blinds.
For example, Route 63 has the following possible destinations:
||King’s Cross Station
||King’s Cross Station / York Way
||Old Kent Road / East Street
||Elephant & Castle
||Elephant & Castle / London Road
||Bricklayer’s Arms / New Kent Road
Now that I pull this together, I realise there is actually a many-to-many mapping between Stop_Points and Destinations (one Stop_Point can be associated with multiple Destinations, and one Destination can be associated with multiple Stop_Points).
So if Countdown gives a destinationName of “Bricklayer’s Arms”, that could refer to three possible stops. Which is fine if the bus is going towards Honor Oak since there is only one stop in that direction. But in the King’s Cross direction there are two.
In other words, even if you know the route, direction and destination name, that’s not always quite enough information to know exactly which stop a bus will terminate at.