Each tunnel is only for a single direction and thus you can actually have multiple trains between the same two stations but heading in opposite directions. Moreover, at rush hour some of the busier lines might even have more than one train in the same tunnel for some stretches of tracks.
There is no way a PCB this size could give an accurate representation. I'm not even sure that level of detail is even published by the TFL. But it shouldn't matter, this is clearly intended to be more ornamental than it is a functional tool for locating carriages.
If you can show a train leaving, and a train arriving then you only lack direction, which should be in the datastreams.
So you'd leave(station=A,direction=0), then increment the tunnel A-B until you next had an arrive(station=B,0) when you'd decrement the tunnel section. Even branched tunnels Should Just Work ®. The tunnels are stacks, unless there are hidden sidings and such, things should add up. Bonus you change colour according to magnitude of $tunnelABC.
More than twice because each station has multiple platforms so you'd need more double the LEDs just for the stations (stations with more than one line would need a minimum of 4 times as many LEDs). Then you have to double that up for each tunnel too. Even with your revisions if you have a train arriving on one platform and leaving on another, which does actually happen (a lot!), then the PCB has no way of representing that data stream.
Ultimately the level of detail you're describing is not feasible with the aesthetic the designer was going for. This is one of those problems that appears much easier than it really is.
Plus, at risk of repeating myself, this is clearly intended to be more ornamental than it is a functional tool for locating carriages.
There is no way a PCB this size could give an accurate representation. I'm not even sure that level of detail is even published by the TFL. But it shouldn't matter, this is clearly intended to be more ornamental than it is a functional tool for locating carriages.