Dividing train darwin schedule query (2 x DT elements?)
109 views
Skip to first unread message
Lee Fortnam
Jul 10, 2016, 3:30:45 AM7/10/16
to A gathering place for the Open Rail Data community
Good Morning all,
I am hoping you might be able to help me out with a query and understanding of a schedule update received overnight. Also, I am new to the Darwin service and only just getting to grips with the data structure etc so will apologise for any newbie style questions or assumptions.
The train in question is the 19:02 from VIC to BOG (with a portion also going to PMH).
Below is the xml of the schedule update received (hopefully the formatting will not get messed up), questions are below the XML:
<?xml version="1.0" encoding="UTF-8"?>
<Pport
xmlns:ns2="http://www.thalesgroup.com/rtti/PushPort/Schedules/v1" ts="2016-07-10T04:24:59.6537857+01:00" version="12.0">
<uR requestID="AM02986904" requestSource="AM02" updateOrigin="CIS">
<schedule rid="201607093588254" ssd="2016-07-09" toc="SN" trainCat="XX" trainId="1C44" uid="W70413">
<ns2_OR act="TB" ptd="19:02" tpl="VICTRIC" wtd="19:02"/>
<ns2_PP tpl="BATRSPJ" wtp="19:05"/>
<ns2_PP tpl="BATRSPK" wtp="19:05:50"/>
<ns2_PP tpl="POUPRTJ" wtp="19:06:42"/>
<ns2_IP act="T " pta="19:08" ptd="19:08" tpl="CLPHMJC" wta="19:07:30" wtd="19:08:30"/>
<ns2_PP tpl="WANDCMN" wtp="19:10:30"/>
<ns2_PP tpl="BALHAM" wtp="19:11"/>
<ns2_PP tpl="BALHJN" wtp="19:12"/>
<ns2_PP tpl="STRENJN" wtp="19:12:30"/>
<ns2_PP tpl="STRHCOM" wtp="19:13:04"/>
<ns2_PP tpl="NORBURY" wtp="19:13:47"/>
<ns2_PP tpl="THTH" wtp="19:14:50"/>
<ns2_PP tpl="SELHRST" wtp="19:15:30"/>
<ns2_PP tpl="WNDMLBJ" wtp="19:16"/>
<ns2_IP act="T " pta="19:17" ptd="19:18" tpl="ECROYDN" wta="19:17" wtd="19:18"/>
<ns2_PP tpl="SCROYDN" wtp="19:19:16"/>
<ns2_PP tpl="PURLEYO" wtp="19:20:33"/>
<ns2_PP tpl="PURLEY" wtp="19:21:30"/>
<ns2_PP tpl="SNSTJN" wtp="19:22:30"/>
<ns2_PP tpl="COLSDNS" wtp="19:23:53"/>
<ns2_PP tpl="MERSTHM" wtp="19:27:27"/>
<ns2_PP tpl="REDH483" wtp="19:28:30"/>
<ns2_IP act="T " pta="19:29" ptd="19:30" tpl="REDHILL" wta="19:29" wtd="19:30"/>
<ns2_PP tpl="EARLSWD" wtp="19:32"/>
<ns2_PP tpl="SALFDS" wtp="19:33:45"/>
<ns2_IP act="T " pta="19:36" ptd="19:36" tpl="HORLEY" wta="19:35:30" wtd="19:36"/>
<ns2_IP act="T " pta="19:38" ptd="19:39" tpl="GTWK" wta="19:38" wtd="19:39:30"/>
<ns2_PP tpl="TNSLYGJ" wtp="19:40:28"/>
<ns2_IP act="T " pta="19:44" ptd="19:44" tpl="THBDGS" wta="19:43:30" wtd="19:44:30"/>
<ns2_IP act="T " pta="19:48" ptd="19:48" tpl="CRAWLEY" wta="19:47:30" wtd="19:48"/>
<ns2_PP tpl="IFIELD" wtp="19:49:20"/>
<ns2_PP tpl="FAYGATE" wtp="19:52:57"/>
<ns2_PP tpl="LHVN" wtp="19:55:01"/>
<ns2_IP act="T " pta="19:56" ptd="20:00" tpl="HORSHAM" wta="19:56" wtd="20:00"/>
<ns2_PP can="true" tpl="CHRSTSH" wtp="20:02:42"/>
<ns2_IP act="T " pta="20:07" ptd="20:07" tpl="BILSHST" wta="20:07:30" wtd="20:07:30"/>
<ns2_IP act="T " pta="20:12" ptd="20:12" tpl="PULBRO" wta="20:12" wtd="20:12"/>
<ns2_IP act="T " can="true" pta="20:12" ptd="20:13" tpl="AMLY" wta="20:12:30" wtd="20:13"/>
<ns2_PP tpl="AMLY" wtp="20:13"/>
<ns2_IP act="T " pta="20:13" ptd="20:14" tpl="ARUNDEL" wta="20:13:30" wtd="20:14"/>
<ns2_IP act="T " pta="20:23" ptd="20:23" rdelay="-8" tpl="FORD" wta="20:23" wtd="20:23"/>
<ns2_PP can="true" tpl="AMLY" wtp="20:16:12"/>
<ns2_IP act="T " pta="20:27" ptd="20:27" rdelay="-8" tpl="BRHM" wta="20:26:30" wtd="20:27:30"/>
<ns2_PP can="true" tpl="ARUNDEL" wtp="20:19:31"/>
<ns2_DT act="TF" planAct="T " pta="20:28" ptd="20:28" rdelay="-8" tpl="BOGNORR" wta="20:28" wtd="20:28:30"/>
<ns2_PP can="true" tpl="ARUNDLJ" wtp="20:21:30"/>
<ns2_PP can="true" rdelay="-8" tpl="BRHM" wtp="20:31:41"/>
<ns2_IP act="T " can="true" pta="20:35" ptd="20:35" rdelay="-8" tpl="CHCHSTR" wta="20:34:30" wtd="20:35:30"/>
<ns2_PP can="true" rdelay="-8" tpl="FSHBORN" wtp="20:37:01"/>
<ns2_PP can="true" rdelay="-8" tpl="BOSHAM" wtp="20:38:23"/>
<ns2_PP can="true" rdelay="-8" tpl="NUTBORN" wtp="20:39:46"/>
<ns2_PP can="true" rdelay="-8" tpl="SBOURNE" wtp="20:41:40"/>
<ns2_PP can="true" rdelay="-8" tpl="EMSWTH" wtp="20:42:30"/>
<ns2_PP can="true" rdelay="-8" tpl="WRBLNGT" wtp="20:44:18"/>
<ns2_IP act="T " can="true" pta="20:46" ptd="20:46" rdelay="-8" tpl="HAVANT" wta="20:45:30" wtd="20:46:30"/>
<ns2_PP can="true" rdelay="-8" tpl="BDHMPTN" wtp="20:49:21"/>
<ns2_PP can="true" rdelay="-8" tpl="FRLNGTJ" wtp="20:50:30"/>
<ns2_PP can="true" rdelay="-8" tpl="PCRKJN" wtp="20:51"/>
<ns2_PP can="true" rdelay="-8" tpl="HILSEA" wtp="20:51:25"/>
<ns2_PP can="true" rdelay="-8" tpl="FRATTNE" wtp="20:53:30"/>
<ns2_IP act="T " can="true" pta="20:55" ptd="20:55" rdelay="-8" tpl="FRATTON" wta="20:54:30" wtd="20:55:30"/>
<ns2_PP can="true" rdelay="-8" tpl="BLFRJN" wtp="20:57:30"/>
<ns2_IP act="T " can="true" pta="20:58" ptd="20:59" rdelay="-8" tpl="PSEA" wta="20:58" wtd="20:59"/>
<ns2_DT act="TF" can="true" pta="21:03" rdelay="-8" tpl="PHBR" wta="21:03"/>
<ns2_cancelReason>108</ns2_cancelReason>
</schedule>
</uR>
</Pport>
Questions
1. This appears to have 2 ns_2DT elements (please note I have replace the : in the ns2 elements as my script does not like them), why are their 2 DT elements, the corresponding train has an rid of 201607093604839 which is just the Horsham to Bognor Regis part.
2. This train can be seen here on realtime trains - http://www.realtimetrains.co.uk/train/W70413/2016/07/09, there is the station AMLY at 20:12 that does not appear in the RTT site, is there a reason for this and is it correct or should it be shown but just cancelled?
3. The rDelay elements, from my understanding this is typically when a train gets redirected and then rejoins its route but with a delay that needs to be added to the times, however, this would appear to be a negative figure so should the time be taken OFF the times?
4. This update was received at 4:25 this morning, well after the train would have completed its run, is there a reason for this, should any data received UP to this point be discarded and this replace it as gospel?
Many Thanks,
Lee
Matt A
Jul 10, 2016, 5:09:16 AM7/10/16
to A gathering place for the Open Rail Data community
1. The original terminating location of PHBR is marked as cancelled. There can only be one non-cancelled terminating location in the journey. In this case, the train is cancelled after BOGNORR, so that becomes the new terminating location. The cancelled locations are retained in the message so someone standing on the platform at PSEA (for example) knows that this particular service is now cancelled as far as they're concerned.
2. AMLY was originally a passenger calling point on this journey, however at 19:09 it was turned into a passing point where the train would not stop. The passenger calling point has been cancelled. Both instances of this location were not in the CIF and were added, and then cancelled, by a CIS system. I don't know all of the data sources for RTT but I assume it does not get a feed directly from the TOCs like Darwin does. The correct function would probably be to show it as cancelled since it's been, very briefly, shown to the public as a calling point.
3. Correct - it's possible to reroute a train via a shorter route, and if you do then you get negative rDelay. Not sure what they were doing here mind you...
4. I think this is because the train remained "active" as it never terminated properly (i.e never got to BOGNORR in Darwin) so when the timetable rebuild happened it made it into some CIS systems which have technically updated it since. Unless you're using Darwin for delay repay or interesting data things, once a train has terminated and you don't want to display it to people any more, you can probably bin further updates. Otherwise, just treat it like you would any other update.
Hope that helps,
Matt
2. AMLY was originally a passenger calling point on this journey, however at 19:09 it was turned into a passing point where the train would not stop. The passenger calling point has been cancelled. Both instances of this location were not in the CIF and were added, and then cancelled, by a CIS system. I don't know all of the data sources for RTT but I assume it does not get a feed directly from the TOCs like Darwin does. The correct function would probably be to show it as cancelled since it's been, very briefly, shown to the public as a calling point.
3. Correct - it's possible to reroute a train via a shorter route, and if you do then you get negative rDelay. Not sure what they were doing here mind you...
4. I think this is because the train remained "active" as it never terminated properly (i.e never got to BOGNORR in Darwin) so when the timetable rebuild happened it made it into some CIS systems which have technically updated it since. Unless you're using Darwin for delay repay or interesting data things, once a train has terminated and you don't want to display it to people any more, you can probably bin further updates. Otherwise, just treat it like you would any other update.
Hope that helps,
Matt
Lee Fortnam
Jul 10, 2016, 8:31:40 AM7/10/16
to A gathering place for the Open Rail Data community
Hi Matt,
Regards,
Really appreciate the quick reply!!!
Still not clear and so if I may delve a little deeper. The train with rid = 201607093588254 should have been for the VIC to BOG according to the schedule received at 2016-07-09 04:01:32. This was associated with a train 201607093604839 which according to its schedule received at the same time was for HRH to BOG. Neither of which are going to PMH. From my understanding, where there is a divide (type VV) the main one shows the originating station where the trains were together), the assoc one shows the station at which the train divides, HRH in this case and shows the portion of that train from the divide station to the end of its route.
| 201607093588246 is an example of a train from VIC to PMH which appears to be correct, with 201607093604837 as the corresponding half of the divide, this is what I would expect. The schedule shows the merged journey for this dividing train which surely is not correct as per your point below about it being cancelled at BOGNORR which is the one leg then there should be nothing in there about PHBR or PSEA etc? Is this an anomaly? The purpose of this is for Delay Repay calculations using Darwin data. |
Lee
Matt A
Jul 10, 2016, 12:14:29 PM7/10/16
to A gathering place for the Open Rail Data community
Hi Lee,
So looking at it I can't say for certain, but it looks like the information that went into Darwin about whichever service was to run didn't quite match up with how things ended up running.
201607093588254 was originally planned to run VIC -> PMH (you can see this when it first enters Darwin's timetable on Friday 8th.
On Saturday morning about 0359 it was updated to run VIC -> HRH, with HRH -> PMH cancelled.
On Saturday around 1905 it was updated again, it looks like to run the timetable of 201607093604839 (the associated train) from HRH to BOG as well.
Ultimately what ended up happening was ...839 (the associated train) ran it's path as it's own headcode. This means that ..254 (main train) looks delayed from HRH to BOG in Darwin, because it was a different train headcode (even if it was the same physical stock) that ran that bit of the journey.
Short answer, I would put this one down to an anomaly.
Long answer, the customer information systems at HRH and beyond were suppressing that train from the display so all a customer should have seen at the platform was a train going from HRH to BOG, which is what they would have expected to see, without it really mattering whether it was the original main service VIC->PMH rerouted to BOG or the original associated service HRH to BOG, while everyone on the original route from HRH -> BOG should still have seen a cancelled indication. So the CIS all ends up displaying correctly, but in terms of working out what actually happened it becomes a bit of a nightmare with the data.
And of course, most of that is conjecture, so it could be wrong. =)
Matt
So looking at it I can't say for certain, but it looks like the information that went into Darwin about whichever service was to run didn't quite match up with how things ended up running.
201607093588254 was originally planned to run VIC -> PMH (you can see this when it first enters Darwin's timetable on Friday 8th.
On Saturday morning about 0359 it was updated to run VIC -> HRH, with HRH -> PMH cancelled.
On Saturday around 1905 it was updated again, it looks like to run the timetable of 201607093604839 (the associated train) from HRH to BOG as well.
Ultimately what ended up happening was ...839 (the associated train) ran it's path as it's own headcode. This means that ..254 (main train) looks delayed from HRH to BOG in Darwin, because it was a different train headcode (even if it was the same physical stock) that ran that bit of the journey.
Short answer, I would put this one down to an anomaly.
Long answer, the customer information systems at HRH and beyond were suppressing that train from the display so all a customer should have seen at the platform was a train going from HRH to BOG, which is what they would have expected to see, without it really mattering whether it was the original main service VIC->PMH rerouted to BOG or the original associated service HRH to BOG, while everyone on the original route from HRH -> BOG should still have seen a cancelled indication. So the CIS all ends up displaying correctly, but in terms of working out what actually happened it becomes a bit of a nightmare with the data.
And of course, most of that is conjecture, so it could be wrong. =)
Matt
Lee Fortnam
Jul 11, 2016, 4:53:55 AM7/11/16
to A gathering place for the Open Rail Data community
Thanks Matt,
Think I will need to continue my investigation with retaining the individual updates so I can see the history of what happened to a certain rid.
Really appreciate your input over the weekend as it allowed me to move on in other areas for the project. Great support.
Thanks,
Lee
Lee Fortnam
Jul 11, 2016, 1:28:42 PM7/11/16
to A gathering place for the Open Rail Data community
Sorry, just thought, when you say a train has teminated, do you mean it has had a deactivation sent for it? If this is the case I can set a flag on receipt of this and ignore future updates as you say.
Thanks,
Lee
--
You received this message because you are subscribed to a topic in the Google Groups "A gathering place for the Open Rail Data community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openraildata-talk/4-PxYEQMQh4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openraildata-t...@googlegroups.com.
To post to this group, send email to openrail...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Matt A
Jul 11, 2016, 4:47:40 PM7/11/16
to A gathering place for the Open Rail Data community
By terminates/terminated, I mean has an arrival movement (TD/TRUST/CIS/Manual) at it's terminating location (destination).
Deactivation will normally follow about 30 minutes after a train terminates. If a train doesn't get an arrival at destination then it will eventually time out based on the arrival time at the destination plus a large-ish time window.
Trains can be activated again after they have deactivated.
Deactivation will normally follow about 30 minutes after a train terminates. If a train doesn't get an arrival at destination then it will eventually time out based on the arrival time at the destination plus a large-ish time window.
Trains can be activated again after they have deactivated.
Reply all
Reply to author
Forward
0 new messages