Movement Cancellation - canx_type and canx_reason_code

[Andrew Powell]

Hi sorry of all the questions.

I am trying to understand the Movement Cancellation message and the terms uses.  I have read the wiki below but still have questions

http://nrodwiki.rockshore.net/index.php/Train_Cancellation

1. canx_type, can I confirm what these mean

ON CALL = What does this mean and what circumstances would this appear in?

AT ORIGIN = This means it was cancelled before it started

EN ROUTE = Not really sure what this would be used for an a circumstance?

OUT OF PLAN = Not sure what this means either, is it when the train has a problem?

2. canx_reason_code, There are lots of these, which ones would it be set to if the train was cancelled immediately. 

e..g.

I believe many trains are activated but immediately cancelled after they have been activated. These were never meant to run but there to secure the route or some such approach.

Thanks for your help

Andrew

[Peter Hicks]

Hi Andrew

'On Call' is when a scheduled cancellation is called.  So, if an activation comes in for a schedule with STP indicator 'C', it'll be immediately cancelled with code 'PD' - planned cancellation.  It's probably not necessary nowadays, and I believe it was used in British Rail days for some kind of business reporting process.

'At Origin' means the train was cancelled at its origin location.  This may happen before, at or after the train was scheduled to depart.

'En Route' means the train was cancelled en-route, i.e. after it started, but before it terminated at its booked location

'Out of Plan' means the train was cancelled at a location not in the train plan.  For example, it could have been diverted off its booked route and then cancelled, or it may have been cancelled between two locations in the schedule.

Peter

--
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 post to this group, send email to openrail...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Powell]

Thanks Peter :)

[Andrew Powell]

Hi Peter

At the moment I am trying to get all the head codes for a day, sounds easy doesn't it!!

The current problem I have come across is that in this case there are 3 head codes(train_ids with the same head code) as 2 others were added as VSTP ones which I would presume overwrite the original one.  I then look in the movement cancellation data as the short term ones are cancelled later one. 

So I cant figure out what is going on and which one to return.

I was wondering if you would be able to understand this one and have knowledge of what may have happened. I feel it would be great to have a better understanding of how this would have worked there and then as find it hard to understand just looking at the data. I have included a screenshot of the activations and the cancellations for this particular entry

The cancellations

I want to return the correct row and then use that to map to the schedule and movement data but with the 3 I just get confused

I can raise this as a new question if needs be, but know your the pro at this stuff

Many thanks

Andrew

On Friday, 13 November 2015 09:37:13 UTC, Peter Hicks wrote:

[Tom Cairns]

By the looks of it from the rows you’ve highlighted – the two VSTP schedules are additions to and not in replacement of the original CIF schedule (the STP indicator being N). You haven’t included the service UID (also in the activation message) but my assumption would be that. 

Tom

[Andrew Powell]

Hi Tom

Ok here is the missing bit, seems to have put train_id in twice

So your saying its like an alteration to the planned route as its is moving?

Thanks

Andrew

[Tom Cairns]

Hi Andrew

So to me it looks like what has happened was both UID 38136 and 38138 were added to the system by the VSTP process. I cannot say for sure without looking their contents up what their intentions were – but as far as they are concerned they are different services to H24161 – the fact they have the same reporting number is neither here nor there really. It seems probable that they were intended to replace H24161 but as I say, their STP indicator is N and they have different service UIDs (which is what we should be using to compare these things), so their relation as far as the upstream systems are concerned are close to nil. While they are active and not cancelled, I’d personally consider them as all services that may potentially physically exist (even if they have near identical schedules)… 

You can have multiple headcode/reporting number on a given day in a given area – it’s generally never the case that you have the same reporting number in the same area at the same time but it isn’t unheard of. If you have two schedules running at identical times with the identical reporting number at identical locations, in this case 3S40, then TRUST itself won’t report on it normally IIRC (have seen it happen once but there were odd things going on that day anyway).

In this situation, the assumption I’d take is that as schedules 38136 and 38138 were cancelled then they should be ignored as potential errors… (although I’d expect them to be coded as PJ to be honest). As I say, can’t say for sure without delving into the data and how my systems interpreted it (don’t have access from here), but that’s what my assessment would be from what you’ve said

Tom

[Andrew Powell]

Hi Tom

Thanks a nice helpful description; I will go with that then.

Greatly appreciated

Andrew

[Andrew Powell]

Hi Tom

Feel stupid to ask all these questions but another one has arisen concerning cancellation and activation messages.

The previous answer helped a lot I feel I understand that somewhat better, small steps :)

I am looking at the train_id = 234R72CT30, I have tried to put together a visual path of what I am seeing in the image.

1. I can follow the train until it get to the last  movement point at 17:46, at this point the train had been cancelled the once at 16:01 and the reactivated at 16:26 so it can head on its journey for 16:35

Questions:

The train doesn't seem to get to the end destination, the last one should be 18:58 looking at the schedule data. 

But the only cancellation that occurs next is the one at 20:20 which is way paste the destination time. (is this just a late cancellation!?)

What has happened to this one and how come there are the other activation's and cancellations so close together. why would this happen?

It says the train is at the same stanox 21415

Thanks Again

Andrew

On Friday, 13 November 2015 12:00:46 UTC, Tom Cairns wrote:

[Peter Hicks]

Hi Andrew

Cancellations aren't necessarily input in real-time.  They can be, but there's no requirement for them to be - they just need to be right at some time afterwards for Delay Attribution purposes.

From a passenger perspective, Darwin is the best source of train movement data.  Yes, it has its inaccuracies (whose system doesn't?), but more TOCs input data in real-time more often than they do TRUST in real-time.

Peter