Where can I find bus route "towards"


#1

Hi,

I’m migrating from using legacy APIs to the unified API, and I’m having trouble finding a particular piece of data.

If you look at https://tfl.gov.uk/bus/route/466/?Input=466&direction=inbound, you’ll see towards “Addington Village”. This is different from Name and DestinationName in the routeSections (“Purley / Downlands Precinct - Addington Village Interchange” and “Addington Village Interchange” respectively), and I can’t find it anywhere else in the lines or routes.

Can anyone point me at the right place please?

Thanks,
Nick


#2

Looking at api.tfl.gov.uk/Line/466/Route/Sequence/inbound, I’m seeing 490003101E as the last stop of branch 2 in stopPointSequences. This has a name of Addington Village Interchange and is stop E there. Its topmost parent is 490G000380 (entry 45 in the stations section), also called Addington Village Interchange and representing the whole cluster of stops at this location. If you look in orderedLineRoutes, you will see that both routes are also shown as terminating at Addington Village Interchange. Like you, I’m not sure where Tfl are getting the Addington Village name, although I suspect it’s probably the name on the destination blind on the physical bus.


#3

Exactly, and that’s what I need. They must be getting it from somewhere, but I can’t see it anywhere


#4

Does this extract from the Datastore XML file help?

	<VehicleJourney>
		<PrivateCode>tfl-8-466-_-y05-45199-2-MFSc</PrivateCode>
		<DestinationDisplay>Addington Village</DestinationDisplay>
		<Operational>
			<VehicleType>
				<VehicleTypeCode>SDLW</VehicleTypeCode>
				<Description>Single Decker Low Floor+Wheelchair</Description>
			</VehicleType>
		</Operational>
		<OperatingProfile>
			<RegularDayType>
				<DaysOfWeek>
					<MondayToFriday />
				</DaysOfWeek>
			</RegularDayType>
			<SpecialDaysOperation>
				<DaysOfNonOperation>
					<DateRange>
						<StartDate>2017-10-23</StartDate>
						<EndDate>2017-10-27</EndDate>
					</DateRange>
				</DaysOfNonOperation>
			</SpecialDaysOperation>
		</OperatingProfile>
		<VehicleJourneyCode>VJ_8-466-_-y05-45199-2-MFSc</VehicleJourneyCode>
		<ServiceRef>8-466-_-y05-45199</ServiceRef>
		<LineRef>8-466-_-y05-45199</LineRef>
		<JourneyPatternRef>JP_8-466-_-y05-45199-31-I-2</JourneyPatternRef>
		<DepartureTime>05:20:00</DepartureTime>
	</VehicleJourney>

#5

Hi Michael,

It does, in that I can see the info I need is right there in the Addington Village element.

Ideally, though, I want to be able to get that information from the Unified API, rather than having to go to two sources. After all, that’s probably what “unified” means :slight_smile:

Do you think the website is using this XML file behind the scenes?

Cheers,
Nick


#6

Good question but one I’m not really qualified to answer. While I would expect them to be related, they may derive from a common parent rather than one using the other.

Looking at one of the applications that uses the live feed (London Vehicle Finder at https://lvf.io/) I see a third variation “Addington Vill”. Using this application on some of my local routes I have noticed in the past that what appears on LVF matches what appears on the screens at bus stops. For the 184, for example, I see “Barnet” (the bus itself shows “Barnet, Chesterfield Road”). On the other hand I also see “Barnet Spires” on the 326 and “Barnet Church” on the 34 and “Barnet Hospital” on the 263 (thouigh just “Barnet” for the 389. I’m assuming this is because of limitations on the number of characters that can fit on the screens. It does imply though that something other than “Addington Village Interchange” is stored in the live feed but I would not know whether “Addington Village” is there alongside “Addington Vill”.

As an aside, the 184 illustrates the difficulty of naming places/stops in a way that makes sense to all users. Someone in Wood Green might not know where Chesterfield Road (the actual destination) is but would recognise Barnet. Someone waiting in Barnet for a bus to Chesterfield Road would not be helped by a sign showing “Barnet” but then they are probably used to it!


#7

Hi @stile,

Yes the Unified API does use that TransXChange XML behind the scenes. The “towards” you are referring to is actually from the Line/Search API rather than being returned from Line/Route as you’d expect. This is a limitation of the API that I wasn’t aware of which I’ll add to our backlog.

The web page in question https://tfl.gov.uk/bus/route/466/?Input=466&direction=inbound calls the Route API, but then passes the lineId into Line/Search, and looks for the first match in the right direction. It makes that additional API call solely to retrieve the “towards” string from the vehicleDestinationText property. D’oh.

https://api.tfl.gov.uk/line/search/466?mode=bus

{
  "input": "466",
  "searchMatches": [
    {
      "lineId": "466",
      "mode": "bus",
      "lineName": "466",
      "lineRouteSection": [
        {
          "routeId": 2516,
          "direction": "inbound",
          "destination": "Addington Village Interchange",
          "fromStation": "Westway",
          "toStation": "Addington Village Interchange",
          "serviceType": "Regular",
          "vehicleDestinationText": "Addington Village"
        },
        {
          "routeId": 2518,
          "direction": "outbound",
          "destination": "Westway",
          "fromStation": "Addington Village Interchange",
          "toStation": "Westway",
          "serviceType": "Regular",
          "vehicleDestinationText": "Caterham-on-the-Hill"
        },

The VehicleDestinationText is indeed what would be shown on the vehicle blind. In fact, for the 466 in the outbound direction this is “Caterham-on-the-Hill” - quite different from the name of the last stop on the route. So it is a useful piece of information for customers looking to catch the correct bus!

For now you might be able to use the same work around. I’ve raised an item on our backlog to get the VehicleDestinationText returned from the Route API so that two API calls aren’t necessary. SVC-4433


#8

Hi Tim,

Ah, mystery solved! I had suspected it would be there somewhere. Thanks very much for the info - I’ll use the same workaround for now.

Kind regards,
Nick


#9

is there any update on SVC-4433 please ?

Thank you


#10

Hi @nakkore

I will bring this up in the next sprint prioritisation on Thursday and let you know when we can do this.
Thanks,
James


#11

brilliant.
Thank you