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.