DLR arrivals ids all the same

I’m consistently finding that arrival data for DLR has all services with the same ID:


(That’s Lewisham but they all do it).

Any ideas. It’s obviously playing havoc with graphQL and it means SignalR updates are impossible.


Deleted - used the wrong NaPTAN.

1 Like

Apologies, could you provide any more info!?

You can always use https://api.tfl.gov.uk/line/dlr/arrivals to get the live status of the whole DLR in one go.

Many thanks for the reply. Looking at the line based feed for arrivals, the same problem exists (i.e. all the imminent departures from Lewisham have the same ‘id’). This means that there’s no reference code to use for Signal R and a key has to be created to prevent some services (GQL) from dumping loads of the records.

Hi @tomhop

Thanks for posting your question.

As per the inserted extract (provided by my colleague at TfL) in the earlier reply - currently the DLR (DAISY) data unfortunately does not contain individual vehicle IDs. All predictions calling at the same station will be allocated the same prediction ID. We use this data for DLR predictions within our own digital tools.
Please can you tell us a bit more about what you are doing with the data downstream / at your end, and we’ll see if we can help?

Thanks, I’m building an app which allows customers to show departure boards from stops, narrowed down to particular services (e.g. From DLR at Lewisham to Bank).

With other services (e.g. Tube, Bus), it’s possible to keep services up to date using Signal R (rather than constant short polling). However the way Signal R appears to be configured, is that only changed services are sent in the payload.

Say for example, I call the arrivals end point for Lewisham DLR, I might get 5 results. If I subsscribe to the Signal R feed for the stopPoint, I might then get an update on one of these five services, two minutes later. Since there is no key to identify which service has changed (For Bus, Tube, updates have populated and distinct ‘id’ fields per update), there’s no way of dealing with the Signal R update, other than repolling for all serivces from the arrivals endpoint.

Unless of course I’m missing something! This leaves me to think that short-polling is the only method that will work for DLR.

Hi, when a prediction has changed, all the predictions with the same ID should be re-sent. There should therefore be no need to short-poll since when you receive a prediction update, you should be able to replace all predictions you already have with the new ones you’ve received.

As an example, suppose you receive a prediction update with two predictions with ID -436501339, and you already have three predictions with ID -436501339. In this case, you can replace the three existing predictions with the two new ones (one of the previous predictions probably represents a train that has already arrived at the station).

Our website uses SignalR to update predictions, without any short-polling required:

Ok thanks. That does perhaps provide a route for me to proceed if all same-id projections are wrapped in this way. I’m actually using GQL subscriptions between my app and server. GQL subscriptions really rely on unique IDs per item, so I will need to find a way to implement this separately. Thanks.