It's cool to see how fast the trains go on different lines. But... where's the Elizabeth line? You get the tooltip when you hover over it, but the polyline is missing.
It's not a tube, it's an overground line. As evidenced by this Network Southeast livery.. on a tube train that's an overground train that goes entirely underground https://m.youtube.com/watch?v=MhUDyX4DKXQ
The Waterloo and City was transferred to London Underground in 1994, as part of the privatisation (or not in this case) of British Rail.
As the only way to get trains on and off the line involves craning them out of the depot[1], they did retain their Network South East livery for about a decade after formally becoming an Underground line though, until repainted at an off line overhaul.
[1] There used to be a lift that could take a carriage at a time to surface tracks, but the Eurostar extension at Waterloo did for that.
It’s probably excluded because TFL don’t classify it as an Underground line. Similarly, hovering over the DLR will produce a tooltip but the line is excluded.
One of the best game I ever played is the text based souvenir game shopping game on Windows 3. I can't recall the name of the game now since it's more than 30 years ago, but it's about shopping souvenirs using London Underground Tube. You have a semi realistic time constraints like train schedules, your flight schedules and of course list of souvenirs items to shop. This is totally offline since there is no Internet available at the time but it's very engaging nonetheless.
My proposal for the modern version of the game is to use real-time train schedules (with delays, ticket discounts, etc) that are available publicly on the Internet for many metropolitan cities in the world for examples Tokyo, London and Berlin.
Imagine you can have a real-world realistic in-app in-game items purchases feature that you personally can buy in the game and delivered to you or anyone you fancy of giving souvenirs except that you only virtually went there.
Maybe a slight bug: the overlay doesnt appear to be locked to the map - when I scroll around, the overlay moves. Currently the northern lines' southern terminal is hovering over Kingston rather than Morden!
> It serves data from individual arrivals boards, which all spell stations differently
It doesn't, at least not for most lines. TfL's data is notoriously inconsistent, with multiple backends used for different purposes. For most lines, the dot matrix indicators are fed by the signalling system and timetables (more modern signaling systems are timetable-aware). Meanwhile, the online API relies on estimates from TfL's TrackerNet.
Although it has a core section that does run underground through tube-like tunnels, it isn't classified as a tube line :) So isn't part of the "London Underground"
I note that the times for future stations are in UTC and not BST. Also, when you zoom in to only a couple of stations, the trains seem to vanish occasionally -- maybe when part of the train reaches the edge of the display. I also find it jarring that the trains appear above the buildings rather than get hidden by the buildings. I'd like to see the trains running along the surface... All of these suggestions are much easier to make than to implement!
I once saw a rendering of parts of the underground showing the stations and the tracks in 3D (hand-drawn but in scale), what stood out to me is how much of the entire system is composed of stations and how little for the actual tubes connecting those areas, certainly in the busier areas. I was hoping to see the stations rendered as well as I never could find those images back. This looks very nice in any case, reminds me of marinetraffic.
The trains themselves have different colours though, so it's not too bad.
Personally, I think the stations themselves are a bit too dark and hide any train that's at the station once the trail disappear. But overall, I think this visualisation is beautiful.
I've seen visualisations similar to this before, but this one is by far the most beautiful and I could watch it all day.
I echo the sentiments on the TfL API, I've built the same Tube Tracker app over and over for more than 10 years[1] as my go-to for learning new tools[2] or testing changes to frameworks[3] and I'm not sure it's ever improved. A chap called Chris Applegate wrote extensively about his battles more than a decade ago[4], did they ever add the stations between Latimer Road and Goldhawk Road on the Hammersmith & City/Circle line?
its incredible the sentiment on TfL API without realising your country even has an API for your public transport. Thats a huge leap in itself, let alone an actively maintained one
The Austrian version of this is particularly cool because it has all forms of public transport on it: https://anachb.vor.at/ (click Kartenoptionen -> Live map -> alle einblenden).
I just spent a bit of time in Wien and was blown away by the ease of use of their transit system and its integration into Google Maps. For someone from the US, it's like a different world.
> You will regret using this data. You will regret using this API.
> It serves data from individual arrivals boards, which all spell stations differently.
> It describes train status in free text that varies between stations. “Approaching Barnet”, “Near Waterloo”, “Heading to Bank”, “Departing Southgate”, “Leaving Hampstead”, etc.
I'm not sure what you expected from an organisation still offering nothing but SMS-based MFA to its "customers" and one that got massively disrupted by a 17 year old in a cyber incident which seemed to paralyse the entire organisation a few months ago...
Seems to be: "TfL’s efforts to deal with the cyber attack have resulted in a growing shutdown of its own systems, meaning that new zip cards used by children and teenagers cannot be obtained" "17-year-old male has been arrested on suspicion of Computer Misuse Act offences in relation to the attack. The teenager, who was arrested in Walsall ..." https://www.standard.co.uk/news/london/tfl-cyber-attack-pers...
It's also the organization that rolled out the second large stored-credit contactless payment system in the world (after Hong Kong), and was the first to introduce bank card contactless payments.
Best part of 20 years ago, which is a long time in anything, it's a lifetime in tech.
About 15 years ago I used to work on some projects for greater London authority, we seemed to mostly be squatting on transport for London servers and they seemed to have good tech and people seemed to like using it. 5 years later they couldn't get away fast enough.
These days just tap a contactless credit card is about as good as it gets-while still having the Oyster alternative where the credit card isn’t a good or preferred option.
Hurrah. That was 13 years ago and it still doesn't support railcard discounts.
TfL may have been innovative a long time ago, but they haven't moved with the times at all. Hell, the Oyster POMs only got contactless payment readers in the last couple of weeks. Prior to that it was "chip 'n' pin" - y'know, the technology introduced back in 2004.
FunFact: I have enjoyed HN for about 10 years even though I have NO IDEA what an API etc. is. A tribute to its welcoming big tent for non-techies like me who wouldn't know a dark pattern from dark matter.
If you're curious: An API is more or less just the communication boundary between two pieces of software.
A common sign of a bad API (including this one) is when it presents data in an overly human-centric way rather than something more computer-friendly.
For a human it's really easy to see "Regents Park" and "Regent's Park" are very very likely referring to the same station, but a computer can't know that unless a human goes out of their way to tell it that.
You could argue the TfL API is perfectly fine for its intended use-case of updating the arrival screens (which are meant for humans), but it's generally better to design APIs to grow for future use-cases you haven't thought of yet. Changing an API tends to be hard once it's being used in the real world.
For example: The older TfL stations have LED matrix displays for displaying information, which are very limited in how much text they can display at once. The newer stations have big TV screens instead, which can show a lot of information. It wouldn't surprise me if this is the underlying reason behind some of the inconsistencies, especially ones like "Kings Cross" vs "King's Cross St. Pancras". I'd bet the longer names with punctuation correspond to arrival displays in the newer stations.
this reminds me of the time I got on a train to Kingsley instead of King's Cross, because the train board only said "Kings" and I didn't think to check the boards/platform number in a rush.
An Application Programming Interface provides data to a requester. They are built/shaped by the provider and so the provider usually has documentation for a user to know how to pull and parse it, with example snippets.
Its like having a printer with preset documents it can print. You set it on your desk, and others can click a button to have the chosen preset sheet come out. You can get creative by hiding some buttons, making some buttons also require a fingerprint of the user to print the paper, or the printout changes every minute, etc.
But the API printer sits on someone's server and prints objects, or organized data, and sends it to whatever you used to call, or request, from the API.
I'll try and explain it simply with no technical information.
An API, or Application Programming Interface, allows you to interact with software using pre-defined agreements, or contracts.
Think of API as a set of legal contracts. I use this analogy when explaining it to lawyers.
If I give you $5, and I say give me an Apple, you will give me an Apple, as expected by the predefined contract, that I receive an Apple.
If I end up receiving Broccoli, then what we have here, is a bug. Or, in other words, the contract has been broken.
Now apply this to other domains in commerce - e.g. I give an ID of an item in a store, and I get back the name of the item, it's price, and if it's stock.
For each person who is willing to speak up and say they don't understand something, there's usually dozens more who silently are wondering the same thing. Even if the parent commentor didn't want an explanation, they opened to floor for others to help out the silent folks who actually were curious as to the explanation.
So true. I have a rule of 100: for every person who takes the time and trouble to actively respond to something on the phone/by mail/online, there are 99 others who feel exactly the same way but can't be bothered.
116 comments
[ 5.9 ms ] story [ 182 ms ] thread> *You will regret using this data. You will regret using this API.*
> It serves data from individual arrivals boards, which all spell stations differently
> It has a load-balancer that regularly returns data that is older than the data returned in the previous request.
Won't someone think of the Ai overlords who will take care of all this for us in the future. A bit of consistency goes a long way.
As the only way to get trains on and off the line involves craning them out of the depot[1], they did retain their Network South East livery for about a decade after formally becoming an Underground line though, until repainted at an off line overhaul.
[1] There used to be a lift that could take a carriage at a time to surface tracks, but the Eurostar extension at Waterloo did for that.
You can find it if you hover north-east of Waterloo.
My proposal for the modern version of the game is to use real-time train schedules (with delays, ticket discounts, etc) that are available publicly on the Internet for many metropolitan cities in the world for examples Tokyo, London and Berlin.
Imagine you can have a real-world realistic in-app in-game items purchases feature that you personally can buy in the game and delivered to you or anyone you fancy of giving souvenirs except that you only virtually went there.
It doesn't, at least not for most lines. TfL's data is notoriously inconsistent, with multiple backends used for different purposes. For most lines, the dot matrix indicators are fed by the signalling system and timetables (more modern signaling systems are timetable-aware). Meanwhile, the online API relies on estimates from TfL's TrackerNet.
Good job on this and pretty cool.
> dist.min.js:11 deck: LineString coordinates are malformed
and no trains appear :(
https://tfl.gov.uk/
Personally, I think the stations themselves are a bit too dark and hide any train that's at the station once the trail disappear. But overall, I think this visualisation is beautiful.
Also, trains disappear when they stop. Which is - uh - strange.
It's more pretty than practical. Trains marked with dots, arrows, or boxes would be far easier to read.
I find the 3D trains (and planes) easier to see.
Also, I love the webcams scattered around the city, and especially those which have sound.
I echo the sentiments on the TfL API, I've built the same Tube Tracker app over and over for more than 10 years[1] as my go-to for learning new tools[2] or testing changes to frameworks[3] and I'm not sure it's ever improved. A chap called Chris Applegate wrote extensively about his battles more than a decade ago[4], did they ever add the stations between Latimer Road and Goldhawk Road on the Hammersmith & City/Circle line?
[1]: https://www.matthinchliffe.dev/2014/03/05/building-robust-we...
[2]: https://svelte-tube-tracker.vercel.app/
[3]: https://github.com/i-like-robots/react-through-time/pulls
[4]: https://web.archive.org/web/20150620042340/http://www.qwghlm...
The detailing of things like how trains "overlap" each other is incredible
[1]: https://github.com/charleskubicek/wheres-my-tube
https://minitokyo3d.com/
> You will regret using this data. You will regret using this API.
> It serves data from individual arrivals boards, which all spell stations differently.
> It describes train status in free text that varies between stations. “Approaching Barnet”, “Near Waterloo”, “Heading to Bank”, “Departing Southgate”, “Leaving Hampstead”, etc.
I'm not sure what you expected from an organisation still offering nothing but SMS-based MFA to its "customers" and one that got massively disrupted by a 17 year old in a cyber incident which seemed to paralyse the entire organisation a few months ago...
https://youtu.be/8TVpQiCIqp4
TfL may have been innovative a long time ago, but they haven't moved with the times at all. Hell, the Oyster POMs only got contactless payment readers in the last couple of weeks. Prior to that it was "chip 'n' pin" - y'know, the technology introduced back in 2004.
A common sign of a bad API (including this one) is when it presents data in an overly human-centric way rather than something more computer-friendly.
For a human it's really easy to see "Regents Park" and "Regent's Park" are very very likely referring to the same station, but a computer can't know that unless a human goes out of their way to tell it that.
You could argue the TfL API is perfectly fine for its intended use-case of updating the arrival screens (which are meant for humans), but it's generally better to design APIs to grow for future use-cases you haven't thought of yet. Changing an API tends to be hard once it's being used in the real world.
For example: The older TfL stations have LED matrix displays for displaying information, which are very limited in how much text they can display at once. The newer stations have big TV screens instead, which can show a lot of information. It wouldn't surprise me if this is the underlying reason behind some of the inconsistencies, especially ones like "Kings Cross" vs "King's Cross St. Pancras". I'd bet the longer names with punctuation correspond to arrival displays in the newer stations.
Its like having a printer with preset documents it can print. You set it on your desk, and others can click a button to have the chosen preset sheet come out. You can get creative by hiding some buttons, making some buttons also require a fingerprint of the user to print the paper, or the printout changes every minute, etc.
But the API printer sits on someone's server and prints objects, or organized data, and sends it to whatever you used to call, or request, from the API.
An API, or Application Programming Interface, allows you to interact with software using pre-defined agreements, or contracts.
Think of API as a set of legal contracts. I use this analogy when explaining it to lawyers.
If I give you $5, and I say give me an Apple, you will give me an Apple, as expected by the predefined contract, that I receive an Apple.
If I end up receiving Broccoli, then what we have here, is a bug. Or, in other words, the contract has been broken.
Now apply this to other domains in commerce - e.g. I give an ID of an item in a store, and I get back the name of the item, it's price, and if it's stock.
People use web browsers to hit websites, but when code hits URLs they are typically just called APIs. A website is technically an API too