Is RDG's Journey Planning system fit for purpose?

[Belperpete]

A number of recent threads have led me to question whether the current system is up to the job.

Firstly, there is the thread about the WMT & Severn Valley through journey trial. This has been stymied by the failure of RDG to get the journeys and fares onto the national journey planning system, so that even if you do know about the trial, most journey planners will tell you that there are either no journeys or no fares. This will surely have put people off using the services.

Then there have been several threads about the TfW Flexi advance returns. These are effectively an advance for the outward journey, where you must travel on the booked train, but you can return the same day on any TfW train. Unfortunately they have had to be entered on the system as advances. So at least one poster wasn't sure if it was a single or a return. The system won't find them unless you specify a return train, that you don't have to use. And the return ticket incorrectly says that it is only valid on that train. It is as though they have had to bash a new square peg into an existing round hole.

And then there are the issues with TfW trying to implement an integrated transport system, so that TrawsCymru bus services appear on journey planners, station departure screens, etc. This highly commendable objective has thrown up a number of issues.

Firstly, it led to departure screens showing up services to undecipherable destinations. For example, the screens at Machynlleth could cope with bus services to Bangor and Aberystwyth, but not Caernarfon - for which it displayed some meaningless code. Thankfully they have finally got this sorted.

However, journey planners still don't seem to be able to cope with it. Some, such as Avanti, just don't find any journeys at all if they involve the bus. Most will find itineraries such as Porthmadog to Chester by bus to Blaenau Ffestiniog and then by train. However, some come up with ridiculous itineraries, such as Porthmadog to Chester via Bangor, that involve taking the train down to Machynlleth, then bus back up to Bangor (back through Porthmadog where you started!), and then train to Chester. Or by catching a bus to Povey's Garage (!?), and wait there an hour so that you can catch the next bus from Porthmadog to Bangor. Ridiculous.

It looks like the system, or those who run it at RDG, just can't cope with anything novel.

 

[Haywain]

It looks like the system, or those who run it at RDG, just can't cope with anything novel.

It looks like products are being created without any though as to to how journey planners can handle them. The fault is with the products and the TOCs who create them, and have the opportunity to feed in to RDG if they want changes made.

 

[Bletchleyite]

It looks like products are being created without any though as to to how journey planners can handle them. The fault is with the products and the TOCs who create them, and have the opportunity to feed in to RDG if they want changes made.

That's something that will get worse before it gets better. There are all manner of fares trials going on at the moment and about to be two more (TPE that is already up in BRFares, and Avanti which is coming at some point if they ever get round to it). But once we have the outcomes from those trials, whether we might agree with those outcomes or not, GBR will design a new national fares structure and then that can be properly built into all the retail systems without all these bodges - possibly even a wholly new such system (and how that system works should feed into how the eventual final state of the fares system is too). That of course isn't just what the fares tiers are but also whether stuff like Standard Premium goes national or gets binned - I'd be surprised if we were left with only one route with it.

I guess in short short term pain for long term gain.

Of course it remains to see what TfW and ScotRail's final fares systems are and whether they would agree for them to be the same as what GBR designs or not (e.g. would TfW insist on keeping that semi flexible return fare or would they be happy selling that as just a combination of an Advance and an Anytime, which is what it actually is). But they probably could be convinced to get them into the same sort of structure at least, even if ScotRail wants a 3 Hour Flex instead of a 70 minute one for example (assuming that is what they go for - they may of course not!). You'd just implement that once and store the number of minutes of flexiblity each way on either the restriction code or the ticket type as desired.

 

[Adam Williams]

Purely personal opinions below:

Is RDG's Journey Planning system fit for purpose?

RDG don't own a journey planning system (which is for the best, IMO). They are custodians of a product management system, data distribution tooling and a handful of APIs. They mainly distribute data for others to consume, write (and conduct) accreditation tests, and rent an off-the-shelf reservations system to power seat bookings and Advance availability.

The problems that you highlight are a combination of:

• Exactly what @Haywain identifies - not enough thought being given to the downstream impacts of new products when they are created
• A lack of interest in incrementally improving the existing data schemas, I don't think it's unfair to suggest that almost nothing substantial has changed in relation to the PMS fares data or timetable data provided to retailers in over a decade. This is despite a) new products being created (70min flex, day flex, "Advance flex" returns) that absolutely warrant changes to the schema and b) ticket restrictions being specified which the schema fundamentally does not support.
  • Retailers do care about the passenger experience and are willing to do work to support new, innovative products if they are thought through, a proper consultation happens and data is put in place to enable it to work properly. This should be done before a trial to ensure that it measures something tangible and there are actual take-aways from whatever it is that is to be evaluated.
• Lack of attention to data quality - I mean no offence to pricing managers or inventory managers when I say this, but today it's basically a free-for-all with TOCs doing whatever they want, duplicating products all over the place and little-to-no oversight. This makes the passenger experience suffer.
• Little to no investment in validation to improve data quality and prevent broken state
• A lack of in-depth understanding of how some of the systems that RDG ultimately is supposed to own ..actually work under the hood, not helped by staff attrition

I am sure there will be some forum members along in due course to paint RDG as some sort of helpless victim in all this that can't do anything itself without substantial budget, ministerial sign-off, unanimous sign-off from all of its members and 20 layers of governance and steering committees, but it ultimately is the custodian of these systems and there are many low/no-budget changes that could've been made (and low-hanging fruit that could've been addressed to improve the passenger experience) that just haven't been picked up.

RDG isn't run like a tech company, it doesn't have substantial in-house software engineering expertise. Many (most?) of its services don't have proper SLAs or out-of-hours incident response and the usual standard operating procedure is commissioning custom systems from a third-party supplier like SilverRail (which then aren't given the ongoing maintenance they deserve once "finished"). This is a real worry to me given how many new central points of failure the industry seems keen to introduce into the retail flow [railcard validation, anyone?].

== Doublepost prevention - post automatically merged: 10 Sep 2026 ==

whether stuff like Standard Premium goes national

This is a great example - it was introduced over 5 years ago. It could've (should've) been a separate fare class in the data and done right from the start. Instead, it was bodged in as standard class fares, which has forced all retailers to also bodge around it.

We've had the 70 minute flex tickets for over 2 years. I still have no data that tells me the validity window for these ticket types.

How long have we had the Veterans Railcard which should've been added as two separate Railcards (Veterans, Veterans with Companion). This could've been a quick win to fix the mess that is this product, and avoid passengers ending up at risk of prosecution. Why hasn't it been addressed?

Why should I have any confidence GBR will magically fix this?

 

[Horizon22]

Purely personal opinions below:



RDG don't own a journey planning system (which is for the best, IMO). They are custodians of a product management system, data distribution tooling and a handful of APIs. They mainly distribute data for others to consume, write (and conduct) accreditation tests, and rent an off-the-shelf reservations system to power seat bookings and Advance availability.

The problems that you highlight are a combination of:

• Exactly what @Haywain identifies - not enough thought being given to the downstream impacts of new products when they are created
• A lack of interest in incrementally improving the existing data schemas, I don't think it's unfairto suggest that almost nothing substantial has changed in relation to the PMS fares data or timetable data provided to retailers in over a decade. This is despite a) new products being created (70min flex, day flex, "Advance flex" returns) that absolutely warrant changes to the schema and b) ticket restrictions being specified which the schema fundamentally does not support.
  • Retailers do care about the passenger experience and are willing to do work to support new, innovative products if they are thought through, a proper consultation happens and data is put in place to enable it to work properly. This should be done before a trial to ensure that it measures something tangible and there are actual take-aways from whatever it is that is to be evaluated.
• Lack of attention to data quality - I mean no offence to pricing managers or inventory managers when I say this, but today it's basically a free-for-all with TOCs doing whatever they want, duplicating products all over the place and little-to-no oversight. This makes the passenger experience suffer.
• Little to no investment in validation to improve data quality and prevent broken state
• A lack of in-depth understanding of how some of the systems that RDG ultimately is supposed to own ..actually work under the hood, not helped by staff attrition

I am sure there will be some forum members along in due course to paint RDG as some sort of helpless victim in all this that can't do anything itself without substantial budget, ministerial sign-off, unanimous sign-off from all of its members and 20 layers of governance and steering committees, but it ultimately is the custodian of these systems and there are many low/no-budget changes that could've been made (and low-hanging fruit that could've been addressed to improve the passenger experience) that just haven't been picked up.

RDG isn't run like a tech company, it doesn't have substantial in-house software engineering expertise. Many (most?) of its services don't have proper SLAs or out-of-hours incident response and the usual standard operating procedure is commissioning custom systems from a third-party supplier like SilverRail (which then aren't given the ongoing maintenance they deserve once "finished"). This is a real worry to me given how many new central points of failure the industry seems keen to introduce into the retail flow [railcard validation, anyone?].

A good review of RDG - also I think they're also a bit of a catch all, umbrella organisation for quite a lot of things now and their true purpose has ended up drifting and being diluted somewhat; I would suggest from a governance point of view GBR may help here to really clarify what is the focus and what should be spun out somewhere else. Too many people working at cross purposes or not really having joined-up thinking.

Also the latter point - my bold - is certainly an increasing concern which I'm seeing more evidence of, although not in the retail world.

 

[Bletchleyite]

We've had the 70 minute flex tickets for over 2 years. I still have no data that tells me the validity window for these ticket types.

The best one in my view is the restriction codes on West Midlands Trains' Super Off Peak tickets. They contain the line "a connecting service can be used to complete a journey begun at a valid time". This cannot be implemented, and so planners show them as valid on far fewer trains than they actually are valid on.

This line would also be helpful for Oval fares where the paper version has far less validity when changing trains than the contactless version, as they've chosen not to include an unimplementable line in the restriction code for these.

This has been a problem for something like fifteen years, and has been reported lots of times, and it still persists. And yet all it would take would be a flag on the restriction code and some tweaks for everyone to implement it, and we could for example then have the Oval paper and contactless fares lined up pretty closely and get rid of this overcharging nonsense.

 

[CyrusWuff]

(Standard Premium)
This is a great example - it was introduced over 5 years ago. It could've (should've) been a separate fare class in the data and done right from the start. Instead, it was bodged in as standard class fares, which has forced all retailers to also bodge around it.

The problem is that any new product (currently) has to be encodable on a magstripe, the format for which was essentially fixed back in the 1980s. That gives you precisely 1 bit to indicate the class of travel. In a shockingly sensible decision, that's set to 1 for First Class, otherwise it's set to 0.

 

[Adam Williams]

The problem is that any new product (currently) has to be encodable on a magstripe, the format for which was essentially fixed back in the 1980s. That gives you precisely 1 bit to indicate the class of travel. In a shockingly sensible decision, that's set to 1 for First Class, otherwise it's set to 0.

Appreciate the magstripe standard has its limitations, and would be a nightmare to change - you're not at all wrong in saying this.

But I would advocate for "progressive enhancement" because of this: you do a more sensible, future-proofed encoding in the systems that can support it - the type06 standard for barcodes, in the fares data feed that retailers use etc etc and fall back to mapping it to "standard class" for CCST

I think it's already the case that the data available in a PRT or E-Ticket barcode is much richer than you get on the magnetic stripe (with things like the full product codes, restriction code etc).

 

[Belperpete]

would TfW insist on keeping that semi flexible return fare or would they be happy selling that as just a combination of an Advance and an Anytime, which is what it actually is).

I did wonder why they didn't just offer a TfW-only day return. I suspect that they have done as an advance so that they could if required apply quota-control, although I have seen no evidence of sales being restricted so far. The only other way being to make services reservation-compulsory, as Avanti?

I suspect that the problem with the Traws Cymru journey planning is that they have not put Porthmadog, Criccieth, etc in as stops on the Mach to Bangor T2 service, to stop rail journey planners offering Porthmadog to Mach or v.v. by bus, undercutting the train, as the bus is both significantly faster and cheaper than the train for such journeys. So if you put Porthmadog into the journey planner, it will find the T22 bus services, but not the T2. Hence the ridiculous itineraries that involve travelling by T22 bus or train to somewhere else the T2 stops.

In both cases, things are having to be bodged to fit the lumbering dinosaur of a system that we currently have, and with pretty poor results.

 

[Belperpete]

RDG don't own a journey planning system (which is for the best, IMO). They are custodians of a product management system, data distribution tooling and a handful of APIs. They mainly distribute data for others to consume, write (and conduct) accreditation tests, and rent an off-the-shelf reservations system to power seat bookings and Advance availability.

I am sure there will be some forum members along in due course to paint RDG as some sort of helpless victim in all this that can't do anything itself without substantial budget, ministerial sign-off, unanimous sign-off from all of its members and 20 layers of governance and steering committees, but it ultimately is the custodian of these systems...

RDG isn't run like a tech company, it doesn't have substantial in-house software engineering expertise. Many (most?) of its services don't have proper SLAs or out-of-hours incident response and the usual standard operating procedure is commissioning custom systems from a third-party supplier like SilverRail (which then aren't given the ongoing maintenance they deserve once "finished"). This is a real worry to me given how many new central points of failure the industry seems keen to introduce into the retail flow [railcard validation, anyone?].

It does beg the question, if RDG isn't providing support for the systems it is custodian of, who is?

 

[Bletchleyite]

I did wonder why they didn't just offer a TfW-only day return.

If they set the interavailable fare they aren't allowed to, which may be one reason why.

 

[alistairlees]

More bodges are coming, just in case you think we have reached peak bodge.

 

[CyrusWuff]

More bodges are coming, just in case you think we have reached peak bodge.

I look forward to seeing which TIS (or TISes) it breaks then.

Heathrow Express Advances are a good example of breaking things, as all the trains in a given direction on a given day use the same Retail Service ID.

 

[Adam Williams]

the usual standard operating procedure is commissioning custom systems from a third-party supplier like SilverRail (which then aren't given the ongoing maintenance they deserve once "finished")

To give another concrete example here, there is a system called the Timetable Comparator Service (TCS) which is used to trigger when to send out email notifications to customers that inform them that their train has been cancelled. Customers in this unfortunate position are offered an unconditional full refund, in line with their rights under the National Rail Conditions of Travel.

This system has no support for stop reinstatement notifications at all - when we requested support for them, we were told they were considered out of scope.

In this way, retailers reliant on TCS will email to say their journey is no longer possible but then will not tell the passenger if it's then put back in place the next day. We'd seemingly rather have the industry lose that revenue than invest a couple of software engineering days into making it fit for purpose.

This is particularly important because trains / stops do get accidentally removed from the timetable.

It's also the case that TCS will sometimes (based on how train planners go about making changes) identify a service as cancelled when it has actually been replaced by an otherwise identical, new train with subtly different attributes in the timetable - but otherwise departing and arriving at exactly the same times. There's ultimately nothing to stop the passenger still travelling with their original ticket - no impact to their actual journey, but they'll have been emailed and (essentially misleadingly) told their train has been cancelled. Again, most customers don't question the email they've been sent and will opt for a full refund. This is pouring ticket revenue down the drain for absolutely no reason, as well as incurring costs for retailers and adversely affecting the reputation of the reliability of the railway.

When we talk about reducing subsidy and increasing revenue, I think of fixing nonsense like this and encouraging growth, rather than cutting service frequencies and introducing more "surge pricing" to squeeze money out of passengers.

 

[alistairlees]

I look forward to seeing which TIS (or TISes) it breaks then.

Heathrow Express Advances are a good example of breaking things, as all the trains in a given direction on a given day use the same Retail Service ID.

Haha. That was my idea.

 

[WAB]

suspect that the problem with the Traws Cymru journey planning is that they have not put Porthmadog, Criccieth, etc in as stops on the Mach to Bangor T2 service, to stop rail journey planners offering Porthmadog to Mach or v.v. by bus, undercutting the train, as the bus is both significantly faster and cheaper than the train for such journeys. So if you put Porthmadog into the journey planner, it will find the T22 bus services, but not the T2. Hence the ridiculous itineraries that involve travelling by T22 bus or train to somewhere else the T2 stops.

More likely it’s due to the T2 not stopping at the railway station. It’s quite difficult to communicate multiple stops within the constraint of the existing system.

 

[MrJeeves]

However, journey planners still don't seem to be able to cope with it. Some, such as Avanti, just don't find any journeys at all if they involve the bus.

Probably for the best, as so many rail tickets are ""valid"" on these buses according to the routeing guide data.

There's no way to make them invalid in most cases, either, without changes to the data feed which I have suggested but have gone nowhere as you might expect.

 

[Belperpete]

More likely it’s due to the T2 not stopping at the railway station. It’s quite difficult to communicate multiple stops within the constraint of the existing system.

That doesn't explain why Mynffordd isn't included, where the bus stops immediately outside the station.

 

[Belperpete]

Probably for the best, as so many rail tickets are ""valid"" on these buses according to the routeing guide data.

There's no way to make them invalid in most cases, either, without changes to the data feed which I have suggested but have gone nowhere as you might expect.

Sooner or later someone who has bought a ticket on the TfW website (for example) is surely going to be presenting one of these tickets on the bus. Perhaps because the buses are run by TfW the bus driver might accept a TfW-produced itinerary? But I forsee problems with an itinerary produced by any other retailer. Fortunately I have a concessionary pass that I can show on the bus.

This does seem to be one of those cases where a problem with the system is working in the passengers favour. If you have an itinerary from an authorised retailer, then the NRCoT says that route is inherently valid (for the rail part of the journey at least).