Getting duplicates for upcoming arrivals/stops while fetching for vehicle id

Hey there,

I am new to the Unified API and recently started testing out some endpoints.

I would like to fetch an array of upcoming stops served by a specific vehicle.
I found the /vehicle/{vehicleId}/arrivals endpoint which is sufficient for this task.

Problem here is the returned and filtered request now showing me this (see the simplified example below), where I can find duplicate stations listed (x marks the spot) - I assume those are parent stations and siblings.

The Example shows the upcoming stops for the elizabeth line from Liverpool Street to Heathrow Terminal 4:

London Liverpool Street Rail Station (910GLIVST) - arrival at 2023-07-13T07:41:55Z (X)
Liverpool Street (910GLIVSTLL) - arrival at 2023-07-13T07:41:55Z
Farringdon (910GFRNDXR) - arrival at 2023-07-13T07:43:52Z
Farringdon Rail Station (910GFRNDNLT) - arrival at 2023-07-13T07:43:53Z (X)
Tottenham Court Road (910GTOTCTRD) - arrival at 2023-07-13T07:46:37Z
Bond Street (910GBONDST) - arrival at 2023-07-13T07:48:48Z
Acton Main Line Rail Station (910GACTONML) - arrival at 2023-07-13T07:59:44Z
Ealing Broadway Rail Station (910GEALINGB) - arrival at 2023-07-13T08:03:04Z
West Ealing Rail Station (910GWEALING) - arrival at 2023-07-13T08:05:48Z
Hanwell Rail Station (910GHANWELL) - arrival at 2023-07-13T08:07:43Z
Southall Rail Station (910GSTHALL) - arrival at 2023-07-13T08:11:07Z
Hayes & Harlington Rail Station (910GHAYESAH) - arrival at 2023-07-13T08:14:05Z
Heathrow Terminal 4 Rail Station (910GHTRWTM4) - arrival at 2023-07-13T07:39:06Z

Is there a way to exclude the duplicate parent stations? In the returned request I have no chance doing this by looking at another parameter other than the naptanId (stopId) or the stationName. Latter is not really a match when comparing endings i.e. “Rail Station”. Is there a specific pattern naptanIds are following at the ending?

Bonus question:
Is there a way to get already passed stops from the past too?
The endpoints only shows the upcoming and remaining ones

Thanks in advance

Welcome @fred

Yes, this is a problem . The NRE-coded version of the solution is…

which also fixes the similar problem at Upminster and Barking.

Hello and welcome to the forum!

Unfortunately, the Elizabeth line arrival data is not really designed to support this use case where you require a vehicle-centric view.

You may be interested in the Service Details data from National Rail, which provides historical data in additional to data about upcoming arrivals and departures. For reference, the operator code for the Elizabeth line is “XR”.

Thanks guys for the replies :+1: I will have to apply some filter logic here i guess.

Altogether a quick feedback (though not related to this question):

The API has some very strange approaches on how I query it for obvious simple data - it is like all over the place, connecting dots with dots.
Not to begin with missing intermediate stops arrival/departure info while planning a route or why we have arrival entries at terminal stations where departures would be more useful (even more funny this topic was raised in 2017 here - 6 years ago and still no interest)

Tldr; not really user-friendly but huge potential when simple things were done right

1 Like

If you’re just after ALL the basic info: tube stops and timetables, tram stops and timetables, dlr stops and timetables and every TfL bus stop and timetable you just need one call to

Thanks for your feedback. We are always keen on hearing what developers would like from us in terms of open data.

Could you please explain this in a bit more detail? Are you referring to JourneyResults requests? For each leg, we return the intermediate stops for each leg (in addition to the start and end stops). But am I correct in thinking you would like the times that each station is called at?

For the Elizabeth line and London Overground, it is possible to obtain departure times as well as arrival times. For example:
For other modes, I can assure you that it is not because of lack of interest that this is unavailable, but we are unfortunately limited by what the source systems are able to provide. That said, we are actively working on addressing this shortcoming and hope to be able to provide some improvements to this soon.

Thanks for the followup and for being open for suggestions :+1:

To be percise, yes that’s the Journey/JourneyResults/ endpoint which I found being helpful for solving my issue with duplicates stated above. I enter fromStationId and toStationId and get the served stops + even the path lineString - though I wished having the arrivals/departure times and coordinates here for the intermediates aswell.

So what’s missing on the intermediate stops are the times and coordinates.

Extraordinary solution would be an endpoint vehicles/{id}/journey which returns the past + upcoming stops (times + coordinates) + the lineString path

As a commuter it is not very helpful looking at a start station and seeing multiple “Check Front of Train” as the given destinations. There might be multiple destinations, but which train runs to which?
Lets take Ealing Broadway Underground Station for example: Here the destination for a district line switches to Barking right when the train is leaving (“Due” displayed - 0 mins remaining).

Sure I can use static timetable data and provide the missing desination headsigns here, but I am here for realtime data - that’s why I fetch the API and then realise this valuable information is missing.

Especially for ArrivalDepartures it is confusing that it is only returns for overground trains and the elizabeth line, when one has to pay attention to query StopPoint/{id}/Arrivals for all other modes.

Though, as there is not always useful data returned when stationId equals destinationId, it might be helpful if there would be a dedicated /Departures endpoint - mostly for stops where lines start

Thanks for confirming the data you would like to receive from JourneyResults.
This data is available from our Journey Planner engine, so I have created a ticket (#96667) to provide this data through the Unified API.

Unfortunately, the other data you have requested is somewhat more difficult for us to provide due to limitations with the underlying systems. However, we are hoping to address some of these points soon.

(cc @SarahLS)

1 Like