RealTimeTrains website

[Ian Hardy]

Tom,

One helpful upgrade would be for RTT to auto-refresh, at present whenever you look at a location, the results are shown at the time you press the search button and the page says the same until the user refreshes the page.

 

[DavidGrain]

Tom,

One helpful upgrade would be for RTT to auto-refresh, at present whenever you look at a location, the results are shown at the time you press the search button and the page says the same until the user refreshes the page.

Personally I would not want an an auto refresh unless I was checking on a train that I needed to meet someone travelling on. Then I use the F5 key on my computer. Often I am looking at past or future trains when such a facility would not be required.

 

[malc-c]

I personally agree with Ian (sorry David), having the page for a selected train auto refresh would be very helpful. I use RTT to see what non-passenger services are running so I can video them, most of which seem to be treated with more flexibility and their timings change on route. Often I've gone out and been hanging around, having to phone home and talk my wife through refreshing and reading the last known location to see the train in question is being held etc.

Another plus for me would be to have RTT as an app on a windows phone that auto tracks... yeah some of us still have them

 

[theironroad]

I personally agree with Ian (sorry David), having the page for a selected train auto refresh would be very helpful. I use RTT to see what non-passenger services are running so I can video them, most of which seem to be treated with more flexibility and their timings change on route. Often I've gone out and been hanging around, having to phone home and talk my wife through refreshing and reading the last known location to see the train in question is being held etc.

Another plus for me would be to have RTT as an app on a windows phone that auto tracks... yeah some of us still have them

You need to upgrade your phone mate, then you could have the latest info wherever you've got a phone signal or WiFi.

 

[malc-c]

You need to upgrade your phone mate, then you could have the latest info wherever you've got a phone signal or WiFi.

I know, but I'm old school and use a phone for actually making voice calls... something the younger generation seem to overlook these days - but it does have internet access, just need a magnifier to read the web browser !

 

[xotGD]

No need for auto-refresh. I takes the user a second to reload the page.

The last thing you want is to lose the info when a page auto-refreshes when you are in a dead spot on the train and the screen just goes blank.

 

[Darandio]

I know, but I'm old school and use a phone for actually making voice calls... something the younger generation seem to overlook these days - but it does have internet access, just need a magnifier to read the web browser !

They aren't overlooking it, just moving with the times like everyone else. Besides, calling back to home base regularly will be an alien concept for many, they get out of the house to avoid talking to the wife.

 

[duffield]

Tom,

One helpful upgrade would be for RTT to auto-refresh, at present whenever you look at a location, the results are shown at the time you press the search button and the page says the same until the user refreshes the page.

I thought about that, then I thought (somewhat second-guessing Tom) that if lots of people used it, including mobile users with larger or unlimited data allowance and those using on -train wifi, it could considerably increase the server load, possibly requiring ££££ upgrades. Maybe if it was set to (say) no more often than 3 or 5 minutes and turned itself off after 15-30 mins needing manually restarting, that would minimise the impact?
Or it could be a paid premium feature!

(As an aside, when I used to support TOPS/Trust (mainframe railway computer system) we had to frequently scold (via NR) errant users who deliberately jammed the physical refresh key down to get constant 'auto-refresh' - it had, shall we say, a negative effect on the service, although it could cope.)

 

[takno]

I thought about that, then I thought (somewhat second-guessing Tom) that if lots of people used it, including mobile users with larger or unlimited data allowance and those using on -train wifi, it could considerably increase the server load, possibly requiring ££££ upgrades. Maybe if it was set to (say) no more often than 3 or 5 minutes and turned itself off after 15-30 mins needing manually restarting, that would minimise the impact?
Or it could be a paid premium feature!

(As an aside, when I used to support TOPS/Trust (mainframe railway computer system) we had to frequently scold (via NR) errant users who deliberately jammed the physical refresh key down to get constant 'auto-refresh' - it had, shall we say, a negative effect on the service, although it could cope.)

Auto-refresh can help with load if you have a lot of users auto-refreshing very rapidly, but it's unlikely that this would apply here. The alternative is to automatically push out updates as they arrive, which is the approach we take on Traksy. It's a whole world of code changes to support it though, and doesn't work for users with older browsers or JavaScript disabled. I think it's probably important to have somebody providing a rock-solid system that will work for everyone without too many whistles and bells, and right now that's something RTT does really well.

 

[Tom]

RTT has the infrastructure already to do auto-updating pages, I wrote it about 3 years ago. I think that I will likely implement this as part of a subscription version of the site though.

Sites like Traksy really need it out of necessity for the maps, etc, but wasn't at the top of priorities for RTT. The 'auto refresh' RTT I was working on when playing around with it years ago didn't do a refresh, just alter the appropriate content on the page.

 

[duffield]

RTT has the infrastructure already to do auto-updating pages, I wrote it about 3 years ago. I think that I will likely implement this as part of a subscription version of the site though.
...

I'd definitely consider subscribing for this feature, but only if the payment method was one I already use (paypal, amazon, google pay) *or* another similar well-known (currently, apparently) unhacked method rather than a site specific system. No disrespect intended, it's just that the more different payment methods you use online, the greater your chances of getting your card details compromised. I'd also pay a bit extra to cover any costs/overheads of using such a well-known method.

 

[Tom]

I use Stripe for everything. It's a fairly well known payment processor - more details at www.stripe.com - you've probably used it before without realising. It will accept payments via Apple and Google Pay as well, which have their cards tokenised. I won't be using any other provider if/when it happens.

 

[takno]

I use Stripe for everything. It's a fairly well known payment processor - more details at www.stripe.com - you've probably used it before without realising. It will accept payments via Apple and Google Pay as well, which have their cards tokenised. I won't be using any other provider if/when it happens.

Definite +1 for Stripe, who are used by thousands of websites. In practice, if you are comfortable that a website isn't a scam you aren't really taking any risks by giving them your card details anymore. the card industry rules mean that the site itself doesn't ever even get the details - they go straight from your browser to Stripe (or other provider). In risk terms it's very similar to going off-site and providing your details to PayPal.

 

[trainmania100]

Just thought i'd point out that the site status isn't reflecting for the trust feed that has unfortunately been down since 1024.

 

[palmersears]

One small issue (see attached) is the duplication of N/R on some services when in detailed mode on mobile Chrome.

 

[kieron]

A couple of things I've noticed (and which may have nothing to do with any of the recent changes):

1. In the detailed station display with ordering set to "Actual", trains which are scheduled to terminate at the station are sorted according to their actual arrival time. If a train is cancelled after that station, on the other hand, it will be sorted using its expected departure time. This means that the table does not show what happened at the station in the order it happened.

2. If I'm using Firefox 65.0.1 on Android but turn Javascript off, the search button on the detailed station display works correctly, but the "Show detailed filtering options" link does nothing.

 

[D6700]

RTT is now showing lots of schedules (WTT/STP/VSTP) as being "Pathed as Electric locomotive", when they were actually planned using diesel timing loads. Light engines and test trains are the ones I've spotted most often, although others creep in, especially if they make use of such a timing load at the origin. Other systems (official and public) do not replicate this error, which suggests it may well be an RTT website issue.

Here's an example, where RTT is incorrect, but OTT is correct:
https://www.realtimetrains.co.uk/train/Y75481/2019-11-01/detailed
https://www.opentraintimes.com/schedule/Y75481/2019-11-01

Of course, some such paths are genuinely planned as being electric and currently show correctly.

I notice from this thread there was the opposite issue with LNER Class 91 hauled services being erroneously shown as diesel on RTT, which was subsequently fixed.

https://www.realtimetrains.co.uk/train/O52091/2019-10-26/detailed

This is pathed as electric locomotive yet was 57003 towing 37038

Perhaps I was being unfair on @Strat-tastic when referring to this issue earlier! Apologies to @Strat-tastic if they were aware of how that specific train was actually timed, as opposed to simply which locomotives actually appeared on the train. That schedule was a direct TOPS input and showed Power Type as D, not E.

Quite. Garbage in, garbage out.

Perhaps not, this time!

I hope my post helps in fixing a couple of small issues.

 

[Tom]

Just thought i'd point out that the site status isn't reflecting for the trust feed that has unfortunately been down since 1024.

As I said to you in another forum, this is a glitch because the site is monitoring TD.net as opposed to NROD for that page. There will be a fix to it over the weekend.

One small issue (see attached) is the duplication of N/R on some services when in detailed mode on mobile Chrome.

View attachment 69959

Thanks I will do some investigation into this.

1. In the detailed station display with ordering set to "Actual", trains which are scheduled to terminate at the station are sorted according to their actual arrival time. If a train is cancelled after that station, on the other hand, it will be sorted using its expected departure time. This means that the table does not show what happened at the station in the order it happened.

Good catch. This is behaviour borrowed from the old version of the site due to how the ordering flags are built. Probably won't be fixed until the new backend is written unfortunately as that data isn't available to the frontend at sort time.

2. If I'm using Firefox 65.0.1 on Android but turn Javascript off, the search button on the detailed station display works correctly, but the "Show detailed filtering options" link does nothing.

This is expected, as that works based on Javascript. If anyone has a mechanism to do that toggle without JS please enlighten me - I'm not a frontend person. I thought getting the tooltips working without Javascript was pretty good given my lack of skills on that front

RTT is now showing lots of schedules (WTT/STP/VSTP) as being "Pathed as Electric locomotive", when they were actually planned using diesel timing loads. Light engines and test trains are the ones I've spotted most often, although others creep in, especially if they make use of such a timing load at the origin. Other systems (official and public) do not replicate this error, which suggests it may well be an RTT website issue.

A good catch - your bolded text is what made me think more closely. I just had another look at the code and it appears that anything that was just straight "D" was printing Electric. This will be fixed shortly.

Odd thing is that this wasn't an issue at initial launch, so must have been introduced when I fixed something else.

 

[Strat-tastic]

RTT is now showing lots of schedules (WTT/STP/VSTP) as being "Pathed as Electric locomotive", when they were actually planned using diesel timing loads. Light engines and test trains are the ones I've spotted most often, although others creep in, especially if they make use of such a timing load at the origin. Other systems (official and public) do not replicate this error, which suggests it may well be an RTT website issue.

Here's an example, where RTT is incorrect, but OTT is correct:
https://www.realtimetrains.co.uk/train/Y75481/2019-11-01/detailed
https://www.opentraintimes.com/schedule/Y75481/2019-11-01

Of course, some such paths are genuinely planned as being electric and currently show correctly.

I notice from this thread there was the opposite issue with LNER Class 91 hauled services being erroneously shown as diesel on RTT, which was subsequently fixed.



Perhaps I was being unfair on @Strat-tastic when referring to this issue earlier! Apologies to @Strat-tastic if they were aware of how that specific train was actually timed, as opposed to simply which locomotives actually appeared on the train. That schedule was a direct TOPS input and showed Power Type as D, not E.



Perhaps not, this time!

I hope my post helps in fixing a couple of small issues.

Apology accepted, thank you

 

[louis97]

An insight provided into some of the work I do in the latest blog post: https://blog.realtimetrains.com/2019/11/how-do-new-timetables-and-trains-affect-us/

 

[greatkingrat]

An insight provided into some of the work I do in the latest blog post: https://blog.realtimetrains.com/2019/11/how-do-new-timetables-and-trains-affect-us/

Does that mean the times shown on RTT don't necessarily match those in industry systems? I can see that causing confusion, particulary if say RTT shows a train 30 minutes late, but TRUST shows it 29 minutes late and the TOC refuses the delay repay claim.

 

[Tom]

Yes, this sometimes happens. From communications I've had a few TOCs they will tend to accept a RTT screenshot in that instance as proof of delay, though. It's normally no more than 30 seconds difference, frequently circa 10 secs - the worst areas for this are newly resignalled... TRUST however cuts the seconds off so 12:00:59 would come out as 12:00:00.

I get far more queries about TOCs refusing to pay out for, say, a 32 minute delay in detailed mode when a 29 minute delay happened as per the GBTT (e.g. booked 1200 WTT, 1203 public, actual 1232). The detailed mode shows delay as against the WTT, simple as against the GBTT.

 

[spark001uk]

One little quirk I've seen still in the new site is on a phone/tablet, when you go to scroll a page, depending how long your thumb dwells before the swiping motion, it places a highlight over that line in a similar same shade of blue to any "not stopping at" lines. It's by no means a problem, and I suspect it may be just a function of the browser rather than the site itself?

 

[Tom]

One little quirk I've seen still in the new site is on a phone/tablet, when you go to scroll a page, depending how long your thumb dwells before the swiping motion, it places a highlight over that line in a similar same shade of blue to any "not stopping at" lines. It's by no means a problem, and I suspect it may be just a function of the browser rather than the site itself?

It should be a slightly different shade of blue, and I mean very slightly, and this is just a result of there being specific tags in the styling files for hovering over a line on a PC - which on mobile is touching the line.

Does that mean the times shown on RTT don't necessarily match those in industry systems? I can see that causing confusion, particulary if say RTT shows a train 30 minutes late, but TRUST shows it 29 minutes late and the TOC refuses the delay repay claim.

I figured that writing these two blog posts from today might be useful in this context, as it explains the process in which offsets are developed by both the industry and RTT:

https://blog.realtimetrains.com/2019/11/about-offsets/
https://blog.realtimetrains.com/2019/11/a-study-in-offsets-aviemore/

 

[td97]

Can I add a bug report @Tom
The line "service forms 2E29 to Leeds" is incorrect and should display "service forms from ..."
The service does form 2E29 to Leeds on arrival at Manchester Victoria.
The "forms from" displays correctly prior to the train activity beginning.

 

[Tom]

This bug is known about and there's still work ongoing to work out where it's actually happening as it's a very transient thing - it doesn't always show incorrectly when the train is in flight

 

[spark001uk]

@Tom Just wondered, I know rtt shows cancellation reason data, but do you have access to the "formed of x carriages" and "delayed due to" data from any of the feeds? I've seen it on one or two mobile apps before, not that it always showed correctly.

 

[Y Ddraig Coch]

@Tom Just wondered, I know rtt shows cancellation reason data, but do you have access to the "formed of x carriages" and "delayed due to" data from any of the feeds? I've seen it on one or two mobile apps before, not that it always showed correctly.

Maybe not particularly helpful in general , but , works well if you have a specific station in mind that is covered.

http://iris2.rail.co.uk/tiger/

It basically show you live screens from the station you are looking at. My local station is included and it shows information about how many coaches, last known location and delays etc .It can be quite helpful for small things like that.

 

[Baxenden Bank]

I think I've got used to the changes now.
The colouration and boldening for early / right-time / late is nice and clear.
The use of text rather than symbols eg 'gains carriages here' makes things easier.
I can't grab, copy and paste the data into excel for subsequent marking/tinkering/analysis.

A certain other site 'interpolates' timings if the raw data is showing N/R. That is not a useful feature! Although it can be turned off. In many cases it probably doesn't matter but, living on the Stoke-on-Trent wobble of the WCML, N/R means the train has probably gone direct via Madeley, missed out Stone, and is thus a cancellation, rather than merely failing to report itself at Stone. A crucial difference!

 

[Tom]

A substantial update has been made today behind the scenes. There are vast improvements to the geography engine which means distances will now appear on most passenger services and a reasonable chunk of other services, there is a new TD handler meaning less 'approaching'/'arriving'/'at platform' hanging around. Some reductions to GB Railfreight service obfuscation has also been made. Also a new status page with better info about the feed uptime: https://www.realtimetrains.co.uk/about/status/

https://blog.realtimetrains.com/2020/01/new-realtime-trains-stage-2/