Train cancelled by a "mishap"

chessie · 2 May 2019

Couldnt help but notice Platform 3 at Chesterfield came into use yesterday lunchtime as the 1154 to Norwich was stuck in Platform 2, having looked at Real Time Trains this was caused by a "mishap", I have never seen this before so my question is what causes a mishap?

http://www.realtimetrains.co.uk/train/C60439/2019/05/01/advanced

RailUK Forums

_toommm_ · 2 May 2019

According to:

https://wiki.openraildata.com/index.php/Delay_Attribution_Guide

The cancellation code MY is caused by a coupler fault.

What you've got to remember is that RTT interprets the cancellation codes how the developer likes - for example, in the autumn, when theres excessive wheelslip caused by leaf fall, RTT shows the cancellation reason as 'because it's Autumn'.

chessie · 2 May 2019

Thanks for the response thought it might be something logical but couldnt fathom it

.

Greg Read · 3 May 2019

_toommm_ said:
According to:

https://wiki.openraildata.com/index.php/Delay_Attribution_Guide

The cancellation code MY is caused by a coupler fault.

What you've got to remember is that RTT interprets the cancellation codes how the developer likes - for example, in the autumn, when theres excessive wheelslip caused by leaf fall, RTT shows the cancellation reason as 'because it's Autumn'.

Run by a 10 year old then ?

pdeaves · 3 May 2019

Greg Read said:
Run by a 10 year old then ?

No, just someone who doesn't take a hobby too seriously (something that lots of people, in all hobbies/walks of life, would do well to emulate).

LAX54 · 3 May 2019

pdeaves said:
No, just someone who doesn't take a hobby too seriously (something that lots of people, in all hobbies/walks of life, would do well to emulate).

Agree with that, but then also some see RTT and Open Train as gospel and the information being put forward is 'official'

Bovverboy · 3 May 2019

Here's a good reason for a train being cancelled. The first westbound Chat Moss stopper of the day, 0528 ex-Manchester Victoria, has been cancelled regularly just recently, probably more than any other single scheduled journey on the route. I have sympathy for anyone who depends on it.

This morning it was cancelled 'due to a passenger being taken ill'. It subsequently departed Victoria at 0532 (only four minutes later than its normal time) and ran ECS to Lime Street, arriving at 0608, some twenty minutes prior its usual arrival time.

Passenger suddenly recovered?

headshot119 · 3 May 2019

Bovverboy said:
Here's a good reason for a train being cancelled. The first westbound Chat Moss stopper of the day, 0528 ex-Manchester Victoria, has been cancelled regularly just recently, probably more than any other single scheduled journey on the route. I have sympathy for anyone who depends on it.

This morning it was cancelled 'due to a passenger being taken ill'. It subsequently departed Victoria at 0532 (only four minutes later than its normal time) and ran ECS to Lime Street, arriving at 0608, some twenty minutes prior its usual arrival time.

Passenger suddenly recovered?

The cancellation reason will be down to the route cause of the issue. If the guard has been held up on the inbound working because of an ill passenger, then the cancellation goes down to that. But the driver could have taken it empty ready for a later working.

Don't put too much stock on what the open data sites tell you.

Bovverboy · 3 May 2019

headshot119 said:
The cancellation reason will be down to the route cause of the issue. If the guard has been held up on the inbound working because of an ill passenger, then the cancellation goes down to that. But the driver could have taken it empty ready for a later working.

I can't see how the guard could have been held up on an inbound working when there aren't any scheduled NT arrivals at Victoria prior to 0528.

headshot119 · 3 May 2019

Bovverboy said:
I can't see how the guard could have been held up on an inbound working when there aren't any scheduled NT arrivals at Victoria prior to 0528.

It was just one example. As I said Don't put too much stock on what the open data sites tell you.

bb21 · 3 May 2019

Bovverboy said:
I can't see how the guard could have been held up on an inbound working when there aren't any scheduled NT arrivals at Victoria prior to 0528.

Delay attribution is a whole field of its own. There are a handful of reasons I can give why that train may have been coded as it was.

I agree with other posters, don't put too much emphasis on what open data sites say. Unfortunately this is one area where unless you have done a job related to the field, you will not understand it, even if you read the Delay Attribution Guide cover to cover. Delay attribution is not intended to provide public information.

Bovverboy · 3 May 2019

bb21 said:
Delay attribution is a whole field of its own. There are a handful of reasons I can give why that train may have been coded as it was.

Perhaps you'd like to give them?

Bovverboy · 3 May 2019

bb21 said:
I agree with other posters, don't put too much emphasis on what open data sites say. Unfortunately this is one area where unless you have done a job related to the field, you will not understand it, even if you read the Delay Attribution Guide cover to cover. Delay attribution is not intended to provide public information.

What's the point in making it public then?

Spartacus · 3 May 2019

Bovverboy said:
Perhaps you'd like to give them?

First guess, espeically as it's first train of the day, might be that someone's got on after an all night sesh and promptly spewed their guts all over the place, lager, kebab and (as always) 'carrot' chunks everywhere. Clearly can't run in service in that condition, and platforms are needed at Man Vic so you get the cleaners on and they do their business while it's ECS to Lime Street. Passenger throwing up will usually go down to sickness, initially at the very least, though some TOCs prefer it to go down to disorder, though RTT sometimes doesn't reflect recodings.

If you want some more examples use your imagination.

ComUtoR · 3 May 2019

Bovverboy said:
What's the point in making it public then?

People want information on demand so it tends to get provided. Nobody seems to remember that there is context or that information is changed. The industry simply released the data they use. There is no translation to layman terms or any lay understanding, just 'open data' to help provide 'transparency'

It's a bit like 'open source' software. The code is laid bare for anyone to read to prove they aren't hiding anything and to help provide some form of transparency but in reality you still need to be literate in code to understand it. You can check all the html for this forum page if you wanted. Most browsers will show it but again, it is of little use to anyone who doesn't understand it.

Dr Hoo · 3 May 2019

As a general principle documents that have been ‘approved’ in accordance with the Network Code by the ORR, etc. are published in the general interests of transparency. A lot of other stuff - such as franchise documents - ar3 published by the DfT and other bodies as they relate to spending public money. If they weren’t published pro-actively people could ask under Freedom of Information anyway.

ComUtoR · 3 May 2019

Thanks Dr Hoo.

As an aside. I wonder what would happen if the reason for the delay wasn't given and both the TOC and NR stated that you needed a FOI Request (and its associated costs) to get the information. Sometimes I feel that telling people the reason for the delay just makes them more angry.

I had a passenger the other day asking for information that I just couldn't give him. Rather than accept the situation and deal with it, he just got more and more frustrated and angry.

bb21 · 4 May 2019

Bovverboy said:
Perhaps you'd like to give them?

Crew displacement, crew displacement due to something the previous day, stock being soiled (by blood or vomit for example) and possibly required cleaning at the other end, guard becoming unfit to continue depending on the nature of the incident, replacement crew needed to be sourced but only driver could be found, service recovery as per recovery policy, incorrect attribution, corrected attribution not being picked up by the open data feed...

As I haven't read the details of the incident I can't possibly say what it was, but the possibilities are numerous.

yorkie · 4 May 2019

headshot119 said:
It was just one example. As I said Don't put too much stock on what the open data sites tell you.

This is true.

In addition, further scepticism can be aimed at those sites which make their own alterations to the data.

ComUtoR said:
Thanks Dr Hoo.

As an aside. I wonder what would happen if the reason for the delay wasn't given and both the TOC and NR stated that you needed a FOI Request (and its associated costs) to get the information. Sometimes I feel that telling people the reason for the delay just makes them more angry.

It's generally the case that providing a reason will make people less angry.

ComUtoR said:
I had a passenger the other day asking for information that I just couldn't give him. Rather than accept the situation and deal with it, he just got more and more frustrated and angry.

I don't think it is likely that they would have been more angry if it had been possible to give them the information.

paddington · 4 May 2019

ComUtoR said:
People want information on demand so it tends to get provided. Nobody seems to remember that there is context or that information is changed. The industry simply released the data they use. There is no translation to layman terms or any lay understanding, just 'open data' to help provide 'transparency'

It's a bit like 'open source' software. The code is laid bare for anyone to read to prove they aren't hiding anything and to help provide some form of transparency but in reality you still need to be literate in code to understand it. You can check all the html for this forum page if you wanted. Most browsers will show it but again, it is of little use to anyone who doesn't understand it.

The difference is that it's possible to learn HTML yourself for free (well you have to buy a computer), and there are people who are interested in helping others learn without wanting any reward.

Whereas the only way to really understand the rail open data seems to be to get a rail-related job. Or go out with some trainspotters who know their stuff then spend the rest of your time on this forum.

yorkie · 4 May 2019

paddington said:
Whereas the only way to really understand the rail open data seems to be to get a rail-related job. Or go out with some trainspotters who know their stuff then spend the rest of your time on this forum.

This is completely incorrect. Why would a spotter necessarily know anything about open data feeds?

You have the rail related job bit the wrong way round; understanding data and systems can lead to job opportunities.

ComUtoR · 4 May 2019

paddington said:
The difference is that it's possible to learn HTML yourself for free (well you have to buy a computer), and there are people who are interested in helping others learn without wanting any reward.

Er.. This forum is providing help without any reward. People who are interested generally ask what each code means.

Whereas the only way to really understand the rail open data seems to be to get a rail-related job. Or go out with some trainspotters who know their stuff then spend the rest of your time on this forum.

That's the issue with all these systems that provide transparency or provide open data. It helps build trust in those without knowledge and those with knowledge understand it and also help build trust because they can see form themselves that the data is being honest.

ComUtoR · 4 May 2019

yorkie said:
It's generally the case that providing a reason will make people less angry.

People are getting more and more frustrated with the railway. No matter how many times 'leaf fall' is explained and NR do their superb videos and the posters go up; the second you tell people their train is delayed due to leaf fall they get angry. Same with 'over running' engineering works. They don't go 'oh, I understand now, cheerio' They get angry about it. The get frustrated that over and over again the same 'excuse' gets trotted out and 'why can't they do it on a weekend' and 'why is it always our line' etc etc. It increases their frustration and anger.

Don't get me wrong; I support telling people the reasons for the delays but it doesn't always help and does add to the problems. I had 3 passengers all with the same information. One got angrier and was actively taking it out on me, another was taking the information and using it to form a plan of action, another just made a quick decision and walked off.

Passengers are often very vitriolic and abusive. We give them reasons, they call it excuses and it can become another stick they beat you with.

I don't think it is likely that they would have been more angry if it had been possible to give them the information.

The request was for information that couldn't be provided on demand. and with my insider knowledge I knew if I gave it to him it would probably end up being wrong. Thanks to this forum I went out my way to provide it. The problem is that literally seconds after I gave it to him, it changed. He completely ignored what I was telling him and that's because his ire was just increasing. Open data here, is working against the passenger. Which again, can increase their anger.

I think that we have reached a point with information that it can become too much. Also, the information doesn't change the situation. One of the worse things we do; is not provide solutions. Give the reason for the delay, let them decide for themselves.

Bletchleyite · 4 May 2019

yorkie said:
This is true.

In addition, further scepticism can be aimed at those sites which make their own alterations to the data.

I love RTT and find it incredibly useful (e.g. no more guessing which arrivals go with which departures at Euston to avoid the scrum) - but you do have to understand its limitations and how it should be used, and when it's reliable and when it isn't.

Bletchleyite · 4 May 2019

_toommm_ said:
According to:

https://wiki.openraildata.com/index.php/Delay_Attribution_Guide

The cancellation code MY is caused by a coupler fault.

What you've got to remember is that RTT interprets the cancellation codes how the developer likes - for example, in the autumn, when theres excessive wheelslip caused by leaf fall, RTT shows the cancellation reason as 'because it's Autumn'.

RY on the above list does contain the word "mishap" - perhaps a keying error?

Tom · 4 May 2019

The reason for MY being shown as a mishap is that it was a mishap previously. I don't presently have the ability to alter attribution codes across the entire fleet of servers because of build issues on the website. This problem will be solved quite soon.

Cancellations coming down from TRUST only show the originally allocated cause. It can and does change later, but TRUST does not pass this down the TD.net channels. This applies for systems both internally and via the open data platform. Darwin (NRE) may show different reasons, and these ones can change. However, RTT cannot use these reasons for licensing reasons which NRE allow various entities to ignore, but have yet to tell me I can.

I'm nevertheless quite content to take feedback via the normal channels - [email protected] email address being the prime one - as ultimately if something is wrong then it helps to fix it. I don't often see issues appearing on forums appear in my mailbox, and I rarely read forums, so if I don't know I can't do anything about it.

_toommm_ said:
What you've got to remember is that RTT interprets the cancellation codes how the developer likes - for example, in the autumn, when theres excessive wheelslip caused by leaf fall, RTT shows the cancellation reason as 'because it's Autumn'.

The only delay codes that result in 'it being Autumn' are FT and TT (from memory) which are "Autumn-attribution Neutral Zone delays". The best summary of those reasons are literally is that it's Autumn as there are so many things that can come under that banner. If anyone has better suggestions for it, then send them via the normal channels, but no-one has yet to do so that I've seen.

swills said:
Agree with that, but then also some see RTT and Open Train as gospel and the information being put forward is 'official'

We are prohibited under our licensing conditions from saying official about anything one does, so you shouldn't see any open data site saying that.

43096 · 4 May 2019

Bletchleyite said:
I love RTT and find it incredibly useful (e.g. no more guessing which arrivals go with which departures at Euston to avoid the scrum) - but you do have to understand its limitations and how it should be used, and when it's reliable and when it isn't.

Agreed. RTT and the Open Train Times maps are absolutely invaluable in avoiding the crowds and getting a seat in the evening peak out of Waterloo, particularly during disruption.

As you say, you do need to understand the nuances to get the most out of them.

Bovverboy · 5 May 2019

Here's a delay attribution which sometimes manages to annoy me. Tonight's 2028 Liverpool Lime Street to Wilmslow stopper has apparently been cancelled (according to RTT) 'due to a planning error'. Forgot to detail a crew for it? The return working, 2252 Wilmslow to Liverpool Lime Street is cancelled 'due to late arrival of an inbound service'. Due to its non-arrival would appear to be more accurate. Northern's own publicity says that the cancellations are a consequence of a shortage of drivers.
The 2252 ex-Wilmslow is the last scheduled westbound through journey of the day, but I can't find any mention, anywhere, of replacement road transport being provided.
Other than the above, the Chat Moss route seems to have escaped almost unscathed today, a contrast to last Sunday when there were fourteen full or part cancellations.

The Northern service between Manchester (all stations) and Preston/Wigan via Bolton seems to have been reduced to at best, an hourly service Manchester Airport to Blackpool North, despite Northern's own publicity indicating that a full service was going to operate. Victoria to Bolton has been covered by the hourly Clitheroe service.

_toommm_ · 5 May 2019

Bovverboy said:
Here's a delay attribution which sometimes manages to annoy me. Tonight's 2028 Liverpool Lime Street to Wilmslow stopper has apparently been cancelled (according to RTT) 'due to a planning error'. Forgot to detail a crew for it? The return working, 2252 Wilmslow to Liverpool Lime Street is cancelled 'due to late arrival of an inbound service'. Due to its non-arrival would appear to be more accurate. Northern's own publicity says that the cancellations are a consequence of a shortage of drivers.
The 2252 ex-Wilmslow is the last scheduled westbound through journey of the day, but I can't find any mention, anywhere, of replacement road transport being provided.
Other than the above, the Chat Moss route seems to have escaped almost unscathed today, a contrast to last Sunday when there were fourteen full or part cancellations.

The Northern service between Manchester (all stations) and Preston/Wigan via Bolton seems to have been reduced to at best, an hourly service Manchester Airport to Blackpool North, despite Northern's own publicity indicating that a full service was going to operate. Victoria to Bolton has been covered by the hourly Clitheroe service.

There's absolutely no pattern to the cancellations - this week, the xx:59 from Picc to Glossop have been cancelled, last week AFAIK it was running fine, week before it was the xx:29...

Geeves · 5 May 2019

Just in regards to random reasons on the official channels being added for delays or cancellations, I (and potentially anyone else on the railway) who has access to the ATOS/Darwin system can put in any reason they like and it will update over the entire country to every app and every website. If TPE for example cannot (or have not) told me a reason for the delay Its then down to guess work, the system demands a reason even if you have no idea what it is. Hell some times I just add animals on the line.

Train cancelled by a "mishap"

Member

RailUK Forums

Established Member

Member

Member

Established Member

Established Member

Established Member

Established Member

Established Member

Established Member

Emeritus Moderator

Established Member

Established Member

Established Member

Established Member

Established Member

Established Member

Emeritus Moderator

Forum Staff

Member

Forum Staff

Established Member

Established Member

Veteran Member

Veteran Member

Member

On Moderation

Established Member

Established Member

Established Member