Chris Gibbard and Paul Drummond of Transport Direct on developments in Great Britain in the electronic transfer of bus service data. Great Britain has a dynamic bus market which permits a bus operator to initiate or alter commercial routes by giving a minimum of eight weeks' notice to a registrar (the Traffic Commissioner). A Local Transport Authority (LTA) neither specifies nor determines such services. In addition to commercial bus routes, an LTA will tender and contract for the operation of those additio
ESBR is now rolling out across Great Britain (Picture: Stagecoach Group)
RSS
Currently, the transfer of the underlying data is far from ideal, it being re-entered manually into systems from paper records. This requires a large amount of effort and is vulnerable to simple typing errors.
Most large bus operators have had electronic bus scheduling software for some time. Many LTAs have databases of from origination, through formal registration with the regulatory body, to all downstream users. A vision was therefore articulated whereby: the bus data supply chain from operator through to all interested parties is completely electronic; the operator creates and owns the data such that it can be re-used effectively and efficiently by all; and value can be added to the data as it moves through the supply chain to the customer. The result would be Electronic Bus Service Registration (EBSR).
The route is described in the TransXChange file by reference to precise points (bus stop locations and junctions through which the route passes) and presented on maps as a series of lines joining adjacent routing or stop points.
There is no map in the TransXChange mfile, just the stop records from the National Public Transport Access Nodes (NaPTAN, see Sidebar) database and the co-ordinates of any road junctions that have been included by the operator.
Operators are responsible for keeping their bus schedules and service registrations up to date. LTAs continue to maintain the bus stop records for their areas.
There is a six-point formal process: an operator creates its application as a TransXChange file and submits it to the UK Vehicle & Operator Services Agency (VOSA); the TransXChange file is tested by VOSA to ensure validity against TransXChange standards; a message is sent via email to the operator and each LTA through whose areas the service passes; each LTA can access the TransXChange file and associated timetable and map PDFs through their VOSA mailbox; the TransXChange file also passes into the VOSA operator licensing system for the attention of a caseworker; and VOSA issues an 'Acceptance' of the file by email and makes available securely to the operator and LTA a PDF rendering of the registered particulars, including maps illustrating the bus route.
476 Arriva and 805 Stagecoach) started with Stagecoach in Cambridge and Peterborough abandoning the use of paper-based systems in February 2008. These operators are planning to extend steadily to their depots nationwide and other operators are now trialling the process within their own systems. EBSR is now well used; 20 per cent of the registrations in November 2009 were lodged electronically.
However, whilst developing EBSR, we realised that we could almost invert this into a one-size-fits-all model, where the bus operator creates a single version of the bus service data from the scheduling system that is suitable for all uses and each user creates a 'window' into this rich data in order to see it from their own perspective (whether light, rich or anything in between).The bus operator clearly owns all aspects of the rich dataset and focuses on creating only a single version of it. The users of this data can create their own window to it so that they can extract what they need. They may also benefit from having the full set of data. For example, the route maps used for registration are significantly improved through the availability of data for all stops (not just the principal timing points) and the road route tracking points - data that is clearly needed for real-time AVL.
Although the registrars receive a richer set of data than they require, they have agreed only to monitor the bus service on the principal timing points, as is currently the case. A partnership approach to learning and evolving means that everyone gains and no one loses.
1889 Transport Direct).
RSS
Chris Gibbard and Paul Drummond of
Currently, the transfer of the underlying data is far from ideal, it being re-entered manually into systems from paper records. This requires a large amount of effort and is vulnerable to simple typing errors.
Exploring electronic transfer
Bus service data is needed by many stakeholders ranging from bus operators to their end customers. The underlying data is required within journey planning and electronic information systems, for paper-based bus timetables and for arrival/departure board information displays at bus stations and some bus stops. Finally, the data is required for regulatory purposes and accessibility planning.Most large bus operators have had electronic bus scheduling software for some time. Many LTAs have databases of from origination, through formal registration with the regulatory body, to all downstream users. A vision was therefore articulated whereby: the bus data supply chain from operator through to all interested parties is completely electronic; the operator creates and owns the data such that it can be re-used effectively and efficiently by all; and value can be added to the data as it moves through the supply chain to the customer. The result would be Electronic Bus Service Registration (EBSR).
Electronic Bus Service Registration
For ESBR, everything that would normally be in a paper-based registration is contained in a TransXChange file (see Sidebar, 'TransXChange and NaPTAN'). The route and stopping places are described and the timetable (with all its variations) is included. The contents of the TransXChange file can be viewed and read using the associated 'publisher' software package, which writes them into a printable (and human-readable) PDF document.The route is described in the TransXChange file by reference to precise points (bus stop locations and junctions through which the route passes) and presented on maps as a series of lines joining adjacent routing or stop points.
There is no map in the TransXChange mfile, just the stop records from the National Public Transport Access Nodes (NaPTAN, see Sidebar) database and the co-ordinates of any road junctions that have been included by the operator.
Operators are responsible for keeping their bus schedules and service registrations up to date. LTAs continue to maintain the bus stop records for their areas.
There is a six-point formal process: an operator creates its application as a TransXChange file and submits it to the UK Vehicle & Operator Services Agency (VOSA); the TransXChange file is tested by VOSA to ensure validity against TransXChange standards; a message is sent via email to the operator and each LTA through whose areas the service passes; each LTA can access the TransXChange file and associated timetable and map PDFs through their VOSA mailbox; the TransXChange file also passes into the VOSA operator licensing system for the attention of a caseworker; and VOSA issues an 'Acceptance' of the file by email and makes available securely to the operator and LTA a PDF rendering of the registered particulars, including maps illustrating the bus route.
Launch and rollout
EBSR was formally launched by the then UK Secretary of State for Transport, Ruth Kelly, in January 2008. The roll-out by the pilot bus operators (Learning and evolving
We started with three 'sizes' of electronic bus service data: Light, with the principal points of the bus service needed for registration; Standard, with all bus service details needed for journey planning and timetable-based information; and Rich, with the additional operational characteristics needed for real-time Automatic Vehicle Location (AVL) systems and arrival/departure boards.However, whilst developing EBSR, we realised that we could almost invert this into a one-size-fits-all model, where the bus operator creates a single version of the bus service data from the scheduling system that is suitable for all uses and each user creates a 'window' into this rich data in order to see it from their own perspective (whether light, rich or anything in between).The bus operator clearly owns all aspects of the rich dataset and focuses on creating only a single version of it. The users of this data can create their own window to it so that they can extract what they need. They may also benefit from having the full set of data. For example, the route maps used for registration are significantly improved through the availability of data for all stops (not just the principal timing points) and the road route tracking points - data that is clearly needed for real-time AVL.
Although the registrars receive a richer set of data than they require, they have agreed only to monitor the bus service on the principal timing points, as is currently the case. A partnership approach to learning and evolving means that everyone gains and no one loses.
Electronic transfer of bus service data
In addition to use as part of a bus registration, TransXChange files can also streamline the transfer of schedules between various parties and/or systems, for instance: bus operators; LTAs; realtime information systems; electronic ticket machines; journey planning systems; and travel and transport information systems and services. This ultimately helps to give passengers confidence in their bus services and enable them to make intelligent travel choices. The increased precision in schedule creation should improve timetable accuracy and speed up the import of data to local and regional databases (and therefore to multimodal journey planning services such as traveline and TransXChange and NaPTAN
TransXChange is a de facto standard, sponsored by the UK
The National Public Transport Access Nodes (NaPTAN) database is a nationwide system for uniquely identifying all the points of access to public transport. Every station, coach terminus, airport, ferry terminal, bus stop, and so on is allocated at least one unique NaPTAN identifier.
The NaPTAN schema is another DfT-sponsored sw facto standart which supports both the public registration of bus timetables by VOSA and data collection for the Transport Direct portal.
On-bus data transfer
There is an array of sophisticated systems which operate on modern buses, including those for electronic ticketing, AVL and passenger information. Such systems will determine the bus's location at any point in time. Bus service schedule data would help to determine where the bus should be. Putting the two together would identify if and by how much a bus is running late. This is useful both for bus operations and passenger information. Bus service data could also be used in electronic ticketing machines to determine fare stages and so on. There is a clear need for and benefit from transferring bus service data between onboard bus systems - ideally in a standardised 'plug and play' way.
From bus to passenger
One further step will take the onboard AVL information from the bus and combine it with schedule data to provide real-time passenger information at bus stops/stations and through mobile phones and internet services.
From schedules to journey plans
Another journey for bus service data is from the operator's scheduling systems through to multimodal journey planning systems. Here, many public transport schedules from many different operators Google Maps. Click on any stop and you will be taken to a link that launches the Transport Direct journey planner with that stop as the origin. In the future there may be further data mashing or novel uses of traditional material. The electronic transfer of bus service data will significantly improve the quality of the data coming in to the journey planning systems that, in turn, will improve the quality of travel information provided to travellers.RSS
