Ah I see! Misses some of the usual times off, - e....g. Shows Crow Nest Junction but not Hindley!It's a VSTP (very short term plan) working instead https://www.realtimetrains.co.uk/service/gb-nr:94601/2021-12-30/detailed
Ah I see! Misses some of the usual times off, - e....g. Shows Crow Nest Junction but not Hindley!It's a VSTP (very short term plan) working instead https://www.realtimetrains.co.uk/service/gb-nr:94601/2021-12-30/detailed
Ah I see! Misses some of the usual times off, - e....g. Shows Crow Nest Junction but not Hindley!
Presumably the odd pathing can be down to hastily inputted schedules?RTT doesn't even attempt to fill in the VSTP timings for various reasons, including that they're frequently just bizarre compared to normally pathed schedules.
I have seen light locos (obviously pathed at max 75mph) which have had sectional running times in some areas of 100mph+ across 15 mile sections.
As @_toommm_ says, the giveaway as to whether its infill is on the detailed service page: infilled times will be shown in grey and all timings from the path will be in black.
A not insignificant number of VSTP light engine movements are timed at 100mph because they (specifically) are permitted to travel at that speed. To correctly show in various systems, those schedules will often use LD75 as the timing load for the first SRT, then switch to something more appropriate for 100mph running going forward.I have seen light locos (obviously pathed at max 75mph) which have had Sectional Running Times in some areas of 100mph+ across 15 mile sections.
There is at least one FOC that is permitted to operate a substantial proportion of its loco fleet at 100 mph light engine, where appropriate, albeit not 37's (or 67's, as it happens).In the case in question I think it was a class 37 on the working operated by a FOC well away from the ECML.
I think that would be down to either human error by whoever at Northern who would have inputted the allocation or a late set swap.This may have been answered before but sorry if it has, but yesterday I was checking Realtime Trains and saw that Northern 156401+150105 were paired together on a Southport-Stalybridge diagram but when I got to Bolton yesterday afternoon despite Realtime trains stating this was the case it was 150144 that was paired up with 150105, does anybody know why Realtime Trains was showing the wrong information for most of yesterday (it was still showing 156401 was out last night on the diagram when I got home which I know wasn't the case)?
Interestingly that example is also only for part of the journey.Just a quick one Tom, there appears to be some allox duplication on some services, example below. Just wondered if you were aware?
https://www.realtimetrains.co.uk/service/gb-nr:Q49198/2022-01-31/detailed#allox_id=1
It still shows them. Tomorrow.Does RTT no longer show Eurostar workings? I'm sure they used to.
Does RTT no longer show Eurostar workings? I'm sure they used to.
SWR's inbound data has become a little interesting to handle in the last few weeks with the continuing omicron timetable changes. That's probably as much as I can say here. A new mitigation has been put in place. (p.s. please report things like this to the feedback email address as I don't read here that often as I am bored with social media in general, and I have a team of people handling support!)Just a quick one Tom, there appears to be some allox duplication on some services, example below. Just wondered if you were aware?
https://www.realtimetrains.co.uk/service/gb-nr:Q49198/2022-01-31/detailed#allox_id=1
Eurostar has always been a bit of a law unto itself in terms of movements between Temple Mills and St Pancras International. RTT will only show information about trains that it knows about, so if it doesn't have a train ID that makes any sense, then...well, it probably won't show anything. Given that this kind of behaviour only affects a small number of routes (of which Eurostar is probably the most noticable) then there's little point in wasting much effort on it as the passenger services still work OK.Thanks, guys. Maybe because there weren't many services, I didn't spot them in all the domestic stuff.
Don't think it shows all the ECS though; saw 4011 arriving at St Pan plat 9 last Friday at 1459, but it's not on RTT. There was also 4001 stabled in plat 10, but that didn't show on RTT either...
Thanks Tom. I always find RTT the first "go-to" site when I'm trying to write up my photo captions. Keep up the excellent work.SWR's inbound data has become a little interesting to handle in the last few weeks with the continuing omicron timetable changes. That's probably as much as I can say here. A new mitigation has been put in place. (p.s. please report things like this to the feedback email address as I don't read here that often as I am bored with social media in general, and I have a team of people handling support!)
Eurostar has always been a bit of a law unto itself in terms of movements between Temple Mills and St Pancras International. RTT will only show information about trains that it knows about, so if it doesn't have a train ID that makes any sense, then...well, it probably won't show anything. Given that this kind of behaviour only affects a small number of routes (of which Eurostar is probably the most noticable) then there's little point in wasting much effort on it as the passenger services still work OK.
Booked a Heaton diagram today, sits at Glasgow for the 1E97 1613 back.This looks rare! A northern 156 unit allocated to a Scotrail service tomorrow!
This looks rare! A northern 156 unit allocated to a Scotrail service tomorrow!
Been swapped for another Northern unit, now allocated 156471.Booked a Heaton diagram today, sits at Glasgow for the 1E97 1613 back.
That has now been corrected to just 333004Urm, somehow I don’t think that this happened.
View attachment 110301
Remember that RTT just displays the data that is inputted by the train company. Given the massive disruption on Leeds triangle services with units all over the place compared to booked diagrams it's not a surprise things are a little muddled.Urm, somehow I don’t think that this happened.
View attachment 110301
As we've been told countless times before, if 'rubbish' comes in the data feed (from Network Rail, Train Companies etc), then 'rubbish' comes out. It's beyond RTT's control.Urm, somehow I don’t think that this happened.
View attachment 110301
To be fair to Halish Railway, the statement could as likely have been 'tee hee, this amusing thing got into the system' as an accusation that RTT is somehow wrong or bad.As we've been told countless times before, if 'rubbish' comes in the data feed (from Network Rail, Train Companies etc), then 'rubbish' comes out. It's beyond RTT's control.
We've also been told countless times before that when there's disruption, which there is in bucket loads, not to expect accurate information at the time. It'll get updated later, if it gets updated at all.
Can confirm as a reader I was drawn to the former conclusion myself.To be fair to Halish Railway, the statement could as likely have been 'tee hee, this amusing thing got into the system' as an accusation that RTT is somehow wrong or bad.
Me too....it was definitely a tongue-in-cheek post!Can confirm as a reader I was drawn to the former conclusion myself.
Check the dateThere’s an interesting glitch that’s developed where the TOPS number under the train graphic is given in Roman numerals. If you’re not familiar with them do not worry the TOPS number is still given in the expanded description. I’m not sure if this has affected all of the TOCs participating in KYT.
View attachment 112358