Passenger train consists as Open Data

[Robski]

I have a question, maybe it should be in it's own thread entitled 'phantom trains?'.

This morning I was looking at the live maps around Cardiff Central on both Traksy and OpenTrainTimes, and spotted a train on both with headcode 5N11 heading in from the east. I watched it stop briefly at P4 at CDF and then disappear into Canton depot. While I was watching it I was also trying to find out what it was. OTT said it didn't know, Traksy, RTT and live.rail-record all gave me a choice of 8 5N11's, all at least 100 miles away, and there aren't any matching VSTPs.

How can this be? And is there some other place I could have looked for the answer?

2N11 (197106) failed at Pye Corner, returned to depot as 5N11. Schedules don't always exist particularly for such last minute moves, e.g. thunderbird locos don't have schedules uploaded.

 

[chrisjo]

2N11 (197106) failed at Pye Corner, returned to depot as 5N11. Schedules don't always exist particularly for such last minute moves, e.g. thunderbird locos don't have schedules uploaded.

Thank you. Should I have been able to figure this out for myself, apart from by deduction?

 

[Robski]

Thank you. Should I have been able to figure this out for myself, apart from by deduction?

Class 5 moves often share the same headcode/train id "remainder" (I don't know how else to call the last 3 digits) with the service they are associated to, so it's often worth checking for an equivalent class 1 or 2 schedule in the area if you can't find a schedule for a given class 5 move - if that service has been (part-)cancelled then that's a tell-tale sign.

("class" refers to the first digit of the headcode/train id, roughly corresponding to the train category and priority - class 1 is express passenger/parcels, 2 is ordinary passenger etc., it's a bit more nuanced than this but hopefully this is enough to clarify what I mean)

 

[chrisjo]

...hopefully this is enough to clarify what I mean)

Perfectly clear. That's what I meant by deduction. Thanks again.

 

[JAWZ]

Hiya - I'm trying to make sense of a bunch of allocation messages for today's GW 1L16 service (Carmarthen - Paddington). I've got no less than six messages in the audit log, and two different diagram numbers, so it's doing my head in a bit

Can anyone verify that my understanding is correct, or correct me if I'm wrong? Here's the message sequence:

10/11 23:32 800027 NP117
11/11 00:12 800027 NP117
11/11 02:42 800036 NP117
11/11 05:07 800032 NP101
11/11 05:12 800026 NP117
11/11 05:17 800017 NP101

How I'm reading this is that 800027 was initially allocated to this service late last night, then again about 40 minutes later. Then it was replaced by 800036 at 02:42.

800032 was added as a second unit at 05:07, then a few minutes later 800036 was replaced by 800026.

Finally, at 05:17 800032 was replaced by 800017, meaning that the final consist was 800017 + 800026.

Does that make sense? And does anyone know if those two units were indeed on 1L16 today?

 

[1D54]

026 and 017 did the 10:22 Swansea - Padd. Train was partially cancelled between Carmarthen and Swansea due to the late arrival of the incoming service.

 

[JAWZ]

026 and 017 did the 10:22 Swansea - Padd. Train was partially cancelled between Carmarthen and Swansea due to the late arrival of the incoming service.

Aha, so the theory is right then, the two diagrams associated with the service indicates two units assigned, and the last two allocations for each of these diagrams is the formation that ran. Excellent, thanks!

 

[1D54]

I just typed 1L16 into the menu on RTT and everything else was there.

 

[MrJeeves]

Aha, so the theory is right then, the two diagrams associated with the service indicates two units assigned, and the last two allocations for each of these diagrams is the formation that ran.

I wouldn't have ultimate faith in the "diagram number" in the data, as I'm sure diagrams fall apart quite quickly in disruption (with this being a good example!).

The main point of the data is what train(s) operate a service over anything else like diagrams.

 

[chrisjo]

and the last two allocations for each of these diagrams is the formation that ran

Maybe! GWR have history of sending out units different from the last ones assigned. I've seen this at CDF on a number (maybe between four and six without checking my observations) of occasions over the last couple of years. It no longer surprises me.

 

[Tom]

Aha, so the theory is right then, the two diagrams associated with the service indicates two units assigned, and the last two allocations for each of these diagrams is the formation that ran. Excellent, thanks!

Each Gemini message for a service completely replaces the previous message representing allocations for that service, and you should never need to compound messages to get a correct allocation. Equally diagram numbers aren’t entirely to be trusted, either, they’re “correct” only to the degree to chain a unit’s services together as part of the day - but equally you could do that by just tracking the unit. A unit can operate one or more diagrams each day.

 

[JAWZ]

Ah, that’s interesting - so the last allocation message should include both of the units that were allocated to 1L16… I’ll have to dig through the audit log and look at this further, thanks!

 

[MrJeeves]

Ah, that’s interesting - so the last allocation message should include both of the units that were allocated to 1L16… I’ll have to dig through the audit log and look at this further, thanks!

You should have seen the equivalent of this, however you are storing the data:

from location	from date time	to location	to date time	resource group numbers	diagram number	diagram date	deleted at	created at
BRSTPWY	11/11/25 11:55	PADTON	11/11/25 13:11	['800017', '800026']	NP101	11/11/25		11/11/25 05:17
CRDFCEN	11/11/25 11:18	BRSTPWY	11/11/25 11:53	['800017', '800026']	NP101	11/11/25		11/11/25 05:17
SWANSEA	11/11/25 10:22	CRDFCEN	11/11/25 11:15	['800017', '800026']	NP101	11/11/25		11/11/25 05:17
BRSTPWY	11/11/25 11:55	PADTON	11/11/25 13:11	['800026', '800032']	NP117	11/11/25	11/11/25 05:17	11/11/25 05:12
CRDFCEN	11/11/25 11:18	BRSTPWY	11/11/25 11:53	['800026', '800032']	NP117	11/11/25	11/11/25 05:17	11/11/25 05:12
SWANSEA	11/11/25 10:22	CRDFCEN	11/11/25 11:15	['800026', '800032']	NP117	11/11/25	11/11/25 05:17	11/11/25 05:12
BRSTPWY	11/11/25 11:55	PADTON	11/11/25 13:11	['800032']	NP101	11/11/25	11/11/25 05:12	11/11/25 05:07
CRDFCEN	11/11/25 11:18	BRSTPWY	11/11/25 11:53	['800032']	NP101	11/11/25	11/11/25 05:12	11/11/25 05:07
SWANSEA	11/11/25 10:22	CRDFCEN	11/11/25 11:15	['800032']	NP101	11/11/25	11/11/25 05:12	11/11/25 05:07
BRSTPWY	11/11/25 11:55	PADTON	11/11/25 13:11	['800032', '800036']	NP101	11/11/25	11/11/25 05:07	11/11/25 02:42
CRDFCEN	11/11/25 11:18	BRSTPWY	11/11/25 11:53	['800032', '800036']	NP101	11/11/25	11/11/25 05:07	11/11/25 02:42
SWANSEA	11/11/25 10:22	CRDFCEN	11/11/25 11:15	['800032', '800036']	NP101	11/11/25	11/11/25 05:07	11/11/25 02:42
CMTHN	11/11/25 09:21	SWANSEA	11/11/25 10:07	['800036']	NP117	11/11/25	11/11/25 05:07	11/11/25 02:42
BRSTPWY	11/11/25 11:55	PADTON	11/11/25 13:11	['800027', '800032']	NP117	11/11/25	11/11/25 02:42	11/11/25 00:12
CRDFCEN	11/11/25 11:18	BRSTPWY	11/11/25 11:53	['800027', '800032']	NP117	11/11/25	11/11/25 02:42	11/11/25 00:12
SWANSEA	11/11/25 10:22	CRDFCEN	11/11/25 11:15	['800027', '800032']	NP117	11/11/25	11/11/25 02:42	11/11/25 00:12
CMTHN	11/11/25 09:21	SWANSEA	11/11/25 10:07	['800027']	NP117	11/11/25	11/11/25 02:42	11/11/25 00:12
BRSTPWY	11/11/25 11:55	PADTON	11/11/25 13:11	['800027', '800032']	NP117	11/11/25	11/11/25 00:12	10/11/25 23:32
CRDFCEN	11/11/25 11:18	BRSTPWY	11/11/25 11:53	['800027', '800032']	NP117	11/11/25	11/11/25 00:12	10/11/25 23:32
SWANSEA	11/11/25 10:22	CRDFCEN	11/11/25 11:15	['800027', '800032']	NP117	11/11/25	11/11/25 00:12	10/11/25 23:32
CMTHN	11/11/25 09:21	SWANSEA	11/11/25 10:07	['800027']	NP117	11/11/25	11/11/25 00:12	10/11/25 23:32

 

[JAWZ]

Excellent! That looks like the six messages I got, yes - I’m not handling the multiple resource groups correctly, but the data tallies with what’s in my logs.

That’s been really helpful, thanks !

 

[Welshguy1048]

Thank you. Should I have been able to figure this out for myself, apart from by deduction?

deleted

 

[trainmania100]

I don't believe RTT does anything like this. I also can't see any general issues with the Gemini feed on this date.

View attachment 191778


Raileasy saw allocations set for NL26 on (Y23523) 3A07, Y23252 (1D29) and Y23661 (5D29).

View attachment 191777

For the sake of making sure there wasn't an issue interpreting the data, there are no results for P00075/1A39 in the feed that day.

View attachment 191779

All of my 91 allocations today are complete, so I'm guessing this was fixed yesterday with the 1MB message limit increase on the RDM platform. Would explain it as the 91s did have a lot of defect messages

 

[MrJeeves]

All of my 91 allocations today are complete, so I'm guessing this was fixed yesterday with the 1MB message limit increase on the RDM platform. Would explain it as the 91s did have a lot of defect messages

I agree, that would explain the issue perfectly.

 

[MatthewE707]

Is there a puclicly available source which shows the allocations of services pre-covid?

 

[trainmania100]

No allocations received for over 6 hours as of 06:30 this morning, could be some missing gen today. (Checked my site against RTT so not just rail data marketplace).

 

[Tom]

Using RTT as a comparator is not your best bet for some operators as RTT does get some operators from the RDM feed. Most operators it does not, but some it does.

 

[milooo]

No allocations received for over 6 hours as of 06:30 this morning, could be some missing gen today. (Checked my site against RTT so not just rail data marketplace).

Traksy is also missing some allocations

 

[kemal]

Traksy is also missing some allocations

Lots of southern train allocations missing today. Hopefully, it will be back to normal tomorrow if possible.

 

[MrJeeves]

There was an issue with the RDM datafeed between about 01:15 until around 09:30. The feed resumed transmitting new messages from there, but many allocations for the day were lost.

Shouldn't affect tomorrow.

 

[takno]

Traksy is also missing some allocations

We get all our allocations from the Gemini feed on Rail Data Marketplace, so we'd expect to have the same lack of data

 

[matt]

Reopened for @trainmania100

 

[trainmania100]

Thankyou
I notice that in the feed, many assets (such as an example 377/1) are given a fleet of a different subclass, Ie 377101 is in the fleet group of 377/4.

I notice this with some 158s as well.

Does anyone know if there's a particular operational reason for this or if it's likely just a data mistake?

 

[CR165022]

Could it be because there's little to no difference mechanically and so they're all counted as one subclass to keep it simple? I believe that's why the 158/7s and 158/8s are classed as 158/0s, because there's no difference, and the /8s only exist because they ran out of 158/7 numbers (Excluding the Perkins units of course). Same with other subclasses that carry over like the 450/1s

 

[trainmania100]

Could it be because there's little to no difference mechanically and so they're all counted as one subclass to keep it simple? I believe that's why the 158/7s and 158/8s are classed as 158/0s, because there's no difference, and the /8s only exist because they ran out of 158/7 numbers (Excluding the Perkins units of course). Same with other subclasses that carry over like the 450/1s

It's possible, but it's worth mentioning that southeasterns 377/1s are designated as such, while southerns 377/1s are put into a 377/4 fleet.

Guessing the easiest thing to do would be to chop the last 2 digits off the unit and stick a slash before the third.

Over a year of data and it's something I've only just noticed :blush:

 

[Tom]

As I've said before the feed is somewhat full of stuff that doesn't always make sense. It might be flat out wrong, it might be a typo, it might be correct but for non-obvious reasons.

Guessing the easiest thing to do would be to chop the last 2 digits off the unit and stick a slash before the third.

That feels distinctly wrong when you consider fleets such as 450s, there is no difference between 450001-450099 and 450100-450127...

 

[mavsk]

I'm not sure exactly where the data is derived from, however I know the Southern 377/1s and 377/4s are in the same pool for diagramming so it may be that's what it's indicating rather than necessarily the unit's actual subclass?

There are also other exceptions where the fourth digit doesn't match the actual subclass - from memory, the Class 442s were actually classified as 442/1 in the Rolling Stock Library when they were with Southern/GX but were still numbered 4424xx.