Many years ago, there was proxied access to the TrackerNet API via a GLA-hosted server which highlighted the popularity of the API and crashed TrackerNet, I understand. Soon after, an official Open Data version of the platform was launched with a caching front-end with an expiration of 30 seconds.
Although this is brilliant, is it possible to get access to a stream of TrackerNet data, similar to the Live Buses stream? Since the introduction of TBTC on the Northern Line, trains are identified down to track sections which are much more granular then the previous track circuits, and I have a use-case which would benefit from being able to track movements in real-time.
In response to the first part of your question - yes, the Unified API allows you to not only poll the Arrivals API with its caching front-end, but also register for push notifications using SignalR and websockets - allowing for low-latency updates without high-frequency polling. See how to use that in this blog article “Unified API Part 5: AoT - Arrivals of Things”. Also we consistently handle TrackerNet, Countdown, DaisyDLR, Darwin etc. through the same interface, so less work for developers to build multi-modal arrivals boards.
On the second part - I’m not familiar with TBTC, but whenever a downstream system is updated we would hope to surface whatever improvements we can on the API. I’ll see what I can find out.
Thanks - I hadn’t realised the Unified API had push functionality too.
On the TBTC side of things, where a train was reported as occupying a particular track section (e.g. ‘TAA/TAB/TAC’), because of the way movement authority is granted, trains are detected at much finer precision, down to the metre or less, I think. If you look at the Northern Line on TrackerNet, trains move smoothly down the track, as opposed to, say, the Metropolitan where they hop between track sections.
I’ll play with the Unified API soon and report back. There aren’t enough hours in the day!
Just to follow up, I took a look at the Countdown data available through the Unified API, and it’s a subset of what’s available from the API on cloud.tfl.gov.uk, so no TrackCode or LCID elements, which is a pity as I wanted to bring the OpenTrainTimes style maps to the Tube!
We can look at exposing those additional identifiers in the Unified API if they’d be useful. Is it just the TrackCode and LCID, or are there others? What is the set number that @krn is referring to?
This includes SetNo and TripNo. SetNo has come across as vehicleId in the Unified API, but TripNo is missing.
The practical outcome of this is that each train has a Train Number (SetNo) which says what paths/times it is running to and a Trip Number which increases throughout the day whenever it changes ends. The latter can be used to therefore better understand how well the train service is running.
That does sound useful! I’ll create a feature request to have that data attached to the Unified API prediction as key value pairs - this is our usual pattern when there is feed-specific data that can’t be shoehorned into the common model.
Interesting discussion. Could anyone point me to any resources that describe how the TrackCode can be used to determine the train posiiton. I have seen some historic FOI requests around this that seemed to suggest that the relation of this code to any geo-position remains unpublished.
The track code on conventionally (track circuited) signalled lines is the track section name. Usually the name of the track circuit (e.g. TJ894B between Baker Street and Finchley Road), or a combination of track circuits (TJ793A.B.C.D.E.F on the approach to Moor Park).
Unless you have a detailed signalling diagram - which are likely not in the public domain - you may have to look at a combination of the TrackCode and TimeTo fields to work out in which order track sections are on plain line.
Track sections don’t have a geographic position as such - they simply indicate the track is occupied between two points - more like a linestring than a point in GIS terms.
For in-cab signalled lines (Victoria, Jubilee, Northern), the track codes appear to be every metre or so, such as TN60195. The TimeTo field appears to decrement linearly with the track code increasing or decreasing.
The Network Rail train describer (TD) feeds are the equivalent of this type of data nationally. I’d love to see a similar sort of detailed feed from TfL!
@poggs Sadly not. This change only affects the “legacy” Trackernet Detailed feed. We have taken the feedback onboard from this forum and are looking at options for adding the additional feeds to the Unified API.