It seems like it should be such a trivial thing to agree on; presumably the fragmented structure of the industry is what is preventing it. Do you know if anyone in RDG or TOCs is agitating at Network Rail to make it happen? (I presume it is Network Rail's responsibility, since they are the ultimate owners of the schedule data.)
I doubt it's anything to do with them whether a train is reservable or not
No-one claimed it was. The claim was that they own the data, so are responsible for any changes to its format.
Claimed? It was suggested in a post and I suggested why I believe it would not be held by NR.
It all hinges on whether a train can simultaneously be reserveable and non-reserveable in the reservation system. It couldn't in the old system, I don't know about the new system. Not sure what safety cases have to do with it though.
Do they own the public timetable data? I would've expected that it belongs to RDG. Network Rail would be responsible for the working timetable - they care what time a train is going to run, and how long it's expected to be in section, rather than if anyone is actually on board and has a seat (or not!)
Correct - that's what I meant. I'm surprised anybody is challenging that; I thought it was a definite given.
No I don't think so - the reservation status just needs an extra level of granularity. Currently there are three values:
I think the answer to this is to make the changes in a backward-compatible way such that nobody needs to spend anything, but anybody who wants to provide clearer information to passengers (whether TOC or software supplier) can do so voluntarily as and when suits them.
I know they own the data feed and distribute it but they won't have any knowledge of which trains do/don't have reservations, which trains have refreshment carts and which services do/don't convey first class - that data has to be provided by the TOCs. Network Rail are just a curator/custodian of the data so any changes would have to be instigated by the TOC, rather that NR.
No, just introducing a new value like that would break things, as all systems would need to be updated to handle it.
Yes exactly! It should be a really easy change, yet nobody seems to be in a position of authority to grasp the nettle and just do it. I hope DfT control of everything will change this...
I suppose so, you can't trust that programmers have implemented decent error handling. One of the things I was taught from very early in my coding days was "expect garbage input and handle it", unfortunately not everyone got the memo.
No, you said it wasn't up to them whether a train was reservable, which no-one had suggested. If you want to say they're not in charge of the data format, feel free to say so. Whoever is would need to add or change one of the fields used.
If you're expecting one of two values and you get a third, how do you handle that? You can flag it as an error, but assigning it one of the other two values may well not be correct.
You use the default: clause of your switch statement, where that is either using the most appropriate value or rejecting the record.
But then presumably any booking engine trying to get a reservation from NRS will fail if it won't give one for that ticket type.
No, changing the meaning of values is only going to break things. Like Caledonian Sleeper, in this case. Better to add a new value. In any case I'm trying to get these things changed. It's remarkably difficult - not enough people understand the central importance of data, or the need for it to evolve. Most standards have barely changed in 25 years. Privatisation has caused ossification of the data structures, inhibiting innovation.
Yes, I misread Paul's post. In which case it might just work. No TIS distingushes between "reservations recommended" and "reservations possible" in a logical sense, so far as I know, so effectively one is superfluous.
Yes, that was my point that there is no difference in logical behaviour (i.e. in relation to which trains need a reservation to be made on them), so it shouldn't break anything but would improve passenger information. It is a small loss, as "reservations recommended" did convey extra information where it was used, e.g. a number of long-distance CrossCountry trains used to be "reservations recommended" for part of their journey where particularly heavy loading was expected, and "reservations available" for the rest of the journey. But I think losing that would be a good compromise to make, and in any case a new code for "reservations recommended" could be introduced, but only put into use a couple of years later once all systems were compliant with the new standard.
Sounds good; good luck.
I think Paul's idea is the way to do it. The timetable format dates from 1988 and hasn't been touched for years. Have there ever been trains that had seats for some ticket types and counted places for others? I feel there may have been a TOC doing that, but I can't remember which one. Perhaps one day we'll have counted places for everything reservable to enforce quotas or distancing (maybe except sleepers) and a real seat allocated only if required, later (and then they will realise they can charge for it!). The new reservation system is capable of doing things entirely differently, but while all retailers are still using the old NRS interface there's a limit to how much new can be done, and of course how much they'd want to change right now anyway.
At the moment a lot of information that should really be in the timetable has come through the real-time system instead (false destinations, via locations), probably due to the inability to change anything about the timetable file format. Expected loading should certainly be in there but maybe would need to be changed reasonably often which also seems to be a challenge for the TOCs. So at the moment this information, where it exists, comes through with the real-time. Actual loading naturally belongs there, it is in the spec but there are changes coming, possibly to a red/amber/green status (like SBB and others), and the information is not being sent at the moment.
If I didn't read this website, I'd have no idea what it meant.
Possibly not. Any suggestions?
