Train rid - 201710037101112
97 views
Skip to first unread message
Lee Fortnam
Oct 3, 2017, 3:41:51 PM10/3/17
to A gathering place for the Open Rail Data community
Hi All,
Starting to despair a little here as finding lots of what I understand to be inconsistencies in data or perhaps I am misunderstanding things so please help a man who is going slowly insane out a bit :-)
This train was between clacton and Liverpool Street this morning.
I first see this train in the digest file from 02:49 and then get updates and new schedules all the way up to 10:14.
The updates indicate that it is delayed by some considerable period and the schedule indicates it was cancelled all the way but there is no cancellation reason.
My question is this, should I trust the schedules more than the updates? if the schedule says it is cancelled but I get an update with dat and aat times should I trust the fact it is cancelled over the times and just show it as Cancelled.
Here is the schedule in the 10:14 file:
<?xml version="1.0" encoding="UTF-8"?>
<Pport
xmlns:ns2="http://www.thalesgroup.com/rtti/PushPort/Schedules/v1" ts="2017-10-03T10:14:22.5670206+01:00" version="12.0">
<uR requestID="0000000000017100" requestSource="at12" updateOrigin="CIS">
<schedule rid="201710037101112" ssd="2017-10-03" toc="LE" trainCat="XX" trainId="1N15" uid="G01112">
<ns2_OR act="TB" can="true" ptd="07:05" tpl="CLACTON" wtd="07:05"/>
<ns2_IP act="T " can="true" pta="07:13" ptd="07:13" tpl="THPLESK" wta="07:13" wtd="07:13:30"/>
<ns2_IP act="T " can="true" pta="07:23" ptd="07:24" tpl="WIVENHO" wta="07:23" wtd="07:24"/>
<ns2_PP can="true" tpl="CLCHHYT" wtp="07:27:30"/>
<ns2_PP can="true" tpl="CLCHEGJ" wtp="07:28"/>
<ns2_IP act="T " can="true" pta="07:32" ptd="07:33" tpl="CLCHSTR" wta="07:32" wtd="07:33"/>
<ns2_PP can="true" tpl="MRKSTEY" wtp="07:38:30"/>
<ns2_IP act="T " can="true" pta="07:43" ptd="07:43" tpl="KELVEDN" wta="07:42:30" wtd="07:43:30"/>
<ns2_IP act="T " can="true" pta="07:49" ptd="07:50" tpl="WITHAME" wta="07:48:30" wtd="07:50:30"/>
<ns2_IP act="T " can="true" pta="07:59" ptd="07:59" tpl="CHLMSFD" wta="07:58:30" wtd="07:59:30"/>
<ns2_IP act="T " can="true" pta="08:09" ptd="08:09" tpl="SHENFLD" wta="08:09" wtd="08:10"/>
<ns2_PP can="true" tpl="BRTWOOD" wtp="08:12"/>
<ns2_PP can="true" tpl="HRLDWOD" wtp="08:15"/>
<ns2_PP can="true" tpl="GIDEAPK" wtp="08:17"/>
<ns2_PP can="true" tpl="ROMFORD" wtp="08:17:30"/>
<ns2_PP can="true" tpl="CHDWLHT" wtp="08:19"/>
<ns2_PP can="true" tpl="GODMAYS" wtp="08:20"/>
<ns2_PP can="true" tpl="SVNKNGS" wtp="08:20:30"/>
<ns2_PP can="true" tpl="ILFORD" wtp="08:21:30"/>
<ns2_PP can="true" tpl="MANRPK" wtp="08:22"/>
<ns2_PP can="true" tpl="FRSTGTJ" wtp="08:23"/>
<ns2_PP can="true" tpl="FRSTGT" wtp="08:23:30"/>
<ns2_IP act="D " can="true" pta="08:25" tpl="STFD" wta="08:25" wtd="08:26:30"/>
<ns2_PP can="true" tpl="BOWJ" wtp="08:30"/>
<ns2_PP can="true" tpl="BTHNLGR" wtp="08:32"/>
<ns2_DT act="TF" can="true" pta="08:38" tpl="LIVST" wta="08:36"/>
</schedule>
</uR>
</Pport>
Here is an update also in the 10:14 file:
<?xml version="1.0" encoding="UTF-8"?>
<Pport
xmlns:ns3="http://www.thalesgroup.com/rtti/PushPort/Forecasts/v2" ts="2017-10-03T10:14:22.5670206+01:00" version="12.0">
<uR requestID="0000000000017100" requestSource="at12" updateOrigin="CIS">
<TS rid="201710037101112" ssd="2017-10-03" uid="G01112">
<ns3_Location ptd="07:05" tpl="CLACTON" wtd="07:05">
<ns3_dep at="07:05" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">2</ns3_plat>
</ns3_Location>
<ns3_Location pta="07:13" ptd="07:13" tpl="THPLESK" wta="07:13" wtd="07:13:30">
<ns3_arr at="07:12" src="TD"/>
<ns3_dep at="07:14" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location pta="07:23" ptd="07:24" tpl="WIVENHO" wta="07:23" wtd="07:24">
<ns3_arr at="07:23" src="TD"/>
<ns3_dep at="07:25" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="CLCHHYT" wtp="07:27:30">
<ns3_pass at="07:29" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="CLCHEGJ" wtp="07:28">
<ns3_pass at="07:30" src="TRUST" srcInst="Auto"/>
</ns3_Location>
<ns3_Location pta="07:32" ptd="07:33" tpl="CLCHSTR" wta="07:32" wtd="07:33">
<ns3_arr at="07:33" src="TD"/>
<ns3_dep at="07:34" src="TD"/>
<ns3_plat platsup="true">4</ns3_plat>
</ns3_Location>
<ns3_Location tpl="MRKSTEY" wtp="07:38:30">
<ns3_pass at="07:39" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location pta="07:43" ptd="07:43" tpl="KELVEDN" wta="07:42:30" wtd="07:43:30">
<ns3_arr at="07:44" src="TD"/>
<ns3_dep at="07:44" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location pta="07:49" ptd="07:50" tpl="WITHAME" wta="07:48:30" wtd="07:50:30">
<ns3_arr at="07:49" src="TD"/>
<ns3_dep at="07:49" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">2</ns3_plat>
</ns3_Location>
<ns3_Location pta="07:59" ptd="07:59" tpl="CHLMSFD" wta="07:58:30" wtd="07:59:30">
<ns3_arr at="08:00" src="TD"/>
<ns3_dep at="08:01" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location pta="08:09" ptd="08:09" tpl="SHENFLD" wta="08:09" wtd="08:10">
<ns3_arr at="08:12" src="TD"/>
<ns3_dep at="08:13" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">2</ns3_plat>
</ns3_Location>
<ns3_Location tpl="BRTWOOD" wtp="08:12">
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="HRLDWOD" wtp="08:15">
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="GIDEAPK" wtp="08:17">
<ns3_pass at="08:20" src="TRUST" srcInst="Auto"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="ROMFORD" wtp="08:17:30">
<ns3_pass at="08:20" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">2</ns3_plat>
</ns3_Location>
<ns3_Location tpl="CHDWLHT" wtp="08:19">
<ns3_pass at="08:22" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="GODMAYS" wtp="08:20">
<ns3_pass at="08:23" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="SVNKNGS" wtp="08:20:30">
<ns3_pass at="08:24" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="ILFORD" wtp="08:21:30">
<ns3_pass at="08:25" src="TD"/>
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">1</ns3_plat>
</ns3_Location>
<ns3_Location tpl="MANRPK" wtp="08:22">
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">3</ns3_plat>
</ns3_Location>
<ns3_Location tpl="FRSTGTJ" wtp="08:23">
<ns3_pass at="08:26" src="TD"/>
</ns3_Location>
<ns3_Location tpl="FRSTGT" wtp="08:23:30">
<ns3_plat cisPlatsup="true" conf="true" platsrc="A" platsup="true">3</ns3_plat>
</ns3_Location>
<ns3_Location pta="08:25" tpl="STFD" wta="08:25" wtd="08:26:30">
<ns3_arr at="08:30" src="TD"/>
<ns3_dep at="08:31" src="TD"/>
<ns3_plat conf="true" platsrc="A" platsup="true">9</ns3_plat>
</ns3_Location>
<ns3_Location tpl="BOWJ" wtp="08:30">
<ns3_pass at="08:33" src="TD"/>
</ns3_Location>
<ns3_Location tpl="BTHNLGR" wtp="08:32">
<ns3_pass at="08:42" src="TD"/>
</ns3_Location>
<ns3_Location pta="08:38" tpl="LIVST" wta="08:36">
<ns3_plat conf="true" platsrc="A" platsup="true">13</ns3_plat>
</ns3_Location>
</TS>
</uR>
</Pport>
Hoping you can assist as always.
Lee
Rail Delivery Group
Oct 4, 2017, 4:05:08 AM10/4/17
to A gathering place for the Open Rail Data community
Looking at the history for this schedule it appears no arrival report was received at Liverpool Street, the last report for it was passing Bethnal Green. This would explain why it went into the automatic 'delayed' state at 0852 (a train is automatically marked as delayed after a period of time (which I can't remember) if Darwin doesn't get an expected movement report for it based on its schedule - in this case the arrival movement at Liv St.).
From that point onwards the actions against this schedule were manually input and Darwin can only be as good as the information it receives (or to put it another way, bad information in results in bad information out!). In this case someone in Greater Anglia marked the train as cancelled @1014 (presumably to clear it off a board or their CIS screen) rather than marking it as arrived at destination (which was the appropriate action). This was a common action in the days before Darwin joined up the CIS as actions to 'manage' a local CIS had no effect elsewhere. This is obviously no longer true and staff were trained to understand that their actions now had a national impact so they couldn't use some of the shortcuts they'd been able to use in the past. As the train wasn't properly managed, it appears a couple of manual Trust movement reports were incorrectly associated with it - these were intended as movements of that train as empty rolling stock into sidings, at the end of the morning rush hour, and as it left the sidings at the beginning of the evening rush hour.
Note that reason codes are entirely optional and will only be placed against a schedule if a reason is known. If a reason isn't known (reasonably common) or, as in this case, someone was using the cancellation function to do something they shouldn't, then no reason code is possible. It is also perfectly possible for a cancelled train to move along the network producing movement reports as-if that train was running normally (if its headcode hasn't been updated). From Darwin's perspective a moving train is a moving train and it will report those movements. The assumption is the human element, which manages cancellation statuses, knows what it is doing and if a location (or the entire service) is marked as cancelled, regardless of movements, it is cancelled until advised otherwise
So in terms of what to believe, you should believe the schedule. There will always be errors such as this because of the manual nature of schedule changes, so any true analysis or usage has to try to recognise and filter out this kind of 'noise'.
Andrew
From that point onwards the actions against this schedule were manually input and Darwin can only be as good as the information it receives (or to put it another way, bad information in results in bad information out!). In this case someone in Greater Anglia marked the train as cancelled @1014 (presumably to clear it off a board or their CIS screen) rather than marking it as arrived at destination (which was the appropriate action). This was a common action in the days before Darwin joined up the CIS as actions to 'manage' a local CIS had no effect elsewhere. This is obviously no longer true and staff were trained to understand that their actions now had a national impact so they couldn't use some of the shortcuts they'd been able to use in the past. As the train wasn't properly managed, it appears a couple of manual Trust movement reports were incorrectly associated with it - these were intended as movements of that train as empty rolling stock into sidings, at the end of the morning rush hour, and as it left the sidings at the beginning of the evening rush hour.
Note that reason codes are entirely optional and will only be placed against a schedule if a reason is known. If a reason isn't known (reasonably common) or, as in this case, someone was using the cancellation function to do something they shouldn't, then no reason code is possible. It is also perfectly possible for a cancelled train to move along the network producing movement reports as-if that train was running normally (if its headcode hasn't been updated). From Darwin's perspective a moving train is a moving train and it will report those movements. The assumption is the human element, which manages cancellation statuses, knows what it is doing and if a location (or the entire service) is marked as cancelled, regardless of movements, it is cancelled until advised otherwise
So in terms of what to believe, you should believe the schedule. There will always be errors such as this because of the manual nature of schedule changes, so any true analysis or usage has to try to recognise and filter out this kind of 'noise'.
Andrew
Reply all
Reply to author
Forward
0 new messages