CHAPTER SEVEN: DATA COLLECTION AND DISSEMINATION
Introduction
7.1 This chapter describes how the required accessibility information (data) could be collected by data owners and then gathered together into a single dataset for dissemination to the parties that need the data.
Data aggregator
7.2 It is recommended that an organisation be appointed as a data aggregator for the collection of accessibility data. This could be the existing data aggregator for travel information in Scotland (Traveline Scotland) or it could be a separate organisation charged with collecting accessibility information.
7.3 Given that Traveline Scotland is also responsible for the supply of data to Transport Direct it would seem sensible for Traveline to extend their role to include the aggregation of accessibility information at public transport stops.
7.4 It would be the responsibility of Traveline to collect the existing data into a single dataset and manage the collection of the additional items that are required (we do not recommend that the aggregator performs the collection themselves).
7.5 Having collected the data Traveline will then be responsible for sending regular feeds to the data consumers and ensuring that the data is kept up to date.
Data storage
7.6 The National Public Transport Access Node database ( NaPTAN) is recommended as the most appropriate database for storing stop accessibility attributes because this database already stores basic stop information. The creation of additional accessibility fields which noted the presence of toilets, seating, shelter, kerb heights, telephones etc could be considered for inclusion in the next version of this database. However, given that the latest version (Version 2) has only just been launched, an alternative option would be to develop a parallel feed to NaPTAN.
7.7 For vehicle attribute data it is recommended that a vehicle attribute field is added to TransXChange (a national data standard for the exchange of bus route and timetable information between operators and Traffic Area Offices etc). All stops referred to in TransXChange have a unique NaPTAN reference number or identity.
7.8 The following diagrams (Figures 7.1 and 7.2) show the system architecture and the process that the data aggregator would manage (the data aggregator has been shown separately to Traveline to reflect the fact that a separate organisation could be used). Traveline and Transport Direct have been used as examples of possible end users for the data. The actual end users may be much wider.
Figure 7.1 Data aggregator system architecture
Notes
Arrows represent data flows
7.9 The following key points are shown on the diagram:
- Local Authorities sending data to the aggregator in a variety of formats;
- Operators supplying vehicle data to the Data Aggregator in various formats or to Traveline Scotland using TransXChange 12;
- Data Aggregator delivering standard format data to Traveline Scotland; and
- Transport Direct receiving data either from Traveline Scotland using JourneyWeb or direct from the Data Aggregator.
Figure 7.2 Data aggregator process
Data sources
Local Authorities
7.10 Local Authorities are the main source of data for bus stops and bus stations. As outlined in Chapter 5, a lot of the bus stop and bus station data is already being collected by the Local Authorities in Scotland, so this data should be accepted in the format that they currently store it in. The study team does not see any merit in insisting that Local Authorities change their databases into a common format, in fact we believe that this would hinder the progress of the project.
7.11 However, authorities should be sent a check list of features that journey planning services require information on, such as kerb infrastructure, seating and shelter type, and a date by which this information needs to be included in their databases.
7.12 Any authorities that have not yet collected the relevant data should be encouraged to use a standard format, possibly modelled on the database used by Strathclyde Passenger Transport.
7.13 In order to allow sufficient time for Local Authorities to collect the information not currently held, (ideally via site visits) a minimum of two months should be allowed for actual data collection and data entry. In addition, sufficient advance warning should be given to Local Authorities so that they can plan for the data collection within their work programmes.
Operators -General
7.14 Information on the accessibility of vehicles normally used on a route is held by the individual operators. For rail, there is one main operator in Scotland (First ScotRail) and whilst on board facilities (including wheelchair accessible toilets) vary by train unit, with the aid of a ramp all trains are categorised by the operator as being accessible. For bus and ferry, however, there are several operators and the likelihood of an accessible vehicle being used varies by operator and route.
Bus Operators
7.15 It is recommended that the data aggregator uses existing communication channels with bus operators to identify NaPTAN (National Public Transport Access Node) stops which are served by a dedicated low floor bus service. The likelihood of a stop being served by a low floor bus route could be graded between 1 and 3, with 1 being almost 100% likely (dedicated low floor route) and 3 indicating it is a non dedicated low floor route.
7.16 The middle grading could be used for routes which are dedicated low floor but where the operator does not necessarily use low floor replacements if a vehicle has to be repaired or used on another route. In conjunction with adding the low floor probability index to the stop data, operators should be encouraged by Local Authorities and the Scottish Executive to focus their low floor vehicles on dedicated routes, rather than spreading the low floor fleet thinly around the entire network.
7.17 The data aggregator should also request that operators provide statements summarising their corporate policy on the level of driver assistance given to disabled people waiting at a bus stop, with particular reference to assistance given to people with a visual impairment, who may be unaware of a bus's service number and its destination. This information should ideally be added to bus service records in TransXChange.
Ferry Operators
7.18 It is recommended that the data aggregator creates a ferry checklist sheet outlining onboard facilities. This checklist should be sent out to operators and completed on behalf of each vessel / route operated. Given the small number of operators and vessels in comparison to the bus sector, operators should be encouraged to use a standard template rather than their own. However, there may be merit in allowing CalMac to expand their existing database, due to its existing comprehensiveness and the number of vessels operated.
7.19 In terms of ferry terminal facilities, the data aggregator should create a standard checklist of features, based on the National Enquiries station information page. This checklist should be sent to each terminal manager on a quarterly basis. Storage of this stop attribute data should be on NaPTAN.
Data Consumers
7.20 It is likely that the two main users of the accessibility data will be Traveline Scotland and Transport Direct. The following section discusses how the data could be delivered to them.
Traveline Scotland
7.21 In collaboration with the Traveline community and Transport Direct, Traveline Scotland should define an XML format to deliver the data to Traveline and this format should be put forward to become a national standard. If this is adopted then all Traveline regional systems could begin to support the standard.
7.22 A standard format for delivering accessibility data does not currently exist within the industry, but there are a number of existing standards which can be drawn upon, for example, the delivery of station information to ATOC for the National Rail Enquiries website.
Transport Direct
7.23 Through the use of NaPTAN the Transport Direct portal has a mechanism whereby it could display the accessibility data for stops which are displayed on a route or selected from a gazetteer or map, but there is no similar mechanism whereby vehicle data can be identified and displayed with the vehicles displayed in a route.
7.24 We recommend that all accessibility data be delivered to Transport Direct in the JourneyWeb journey responses which are provided by the Traveline Scotland system as this is the current preferred means of supplying information to the portal. This will require an enhancement to the JourneyWeb protocol.
Standards
7.25 The first task in creating a new standard for accessibility data is to create two record types:
- a record to describe the stop attributes
- a record to describe a single vehicle's attributes
7.26 Once these have been created the records can be used in various ways as described below.
Stop Attribute Data
7.27 The stop data can be delivered in the following ways:
- As part of NaPTAN by adding an instance of the stop attribute record to each NaPTAN record in the weekly NaPTAN feed.
- As a parallel feed to NaPTAN. This would take the form of a document header followed by records which contained a NaPTANID and a stop attribute record.
7.28 A parallel feed of data can be managed on its own timescales and isn't dependant upon the assistance of the NaPTAN system provider.
7.29 For consistency, it is recommended that NaPTAN is the most appropriate database for storing stop attribute records. However, this would require improvements to the existing Version 2, which could take time. Establishing a parallel accessibility attribute database to NaPTAN would enable the Traveline community quicker access to the information required by disabled travellers.
Vehicle Attribute Data
7.30 This vehicle data can be delivered in the following ways:
- As part of a TransXChange feed. Each service record in the TransXChange feed would contain a vehicle attribute record.
- As a separate data feed. This would rely upon a way of uniquely describing vehicles that appear in TransXChange or ATCOCIF files 13.
7.31 We recommend adding a vehicle attribute record to TransXChange.
JourneyWeb
7.32 JourneyWeb is used to describe a journey between a pair of stops, for example, A to B. Each leg of the journey is made up of an origin stop record, a service record to describe the vehicle, and a destination stop record. It is recommended that the stop attribute record and vehicle attribute records be added to the JourneyWeb response so that any relevant accessibility data can be delivered with the journey results.
7.33 It is also recommended that the journey request record be enhanced to provide a means of specifying the desired level of accessibility required in the journey resulti.e. return me a journey which only uses wheelchair friendly vehicles and only interchanges at places with no stairs. Information provided should also include a summary of operator policy on disabled travel and a telephone number for further information.
Summary of data collection and storage
7.34 With regards to overall data collection and storage for the additional accessibility information, it is recommended that Traveline Scotland be appointed as a data aggregator.
7.35 It would be Traveline's responsibility to collect the existing data into a single dataset and manage the collection of the additional items that are required. Having collected this data Traveline will then be responsible for sending regular feeds to the data consumers and ensuring that the data is kept up to date.
7.36 The National Public Transport Access Node database ( NaPTAN) or a parallel feed to NaPTAN is recommended as the most appropriate database for storing stop accessibility attributes. For vehicle attribute data it is recommended that a vehicle attribute field is added to TransXChange.