I have been researching the accuracy of rail station disability accessibility information for several years. The difficulty with inaccuracy of such has been recognised by the Office of Rail and Road: (PDF)
Inaccurate, incomplete or unclear information may result in assistance being booked for a journey that involves a station which proves to be inaccessible to the passenger.
… Bookings are ‘designed to fail’ from the outset due to inaccurate station information.
There are long-standing issues with the station information held on the National Rail Enquiries website that affect prospective passengers and booking agents. The working group estimated that a significant number of the station pages on NRE display some form of inaccurate information.
My research compares data in Knowledgebase / National Rail Enquiries against that published in Train Operating Companies’ accessible travel policies.
Research results
- ATP DPPP Knowledgebase compare 2021 – Excel Spreadsheet comparing and giving results
- ATP DPPP Knowledgebase compare 2021 no queries – Excel Spreadsheet without queries / connections (designed to update from data sources, which result in security warnings)
- Intro and Instructions – PDF introducing and explaining how to use the spreadsheet.
So for Britain’s 2,500+ stations, 2,190 (85%) have some item of accessibility data differ between the ATP / DPPP and National Rail Enquiries. For example, of those stations that have information on the provision or otherwise of accessible toilets, 154 (13%) differ between the two information sources – either National Rail Enquiries says there is an accessible toilet and the ATP says there isn’t, or vice versa.
Lobbying Rail Delivery Group
I’ve been emailing the Office of Rail and Road, Train Operating Companies and Rail Delivery Group about this. Here’s an extract from my most recent email to Rail Delivery Group.
DPPP/ATP vs Knowledgebase comparison
I have many thoughts and experiences with Knowledgebase, predominantly through my research into consistency of accuracy in station accessibility feature information between different sources – e.g. DPPPs/ATPs, Knowledgebase and TOC accessibility maps. Like the ORR, I have significant concerns about its accuracy.
Such isn’t an academic exercise: I have had multiple experiences with such information being inaccurate causing me difficulties on the ground.
I attach a spreadsheet showing a comparison of station information from Knowledgebase against that in their DPPPs / ATPs. There are significant differences. Whilst some of these differences may be due to the comparative ages of information – e.g. station features for stations in DPPPs written up to 4 years ago may well have changed – the number of discrepancies is too substantial for this to account for it.
Examples include the 296 stations where the ATP says there’s a disabled toilet but Knowledgebase says there isn’t (have they all been closed since the DPPP / ATP were published?!) and the 42 where Knowledgebase says there is an accessible toilet but the ATP / DPPP says there isn’t.
And many, many, many more. The spreadsheet shows inconsistencies in 2194 of the 2586 stations’ accessibility data. For those 2194 stations at least one element of accessibility data differs between Knowledgebase and the station information in the relevant ATP / DPPP. Many stations have more than one such discrepancy – across those 2,194 stations, there are 6,145 instances where an element of a station’s accessibility information differs between that stated in the DPPP/ATP and that in Knowledgebase. (That’s excluding instances of such information being missing from Knowledgebase.)
Structural errors
More concerning to me is that the structure of Knowledgebase simply makes it impossible for station operators to input accurate information.
Take “Step Free Access Coverage”.
The current Knowledgebase Data Feeds Specification and the Developers Guide for the Stations V4 XML Feed say:
<StepFreeAccess><Coverage>
Coverage of step free access. Contains 1 of the following values: wholeStation / partialStation / allPlatforms / noPartOfStation / unknown.The RDG Knowledgebase Stations Data Feeds Specification has been updated and re-signed off on a regular basis, and was signed off in 2019.
The Knowledgebase Stations XML schema confirms:
<xsd:simpleType name=”StepFreeAccessCoverageEnumeration”> <xsd:restriction base=”xsd:NMTOKEN”>
<xsd:enumeration value=”wholeStation”>
<xsd:annotation><xsd:documentation> The whole station is accessible, including all platforms and ticket office. </xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value=”partialStation”>
<xsd:annotation><xsd:documentation> Parts of the station are accessible. Used when neither allPlatforms nor wholeStation are applicable. </xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value=”allPlatforms”>
<xsd:annotation><xsd:documentation> All platforms are accessible, but not the ticket office. </xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value=”noPartOfStation”>
<xsd:annotation><xsd:documentation> Neither the platforms nor the ticket office are accessible. </xsd:documentation></xsd:annotation></xsd:enumeration><xsd:enumeration value=”unknown”>
<xsd:annotation><xsd:documentation> Accessibility details are unknown. </xsd:documentation></xsd:annotation></xsd:enumeration> </xsd:restriction> </xsd:simpleType>I therefore don’t understand why it is not currently possible for station operators to select “partialStation” or “allPlatforms” – and why all stations are thus arbitrarily classified as having full or no step-free access. The XML data feed specification is signed off year after year, going through a formal review process, and remains with these options in, yet they aren’t actually possible to select; in actual fact only “wholeStation” or “noPartOfStation” can be selected.
One wonders: what is the point in having a formal specification and schema approval process, if the resulting document isn’t accurate nor followed? But more importantly: what is the point of having this crucial information in Knowledgebase, given that its implementation means the information it holds simply can’t be trusted?
Micky Ball and Michael Adlington recognised in 2017 that this needed to be changed. So did Scotrail, who emailed me in 2017 to say:
“ScotRail is experiencing difficulties with updating the ‘Step-free access coverage’ section due to a technical issue with the NRE website, which is only allowing for ScotRail to tick ‘Yes/No’ for this field without the option to edit text. This is an issue that can only be addressed by Rail Delivery Group, which ScotRail has requested be addressed as quickly as possible.”
Other anomalies include: there’s a field for “Station Categorisation”, presumably Step-Free Access Categorisation using the ORR’s definitions – but it’s only filled in for 235 stations (GTR’s), and in any case it only allows a single-character entry, so not “B1, B2 or B3” as described by the ORR.
Every station (all 2,500+) is down as having an “induction loop” – even those that have no ticket offices, audio announcements, or help points, so I question what audio information can be being provided over induction loops at these stations!
“Last Changed” doesn’t update for some stations – e.g. Knowledgebase claims Maybole’s data was last updated in November 2016 yet the Step Free Access Note states “This is a Category A Station” – a categorisation invented by the ORR in 2019.
TOC accessibility managers tell me that they spend considerable time and money surveying access features at all their stations, provide this information to NRE, mass-upload it – then find that the database has been reverted to an earlier version, undoing all the updates, without the TOC even having been informed.
This simply doesn’t work.
Knowledgebase replacement deadline, and interim issues
The Knowledgebase replacement has been promised for many years. I was promised it by the end of 2016. Micky Ball and Michael Adlington promised it by the end of 2017. There have been any number of slipped deadlines and so on.
I now understand that the replacement is not likely to be implemented until the end of 2022? I’d be grateful for any information on this process and deadlines.
I guess the above issues, and many more, show why such a replacement is needed. The problem is: the existing system isn’t viable in the meantime. It has been creaking on for far too long, unloved, unmanaged and left to rot (to say nothing of Stations Made Easy); with work-around after work-around.
The result is that disabled people suffer. I suffer; the frustration of attempting to find accurate information for planning and booking journeys, finding “on the ground” that journeys I wish to complete aren’t actually possible; that I can’t hear announcements or that I can’t go to the toilet and so on. And so do others.
I would argue that the existing system must not be expected to last until it is replaced; especially as the replacement timescale may well slip, given the RDG’s planned Knowledgebase replacement has suffered so many slipped deadlines already (and similarly the Passenger Assist app etc.) It would seem that the ORR are of a similar mind: I have been collaborating with them for their current audit of the accuracy of station accessibility information, and I’m aware of what emphasis they (rightly) place on such.
What can be done about it?
Can I help?
As you have probably gathered, I care about this a great deal. Accurate information about accessibility is every bit as necessary and important as accessibility itself: neither is of any use without the other; and this seemingly dry subject has a real, human, cost on disabled people’s ability to access public transport.
The spreadsheet shows potential inaccuracies in 2,194 of 2,586 stations’ data.
So: what would be practicable? How can I help to ensure the accuracy of information in Knowledgebase until the new version is released? How can I contribute to ensuring the new version is more fit for purpose than the current mess? And how can RDG, as owners of this data, improve this?
Hopefully Rail Delivery Group will respond positively to the email above and actually do something about this egregious and potentially harmful access information provision failure.
I don’t understand why an AI system can’t be designed that is updated by every user which would include staff. Amazon collects information from all their customers (often too much information) and apps like WAZE is used by motorists which gives live updates of incidents, accidents and even identify where police are. A solution like this would obviously only solve the problem of getting up to the minute and accurate information. This, unfortunately, would not solve many of the other organisational shortcomings.
Seems to me there are two problems here. The bigger one is the IT systems appear to be preventing the data being corrected and the other is the data quality itself. I think there needs to be an interim system whereby there is someone who checks the information with every booking where the person booking isn’t already familiar with the stations etc. Also a check needs to be made on whether the toilets, lifts etc are out of order at the time of booking and, say, 24 hours before the journey. Once they have solved the IT problems they need to employ someone (eg Doug Paulley) to ensure the data quality. At the moment I believe the data is added by station staff who are not experts in accessibility and don’t appear to have been either trained or motivated to do the job properly. I can envisage a scenario where this person takes on board feedback from users and also talks station staff through what they should be looking for in adding/correcting their data. Of course in an ideal world such a person would visit stations themselves but I can’t see the funding being there for that and it would be difficult for a user with accessibility needs and therefore understanding to do so.
I agree.
Years ago, a group of access consultants were commissioned to visit every station in the country and document the access and facilities comprehensively. Stations Made Easy https://www.raildeliverygroup.com/media-centre-docman/archive/302-2009-12-stations-made-easy/file.html . (PDF). It cost something like £1.2 million.
Sadly, the DFT and so on didn’t provide funding for its upkeep. So this marvellous, detailed tool has just been left to moulder and get increasingly out of date.
I think redoing the whole survey, and taking TOC station managers etc. out whilst doing it, would be an excellent thing. As would having the database run by somebody with considerable more competence and commitment than RDG.