Any reason why trainsplit is not offering a particular journey for sale?

[TheConfusedMan]

I'm looking at Cowes West -> Brighton return (5th March -> 6th March).
For the return portion my choices are 7:32 (am) -> 10:48, then nothing until 9:00 -> 11:58......
Yet when I use trainline / national rail enquiries there is an 8:31 -> 11:58 version without the tight changeover

Does trainsplit make a habbit of not giving you certain options for certain reasons?

 

[Adam Williams]

I'm assuming your search is the one that was done on the RailUK Forums site at 10:39 which yielded these results.



The journey planner will normally trim out results that aren't considered optimal.

The 8:31 -> 11:58 itinerary arrives at exactly the same time and costs exactly the same, you just waste additional time above and beyond the MCT in Southampton. There is no reason to surface it with a default set of search parameters. If I turn off trimming, I legitimately get 288 possible itineraries between Brighton and Cowes for an ArriveBefore 13:15 on March 6th - the vast majority of them overtaken, which is why this logic exists. Every journey planner will have their own version of this sort of logic, which is why IPTIS (National Rail Enquiries)/Hafas (Trainline) might choose to surface different itineraries than FastJP.



Where do you draw the line here? You could make the argument that this even slower 08:01 itinerary should be included too!



The way to get the itineraries you want to buy is to tell the journey planner your intentions. In your case, you want more time in Southampton - above and beyond the minimum connection time - so the best approach is to ask for it:



And you'll get the options on the return that you want:

 

[TheConfusedMan]

Good lord, that's detailed, thanks.

I've never delved into those options before but yes, they would have fixed my issue.

The fundamental problem with the route suggested was the limited time left for the changeover mid-route on the 9:00 Brighton > Southampton. The last *four* times I or a family member has got a train, we've been delayed later than the time the system allowed for at least one changeover, and missed a connection, with all the knock on effects that can have.

The last time it happened was yesterday in fact, hence my concern.

Also as the ticket was for a family member who doesn't get trains much and HAS to get back to West Cowes by a certain time, the far better option was the direct 8:31 with no changes. Sure it's 30 minutes longer, but it's also far less complex and risky from her point of view.

Thanks for the feedback though. It's fascinating to see how it works under the hood (I write software also btw, but thankfully not route planning).

I can see why you would need to filter out bajillions of edge cases and multi-change routes... I was just surprised that it filtered out a direct connection without mentioning it.

 

[Adam Williams]

The fundamental problem with the route suggested was the limited time left for the changeover mid-route on the 9:00 Brighton > Southampton. The last *four* times I or a family member has got a train, we've been delayed later than the time the system allowed for at least one changeover, and missed a connection, with all the knock on effects that can have

Useful practical context, thanks.

To me, it suggests that some of the centrally set minimum connection times aren't really sufficiently set, given it sounds like this causes real problems repeatedly.

Thanks for the feedback though. It's fascinating to see how it works under the hood (I write software also btw, but thankfully not route planning).

No worries, always happy to try and shed some light on how these sorts of things are currently implemented! I'm sure that as a software engineer, even if you're not dealing with route planning day-to-day, you can relate to the different trade-offs at play, with what ultimately gets presented back to the user. I find it more challenging to explain to some other less-technical stakeholders, sometimes.....

There's probably room for improvement here when there are very few return itineraries that come back. You can afford to trim fewer itineraries and maybe show a couple with additional slack in their connections. We're working on some new filtering options in the TrainSplit Beta site and take all customer feedback into consideration, so will discuss this further with the team at Raileasy and FastJP.

 

[TheConfusedMan]

I'm sure that as a software engineer, even if you're not dealing with route planning day-to-day, you can relate to the different trade-offs at play, with what ultimately gets presented back to the user.

Tell me about it. I'm currently writing some code to take continuous 24 hour a day GPS position data and try to automatically split it into 'journeys' with start and stop points. It's all a bit disgusting.

 

[Adam Williams]

Tell me about it. I'm currently writing some code to take continuous 24 hour a day GPS position data and try to automatically split it into 'journeys' with start and stop points. It's all a bit disgusting.

Rather you than me, I think!