Train type and train weight estimation from CIF Schedule

[Александр Цыплаков]

Good day all! 

(sorry for the wall of text)
I am trying to analyze traffic data, specifically trying to assign some train weight to every train movement in the Train Movement data. 

I do that by using Activations to match train_id with train_uid, then finding corresponding train_uid in the CIF_Schedule (or VSTP schedule for VSTP entries) - and then pulling from CIF_Schedule fields CIF_Timing_load and CIF_power_type. 

Assigning train_uid seems to be happening without much issues - some rows of TM that I can't match to any Activation messages, but not much (less then 1%).
Consequent join with CIF_Schedule and VSTP also goes pretty well - again, some rows I can't match - but overwhelming majority matches okay. 

However, what I end up with are rows, that have valid train_uids, have valid matches with CIF_Schedule / VSTP - and have valid CIF_power_type values. 

But they have no CIF_Timing_Load values. As in NULL
Very large percentage, close to 50%

Is there something that I am missing / doing incorrectly here?

For example:
the CIF_Schedule that I am using is based on me taking 1 full schedule for a specific day (1st of the month) - and then adding all schedulle corrections for consequent days.

If there is a row in additions that is a modification of the schedule - then this row from the additions table overwrittes the original row (for that particular day) completely - for all parameters.

Is it possible, that by doing that I am actually losing some data? That correction row in daily schedule adjustments are only meant to correct parameters of the original schedule entry that are non-null - and I am effectivel overwriting nulls over reasonable values?

Best regards,
Alex

[Matthew Burdett]

Hi

I'm pretty sure timing load has no relation whatsoever to the trains actual weight. Eg track machines always use 715 tonnes regardless of type. A cif schedule may be shown 600 tonnes where the train runs one day with 18 wagons and the next with 16, the to the same schedule

Timing load is not always specified, my latest cif update has a decent number of class 6 trains missing a timing load. 

I did push a Data Want on the rail data marketplace for wheel impact load detector API, hopefully that may come one day as it has vehicle weights.

--
You received this message because you are subscribed to the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openraildata-t...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/openraildata-talk/89c26ed4-4525-4796-9348-7192a992140en%40googlegroups.com.

[Александр Цыплаков]

I was hoping that timing load  - specifically for rail freight (which is my primary interest)  -  was at least directionally close to weight 
(for passenger - if I understand the logic correctly - it designated train type rather then weight. So getting to train weight would be an exercise of assumptions in regards to ridership + bare train weight anyway) 

But if it is largely uncorrelated with what freight train actually weights, then I might have to review my whole approach to this. 
(maybe start a table of defaults for corridor+traffic_type combinations - and see if it would make a more consistent output)
Having train counts - and not having GTMs feels extremely ...limiting.
(God forbid one asks for a way to calculate car-miles and average train sizes from train data...) 

Fingers crossed for the load detector data, it would be lovely.

Best regards,
Alex

среда, 15 апреля 2026 г. в 14:18:24 UTC+1, Matthew Burdett:

[Peter Hicks]

Hi Alex

On Wednesday, 15 April 2026 at 13:51, Александр Цыплаков <deli...@gmail.com> wrote:

I am trying to analyze traffic data, specifically trying to assign some train weight to every train movement in the Train Movement data.

I do that by using Activations to match train_id with train_uid, then finding corresponding train_uid in the CIF_Schedule (or VSTP schedule for VSTP entries) - and then pulling from CIF_Schedule fields CIF_Timing_load and CIF_power_type.

As has been pointed out, the timing load and power type don't reflect the rolling stock actually used on the service - or in the case of freight, the loading status of wagons on the train.  Both of those are just identifiers for the set of sectional running times used for the train.  It would be entirely possible to run a slower and heavier train (within limits) in a faster path - the train would just lose time en-route.  Or you could run a faster and lighter train and it wouldn't hit its maximum capability - for example, Class 80x trains running in paths timed for an HST and arriving at stations several minutes early due to their superior acceleration capabilities.

It sounds like you might be better off using the passenger train consist data.  Data is available for most passenger operators (but not all) and you can probably fill in the gaps with sensible defaults.  For example, most London Overground services are 5-car, with some 10-car services on the Weaver line.  For that, you could work out the 10-car services using Darwin, if the train length if specified.

The advantage of using the consist data is that you'll have a maximum of one 'final' consist message per train, showing the origin and destination location and any changes en-route.  That might mean you don't need to rely on the schedule/TRUST data so much, only for where there are gaps.

Peter

[Александр Цыплаков]

Thanks you for your reply, Peter! 

In hindsight it is quite clear, that Timing load couldn't have been a precise description of the actual train weight - being a characteristic of the schedule and not of the particular move - so naturally, when life happens, an actual consist can be different from what was planned. 
Just proves time and again, how much domain knowledge is required to properly interpret this data correctly. It's been almost a year of me tinkering with it, and I keep finding new ways to misinterpret it :)

As I've mentioned, my interested is mostly focused on freight. 
So for passenger my attempts to calculate train weight were mostly about preserving available information for any potential future use, rather then practical. Seriously working through consist information from TOCs would be a significant overkill for my purposes right now - but useful knowledge for the future.

For freight, I guess I will have to introduce a two step process
- initially I will be pre-generating a table of train weights for specific train-date-segment combos based on Timing Loads  (tacitly split into tare weights and net weights based on some assumptions)  
- and then doing a second pass, where I would attempt to plug gaps (where Timing loads are completely  NULL) or would attempt to correct weights (like zeroing out net weights on links+directions, where freight trains are likely moving as empty) 

Best regards,
Alex

среда, 15 апреля 2026 г. в 17:41:45 UTC+1, Peter Hicks: