Opentrain times/Signal maps technically question.

[RailwayRookie]

I was under the impression these sites pulled signal aspect information from CCF as they alway seem to be about a second delayed from when a singal clears on there.

Looking at the the Ely area, particularly the single line at Soham there's all sorts of conflicts.

Opentrain times shows most signals at green with conflicting routes set across single lines and junctions, Tracksy and Signal Maps both show conflicting greens too.

So my question is, on the ground these signals are almost certainly at red because of a T3, so in theory CCF shows the same, so while Tracksy shows blank aspects around Ely, what could cause some sites to fall everything back to green.

I know its quite unimportant in the grand scheme of things but my curious mind won't leave it be.

 

[louis97]

Opentrain times shows most signals at green with conflicting routes set across single lines and junctions, Tracksy and Signal Maps both show conflicting greens too.

There is signalling work going on around there over this Christmas. The level of work going on means the interpretation of the raw data needs updating.

What you're seeing is fairly common during signalling works, it'll likely remain like it until the background interpretation of the data is updated to reflect the signalling works.

So my question is, on the ground these signals are almost certainly at red because of a T3, so in theory CCF shows the same, so while Tracksy shows blank aspects around Ely, what could cause some sites to fall everything back to green

It'll be in the interpretation of the data, CCF might not show the same if it has already been setup for the data post the signalling work.

 

[Nicholas Lewis]

I was under the impression these sites pulled signal aspect information from CCF as they alway seem to be about a second delayed from when a singal clears on there.

Looking at the the Ely area, particularly the single line at Soham there's all sorts of conflicts.

Opentrain times shows most signals at green with conflicting routes set across single lines and junctions, Tracksy and Signal Maps both show conflicting greens too.

So my question is, on the ground these signals are almost certainly at red because of a T3, so in theory CCF shows the same, so while Tracksy shows blank aspects around Ely, what could cause some sites to fall everything back to green.

I know its quite unimportant in the grand scheme of things but my curious mind won't leave it be.

It uses the data feeds from the train describers which are constantly pushing out data when anything changes of state ie signal aspect changes, a route get sets up or cancelled and train stepping between berths. CCF uses the same data sources but has the advantage of playback so ops staff can look back and see sequence of events when investigating train delays for example.

The internet based systems can only log the last known state of an asset and given this area is being transferred to new signalling it will have a new data feed from the SSI so all data is unreliable and stale currently.

 

[68000]

CCF (and its replacement TMV) will get design updates to match infrastructure and signalling changes as part of projects and will be commissioned in line with the commissioning dates of those projects

 

[takno]

Short answer is that the data is always available, but the keys to the data aren't made available, so all you get is a few thousand on/off indications. All the individual sites then have to work out how to map those to individual signals and routes. Quite a lot of data is shared between sites once it has been worked out, but none of it is released by Network Rail anymore. Indeed Network Rail don't even share maps, so it's necessary for the various sites to work out where the signals even are.

The people developing and maintaining CCF will have been provided with the data mappings and route maps in advance of the work being done. In many cases they actually use this to get the maps updated promptly.

 

[Class15]

There’s an interesting issue like this on the Wherry lines on Railcam. Every signal is presented as green, and this is clearly not a temporary issue as it has been like this for years. It would be more helpful to not show the aspects, I would think!

 

[takno]

There’s an interesting issue like this on the Wherry lines on Railcam. Every signal is presented as green, and this is clearly not a temporary issue as it has been like this for years. It would be more helpful to not show the aspects, I would think!

I do try to do that on Traksy, but I'm not always aware of where the data has changed, and it's sometimes fiddly to figure out whether there has just been a small change or error, or whether the whole zone needs to be deleted and reworked.

 

[J-Me]

In regards to the Wherry Lines the data for the signals on the feed is reversed and is the only signalling area I've seen this. I've been making my own maps (poorly created and coded because I'm thick and not publicly available) for the past 10 years and thankfully my simple code means I could easily invert my regular code to display the signals correctly (as seen in attached image). I suspect maps such as those on the railcam site have far more sophisticated code under the hood making it more complicated to adapt to what seems to be an error on the data feeds end. The S Class data tables are rarely if ever updated unless there's a signalling change so its unlikely to change for the foreseeable future.

@takno I have tremendous respect for you and what you've created with Traksy. I see just how much nitpicking and criticism you (and other map creators) have to deal with and I simply don't have the desire to deal with that!

 

[Freightmaster]

There is signalling work going on around there over this Christmas. The level of work going on means the interpretation of the raw data needs updating.

What you're seeing is fairly common during signalling works, it'll likely remain like it until the background interpretation of the data is updated to reflect the signalling works.

Exactly the same thing has happened this morning in the York signalling area (Northallerton to Temple Hirst);
the signal/berth numbers themselves are unchanged, but workstation upgrades at York ROC mean that all
signal aspect/route setting data has been altered, so none of the main diagram sites (OTT/Traksy/Railcam)
will be able to display correct signal data on that part of the ECML for the foreseeable future...


I know it's a long shot, but if anyone reading this has access to updated 'SOP' tables for this project
that they are prepared to share, it would make my Christmas if you could contact me anonymously
by PM to save me having to spend several days working round the clock to get all the signal aspects working
one by one using a process of trial and error!




MARK

 

[louis97]

the signal/berth numbers themselves are unchanged,

Most of them are, there are some minor changes to the berth numbers in the bay platforms at York.

 

[takno]

Exactly the same thing has happened this morning in the York signalling area (Northallerton to Temple Hirst);
the signal/berth numbers themselves are unchanged, but workstation upgrades at York ROC mean that all
signal aspect/route setting data has been altered, so none of the main diagram sites (OTT/Traksy/Railcam)
will be able to display correct signal data on that part of the ECML for the foreseeable future...


I know it's a long shot, but if anyone reading this has access to updated 'SOP' tables for this project
that they are prepared to share, it would make my Christmas if you could contact me anonymously
by PM to save me having to spend several days working round the clock to get all the signal aspects working
one by one using a process of trial and error!




MARK

There does seem to be a growing tendency to rewrite the whole SOP table for small changes rather than selectively inserting new things wherever they will fit which can be a little frustrating

 

[Freightmaster]

There does seem to be a growing tendency to rewrite the whole SOP table for small changes rather than selectively inserting new things wherever they will fit which can be a little frustrating

Looks like that's what has happened at York - no new signals to accommodate,
but all the existing signals have been given new data addresses anyway.

It looks like I'll be spending the whole weekend trying to sort out this mess;
I'll send you a PM if/when I manage to work anything out...




MARK

 

[Tom]

Looks like that's what has happened at York - no new signals to accommodate,
but all the existing signals have been given new data addresses anyway.

To be fair, York is a complete recontrol from IECC to WestCAD... so it's not like for like in the slightest.

 

[takno]

To be fair, York is a complete recontrol from IECC to WestCAD... so it's not like for like in the slightest.

That does make more sense. Same signal numbers and routes, but a complete change to the bit which is generating the s-class data. On the upside WestCAD does tend to output the bit changes and berth moves in the order you expect them, and a cleanly-generated mapping will tend to have things in order.

I'm mostly spending the day trying to make southern region headcodes map properly, now that I've got a decent copy of the timetable in the system. Slightly mystified as to why GTR have cancelled all the permanent schedules and replaced them with STPs, and irritated by the fact that activations are firing both for the permanent schedule and the STP. I suppose at least having a very big obvious mess gives me some good data to debug the problem...