TOC codes when operators change hands

krus_aragon · 15 Aug 2019

takno said:
Could you make those 2 characters? You'd be amazed how expensive changing to a longer code would be

Especially when you decide that two digits aren't enough to store the year in dates any more.

RailUK Forums

takno · 15 Aug 2019

krus_aragon said:
Especially when you decide that two digits aren't enough to store the year in dates any more.

That will never bite us again. I mean they will _have_ to have stopped using the systems by 2060, which is when the problem was deferred to...

daveshah · 15 Aug 2019

takno said:
That will never bite us again. I mean they will _have_ to have stopped using the systems by 2060, which is when the problem was deferred to...

Even sooner there's the 2038 problem waiting to bite (overflowing Unix timestamps...)

takno · 15 Aug 2019

daveshah said:
Even sooner there's the 2038 problem waiting to bite (overflowing Unix timestamps...)

I'm definitely planning on retiring before that

Tom B · 15 Aug 2019

With the seeming move to brands for a franchise, decoupled somewhat from the incumbent operator, this will surely be less of an issue in future.

Poster timetables at stations display the two letter codes. Actually since LNER came in, I've mistakenly called them GNER a couple of times...

anamyd · 15 Aug 2019

NoMorePacers said:
West Midlands Railway is still 'LM' and Greater Anglia is 'LE' (what is that even from?) as well.

I believe Transport for Wales is "AW" as well. Why was it even changed to that, rather than remaining as WW or WB...?

alistairlees · 16 Aug 2019

Where a change of two letter code would be useful is at the change of a franchise. For example all trains that are operated by the new first /Trenitalia franchise will show as “Virgin Trains” in online journey planners right up to the day before the franchise changes. This is undoubtedly confusing for the general public (“I thought it was changing to First Group -why does it still say the operator is Virgin Trains? Is my ticket still valid?”). The same problem will be on tickets (route codes) issued before the franchise change.

The reason for this is that the data does not support with effect from /with effect until date ranges for TOC two letter codes. If it did this problem would be resolved. This additional data could be introduced in a non-breaking way so that at least some TIS / journey planners could display the correct operator details, and do at least reduce the number of confused passengers.

daveshah · 16 Aug 2019

Perhaps "brand name" for services should be separated from the internal franchise details in the data, and used in customer-facing situations. This would also deal with things like LNWR.

Clip · 16 Aug 2019

alistairlees said:
For example all trains that are operated by the new first /Trenitalia franchise will show as “Virgin Trains” in online journey planners right up to the day before the franchise changes. This is undoubtedly confusing for the general public (“I thought it was changing to First Group -why does it still say the operator is Virgin Trains? Is my ticket still valid?”). The same problem will be on tickets (route codes) issued before the franchise change.

I don't think it has ever caused a problem in the past when a franchise has changed - people still got on their trains and got to their destinations?

takno · 16 Aug 2019

alistairlees said:
Where a change of two letter code would be useful is at the change of a franchise. For example all trains that are operated by the new first /Trenitalia franchise will show as “Virgin Trains” in online journey planners right up to the day before the franchise changes. This is undoubtedly confusing for the general public (“I thought it was changing to First Group -why does it still say the operator is Virgin Trains? Is my ticket still valid?”). The same problem will be on tickets (route codes) issued before the franchise change.

The reason for this is that the data does not support with effect from /with effect until date ranges for TOC two letter codes. If it did this problem would be resolved. This additional data could be introduced in a non-breaking way so that at least some TIS / journey planners could display the correct operator details, and do at least reduce the number of confused passengers.

It would be far easier for the system converting the codes to display names to do this, rather than doing it in the source data.

smsm1 · 16 Aug 2019

yorkie said:
happens to change its branding part way during the journey

It's rather hard for the branding stuck/painted on the side of the train to suddenly change through the route. This should match the train operator name on the departure boards, and in any apps.

I'm aware that as part of the Thameslink transition there were some issues of Thameslink trains being marked as Great Northern on some systems for half the journey, and the opposite in the other direction, even so the train was operating with the save branding on the vehicle throughout. Whether the staff change half way through the journey is less relevant when you are trying to figure out whether you can get on the train.

There are occasions such as Greater Anglia loaning an East Midlands Trains unit for a day or two, or some early morning journeys around Norwich. That makes things harder, however it's a part of the network where there is normally only one operator and no operator specific tickets.

yorkie said:
I'm curious to learn what it is you do

I'm a sys admin/developer for a company that processes public transport data (including UK Rail) for major journey planners. An item that has come up in their user research is vehicle branding being different to departure boards or the journey planner data.

smsm1 · 16 Aug 2019

Clip said:
I don't think it has ever caused a problem in the past when a franchise has changed - people still got on their trains and got to their destinations?

For foul like us who understand the system, it's not an issue, however for the average person who takes a train and doesn't understand the detail of how it works, it's an issue that does cause confusion.

Clip · 16 Aug 2019

smsm1 said:
For foul like us who understand the system, it's not an issue, however for the average person who takes a train and doesn't understand the detail of how it works, it's an issue that does cause confusion.

Not in my years of front line experience but hey ho

AndyW33 · 16 Aug 2019

danielnez1 said:
With my Software Engineer hat on, being reliant on 2 character TOC codes seems like a bad idea as it drastically limits the possible combinations (especially given that multiple operators come and go over the years; something which BR et al. must have considered at that time) and they are not unique (i.e. NT for the two Northern franchises). In a relational database system, TOC codes would not be enough to uniquely identify each operator. My guess is that some company (possibility one that is associated with the rail industry and that starts with "A" and ends with "S") is making a killing to maintain interoperability.

And yet in the airline industry one set of two character alphanumeric codes is sufficient to distinguish every single airline offering scheduled passenger service in the entire world. (Yes, I know that some systems display 3 characters using look-up tables, but the underlying IATA codes are two character - it's just that people like Easyjet prefer their code relates to the brand name so EZY rather than U2) Are we really saying that we need more than that to separate out rail franchises in just one country?

smsm1 · 16 Aug 2019

AndyW33 said:
Are we really saying that we need more than that to separate out rail franchises in just one country?

Only if they are forever unique, which I don't think is something that's required. Having a few years between usage/recycling of the codes should be enough to allow the old names to filter out.

Class 466 · 16 Aug 2019

yorkie said:
and of course WMT is still 'LM'!

GTR has multiple TOC codes, each matching the name of the now defunct former constituent TOCs.

But there can be good reasons for this: the TOC codes are likely to be hard coded into systems such as journey planners, etc.

GTR paid to have FC changed to TL & GN.

alistairlees · 16 Aug 2019

smsm1 said:
For foul like us who understand the system, it's not an issue, however for the average person who takes a train and doesn't understand the detail of how it works, it's an issue that does cause confusion.

Correct. It won't come up with the EMT to EMR swap as that's too subtle, but it will certainly come up when Virgin Trains changes to West Coast Rail (if I have that name correct). If the industry were truly customer-focused then it would handle these things better; it's hardly difficult.

Class 466 · 18 Aug 2019

Bear in mind these two letter codes aren’t used in any general public facing systems, and it costs a lot to change them. Often begs the question is there really any point in spending this money on something that joe public won’t even notice?

pdeaves · 18 Aug 2019

Class 466 said:
Bare in mind these two letter codes aren’t used in any general public facing systems

The codes are used in public, on timetables (proper ones, not journey planners).

Adam Williams · 18 Aug 2019

takno said:
My software engineers hat tells me that 2 character alphanumeric gives you 1296 unique codes, which is plenty as long as you don't keep the online systems full of old data. With my "I read the documentation" hat on I'd say that it comes from a range of BR mainframe systems which means short alpha codes are the normal way of doing it, and they only ever anticipated using the codes for business units. Second guessing the decisions people made 30 years ago using an environment you likely don't understand, and under resource constraints that are difficult to even picture now, is a fools errand at best.

I'd have to agree with danielnez1 on this, it's poor practice nowadays and this sort of technical debt should've been managed and dealt with a long time ago. It never ceases to amaze me how many 'real world' systems are built on top of this sort of tech (which I consider obsolete) - don't get me started on the financial sector, for instance! I'll be interested to see if/when things improve, but in the meantime I guess IBM will be doing well.

anamyd · 18 Aug 2019

pdeaves said:
The codes are used in public, on timetables (proper ones, not journey planners).

was thinking the same thing... "AW: Transport for Wales, LM: West Midlands Trains (Railway)", VT: (West Coast Rail)" (on the Shrewsbury-Wolverhampton line)

takno · 18 Aug 2019

Adam Williams said:
I'd have to agree with danielnez1 on this, it's poor practice nowadays and this sort of technical debt should've been managed and dealt with a long time ago. It never ceases to amaze me how many 'real world' systems are built on top of this sort of tech (which I consider obsolete) - don't get me started on the financial sector, for instance! I'll be interested to see if/when things improve, but in the meantime I guess IBM will be doing well.

At the end of the day half of the global economy is run on software like this that was written 20-50 years ago and basically just does the job. We could replace it all every 5 years, but it would be a chronic waste of time and resources that could be spent doing something more useful. With systems like this there isn't just the base replacement cost, but also the downstream systems which depend on it. Ultimately replacing it with something shiny and new could easily cost the industry well over £100m all in. You may well then end up with a system that isn't as stable, still lacks important features, and has to be replaced again in 6 or 7 years when the underlying platform goes out of "long term" support. Basically you could be setting yourself up for an ongoing 20m a year in extra costs. Forever. Compared to that IBM is cheap (assuming that there's actually still a mainframe running the system anyway).

If there is a wholesale change to the industry structure, and if the system no longer supports the structure as a result, that's when it's time to fire up a new system, not just because some software engineers want to earn the big bucks but refuse to drop Elixir and learn some COBOL

Adam Williams · 18 Aug 2019

takno said:
At the end of the day half of the global economy is run on software like this that was written 20-50 years ago and basically just does the job. We could replace it all every 5 years, but it would be a chronic waste of time and resources that could be spent doing something more useful. With systems like this there isn't just the base replacement cost, but also the downstream systems which depend on it. Ultimately replacing it with something shiny and new could easily cost the industry well over £100m all in. You may well then end up with a system that isn't as stable, still lacks important features, and has to be replaced again in 6 or 7 years when the underlying platform goes out of "long term" support. Basically you could be setting yourself up for an ongoing 20m a year in extra costs. Forever. Compared to that IBM is cheap (assuming that there's actually still a mainframe running the system anyway).

If there is a wholesale change to the industry structure, and if the system no longer supports the structure as a result, that's when it's time to fire up a new system, not just because some software engineers want to earn the big bucks but refuse to drop Elixir and learn some COBOL

I don't disagree with what you've said - I think there's a difference between replacing it because it's not "new and shiny" and replacing it because it no longer does the job it should and/or there's a dwindling skills base. I suspect we just have different opinions as to when the latter is reached.

The experience I had with most of the CMA9 was that that they'd tried to use duct tape around their old systems to pull them into the current century. There'd be a shiny API server written in Java somewhere sat in front of all the old creaking tech for customers to interact with. This system would then talk to a mainframe which was incapable of handling unicode names, or was reliant on a batch job for updating data which meant nothing was realtime and massively slowed changes and innovation. My prediction in this area is that the challenger banks that have built their own tech (Monzo) will do a much better job here and be able to deliver features that consumers expect in 2019.

What does this have to do with rail? Rail is in a similar state from what I've seen of the systems which power it. 2 letter fixed TOC codes which are outdated are a symptom of a wider issue which, in my opinion, is an accumulation of technical debt and underinvestment in systems. Graduates will not want to deal with these systems or go and learn COBOL - and in CS at least, there is more than enough supply of work that not only do they not need to, it would be a losing proposition to go and adopt these sorts of technologies as a new engineer. The end result will be that maintenance gets more and more expensive over time.

alistairlees · 18 Aug 2019

The fares data structure is essentially unchanged from 20 years ago. As a result of a fear of changing the structure of the fares data, lots of other data has been added in other new systems which are meant to be used in conjunction with the fares data but which are often difficult to do so and which don’t in any case solve the issues with the fares data that are there in the first place.

Incremental change is essential. That doesn’t mean wholesale system change (though plenty of systems have been replaced, though usually without fixing the issues). Without incremental change there will be more issues, more hacks, more inconsistencies, more failure to keep up with customer expectations and more (not less) cost.

Nothing in the data is provided by IBM.

alistairlees · 18 Aug 2019

Adam Williams said:
I don't disagree with what you've said - I think there's a difference between replacing it because it's not "new and shiny" and replacing it because it no longer does the job it should and/or there's a dwindling skills base. I suspect we just have different opinions as to when the latter is reached.

The experience I had with most of the CMA9 was that that they'd tried to use duct tape around their old systems to pull them into the current century. There'd be a shiny API server written in Java somewhere sat in front of all the old creaking tech for customers to interact with. This system would then talk to a mainframe which was incapable of handling unicode names, or was reliant on a batch job for updating data which meant nothing was realtime and massively slowed changes and innovation. My prediction in this area is that the challenger banks that have built their own tech (Monzo) will do a much better job here and be able to deliver features that consumers expect in 2019.

What does this have to do with rail? Rail is in a similar state from what I've seen of the systems which power it. 2 letter fixed TOC codes which are outdated are a symptom of a wider issue which, in my opinion, is an accumulation of technical debt and underinvestment in systems. Graduates will not want to deal with these systems or go and learn COBOL - and in CS at least, there is more than enough supply of work that not only do they not need to, it would be a losing proposition to go and adopt these sorts of technologies as a new engineer. The end result will be that maintenance gets more and more expensive over time.

Exactly right. And there are many more examples of these issues in rail data and systems.

takno · 18 Aug 2019

Adam Williams said:
I don't disagree with what you've said - I think there's a difference between replacing it because it's not "new and shiny" and replacing it because it no longer does the job it should and/or there's a dwindling skills base. I suspect we just have different opinions as to when the latter is reached.

The experience I had with most of the CMA9 was that that they'd tried to use duct tape around their old systems to pull them into the current century. There'd be a shiny API server written in Java somewhere sat in front of all the old creaking tech for customers to interact with. This system would then talk to a mainframe which was incapable of handling unicode names, or was reliant on a batch job for updating data which meant nothing was realtime and massively slowed changes and innovation. My prediction in this area is that the challenger banks that have built their own tech (Monzo) will do a much better job here and be able to deliver features that consumers expect in 2019.

What does this have to do with rail? Rail is in a similar state from what I've seen of the systems which power it. 2 letter fixed TOC codes which are outdated are a symptom of a wider issue which, in my opinion, is an accumulation of technical debt and underinvestment in systems. Graduates will not want to deal with these systems or go and learn COBOL - and in CS at least, there is more than enough supply of work that not only do they not need to, it would be a losing proposition to go and adopt these sorts of technologies as a new engineer. The end result will be that maintenance gets more and more expensive over time.

As a Monzo customer I'm pretty uncomfortable with their stack tbh. They've made some pretty out-there tech choices. Cassandra is going to be total abandonware in 5 years, and their language choices are fairly niche. It's going to be unmanageable as a platform long before other banks get round to fixing their stacks.

I don't think we fundamentally disagree about except on timing. I've spent 20 years watching people spending millions trying and failing to replace systems which at heart are fine, and I've watched systems I wrote in a month as sticking plaster become turnkey solutions used daily by hundreds of thousands of people, and what I've basically learned is that unless it's completely broken, or you are adding a massive amount of useful new functionality that somebody actually asked for, then you don't want to change it. There's just too much else the entire profession could be doing.

None of this really affects the two-letter codes of course. If you really want to change those on public-facing timetables you could just write a mapping into the code which generates the PDF and leave the rest of the industry alone. Added to which, with the move to non-branded franchise names they could probably justify doing a one-time change to deal with all of them in one go.

ALEMASTER · 18 Aug 2019

I believe East Midlands Railway is keeping EM, the same as East Midlands Trains. It did however amuse me that on the 222's external displays they continued to display the ML for Midland Mainline as a prefix for the RSID train service number through the entire EMT franchise despite the timetable and reservation system having it as EM!

takno · 18 Aug 2019

ALEMASTER said:
I believe East Midlands Railway is keeping EM, the same as East Midlands Trains. It did however amuse me that on the 222's external displays they continued to display the ML for Midland Mainline as a prefix for the RSID train service number through the entire EMT franchise despite the timetable and reservation system having it as EM!

I've gone for shortening the name on Traksy to EMR. It's not a classic brand like GWR, but it does appear to be what they're planning to write on the side of the trains. EM is still the logical code for them, which is handy

TOC codes when operators change hands

Established Member

RailUK Forums

Established Member

Member

Established Member

Established Member

On Moderation

Established Member

Member

Established Member

Established Member

Member

Member

Established Member

Member

Member

Established Member

Established Member

Established Member

Established Member

Established Member

On Moderation

Established Member

Established Member

Established Member

Established Member

Established Member

Member

Established Member