Thank you, that’s really helpful and has stimulated me to wondering if I can do better than I’m doing right now.
The TrainID is a curiosity. I’m rather focused on the Metropolitan line, where the problem of identifying trains is most acute (at least beyond Wembley Park) and on these bits of the network it’s quite common to have no information at all, no LCID, no Leading Car and a SetNo (Train Running Number) of ‘000’.
As I’ve already mentioned there are typically two TrackerNet TrainIDs for each physical train - to pick an example right now, this is the Watford train at Northwood Hills. Set No is 000. TrainID1 is 1096711 and TrainID2 is 1096461. In this case there is an LCID (24982) and Leading Car (21074) so I’m confident that these two sets of TrackerNet results with different TrainIDs refer to the same physical train.
This isn’t the case on all lines though, the Jubilee line for example only has one TrainID per train - perhaps you’d expect that since it’s more modern. The Central line is curious, sometimes there’s one, sometimes two.
If you can link the two IDs together through some other piece of data, that seeems to be the best approach to getting a unique ID which lasts for the duration of the journey. However I’m often reduced to guessing, based on the fact that two different TrackerNet records refer to a similar ‘looking’ train and appear to be on the same bit of track. That’s not always the case, sometimes two IDs claim to be on different track sections even though they’re clearly the same train and very occasionally they give contradictory information, for example different destinations. That’s confusing.
They do occasionally change in mid-journey as well, specifically at Harrow on the Hill (where all sorts of strange and unpleasant things happen). My working theory is that these numbers relate to the train staff - it’s a guess - I really have no idea - and that these numbers may change if there’s a driver change. It pleases me to think that there’s one at the front of the train and one at the back, hence the sometimes differing track codes.
This discussion has prompted me to look again at the function that I’ve made to generate a unique identifier. After a lot of trial and error, this approach seems to work best, but I’m sure it can be improved:
If there’s a SetID that isn’t ‘000’, then use that, but put a line identifying digit at the front and add the TrackerNet ‘Trip Number’ to the end - it helps sort out the occasional duplicate SetIDs on a line. If not then …
If there’s an LCID then add a digit to the beginning to identify the line and use that (I assume I’m doing that because I found duplicate LCIDs on different lines). If the LCID is less than 99 (but greater than 0) stick 99 at the front (to avoid possible conflicts with the SetIDs from step 1) If no LCID then …
If there’s a Leading Car just use that. If not …
… use the TrackerNet TrainID, but before you return that value, check to see if there’s another TrainID on the same track. If so, link them together and return one or the other but not both (I stick them in a dictionary and pick one).
… endif
…endif
…endif
endif
Which is a bit of a performance and I’m sad to say, doesn’t always work. I do get occasional duplicates, records that - when you plot them on a map - obviously relate to the same train but there is no piece of data that can automatically link them. To get round this issue I would need to add a proximity check, to see if these two ‘trains’ are so close together that they must, actually, be the same vehicle (or there’s some horrible accident in progress). Using the track location field might work for that … sometimes. Alternatively a proper graph of the track codes is what’s needed (so say we all).
None of this will work on the DLR, where - as far as I can see, there’s no useful information at all. Sorting that out is an intruiging technical problem that I might wickedly assign to one of my A-Level students as a project, but frankly - DLR - I just don’t care 
