Don't believe what the computer tells you.
The website ought to be programmed to tell you 'no data' rather than 'delayed', which would be more accurate
Unfortunately "no data" (i.e no train movement) will ultimately lead to "delayed" after a certain period of time for pretty much all CIS providers. Which is broadly the right way to do it and I am pretty sure teams where there is manual reporting know how important it is to input data. GPS data is a supplement but it can be patchy and spawn weird results. Of course other more important incidents can happen, but it is key. It is somewhat shocking a quarter of the way through the 21st century that we have parts of the railway that work like this but of course without investment, it is what it is..
== Doublepost prevention - post automatically merged: ==
Exactly this. I keep reading that accurate lat/long reporting isn't something the industry is that interested in though. They're happy with signalling berths. Personally I think they're missing a trick, as the travelling public has got used to apps like PlaneFinder, BusTimes etc, and there does seem to be a demand for live train maps. Or maybe that's just wishful thinking on my part![]()
For all the complaints about rail information, I find stationary digital bus information to be much more of a fiction, if it is even provided.
== Doublepost prevention - post automatically merged: ==
Maybe - its use at Parkway seems to be very intermittent and when it is used for west/southbound trains it will show long before the train is even in sight. Its use seems potentially dangerous - encouraging people to hurry unnecessarily down the stairs to the platforms. The only justifications I can really see for its use (neither of which really applies at Parkway) are 1) on a purely “arrivals” board and 2) where a train has a long layover but can already be boarded.
It ultimately depends on exactly where the berth and TD trigger is. This can of course vary.
Last edited:

