Guidance

Bus open data implementation guide

Updated 11 December 2020

Buses are the most used form of public transport. Across England, over 50% of public transport trips are made by bus and the sector is responsible for creating 123,000 jobs and £6 billion gross domestic product (GDP). Buses also support lower congestion. In central London, they account for 38% of distance travelled, taking up only 9% of road space. Buses are mostly used by the young, the old and those on lower incomes, with disabled people making 10 times as many journeys by bus as by rail.

Annual bus statistics for England 2019/20 published in October 2020 showed that the number of local bus passenger journeys in England fell by 6.2% outside London compared with 2018/19. The fall in the number of local bus passenger journeys across England totalled 238 million.

The release of open data by Transport for London (TfL) in 2007 has recently been evaluated in the Deloitte report Assessing the value of TfL’s open data and digital partnerships (PDF 4.42MB). TfL is now generating annual economic benefits and savings of up to £130 million for travellers, London and TfL itself with 42% of Londoners reporting they use an application powered by TfL data and 83% reporting they use its website. Similarly, for routes that offered real-time service updates, TfL reported a 2% uplift in patronage when compared to routes without real-time information.

And yet, if you look across England more broadly, the availability and quality of information available to passengers when planning their trips, waiting at bus stops, or travelling to their destinations varies considerably. Whilst some operators and local authorities publish route and timetable information, and a national open dataset on routes and timetables is available through Traveline, no consistent approach currently exists in England for the open publication of bus data.

Research conducted by Transport Focus, the independent passenger watchdog, has found a strong desire amongst bus passengers for more centralised sources of information about bus times, routes and fares. The Bus Services Act 2017 seeks to address this. The act provided powers for the Secretary of State to require bus operators and/or local transport authorities (LTAs) to openly publish information about bus routes and timetables, stopping places, fares and tickets, location information and more broadly the operation of bus services.

Once the data is open, technologists will then be able to register for an account and access this data. This will enable the technology sector to create end-user applications and digital products or services that will help users with journey planning. Our overall ambition is to improve the information available to bus passengers, making it easier for them to make informed travel decisions based on complete, accurate and timely data.

In May 2020, the Public Service Vehicles (Open Data) (England) Regulations were laid before Parliament and published on legislation.gov.uk. The regulations were subject to the affirmative procedure and actively debated and approved in both Houses.

The bus open data regulations were made in July 2020 and will come into effect from 31 December 2020. This non-statutory guidance document is being updated to take account of changes since the launch of the Bus Open Data Service (BODS) in January 2020 and following the making of the legislation.

This guidance is intended to serve as a practical guide to help bus operators and local authorities meet their new statutory requirements as well as encourage application developers and technology providers to use the data, innovating to create applications, products and services that passengers want and need.

The Bus Open Data Service

Overview

Operators of registered local bus services in England (outside London) are to be required to make details of their services available as open data, as required by the Bus Services Act 2017. The scope of open data encompasses timetable data, fares data, vehicle location (real time) data and historic performance (punctuality) data.

The open data requirements are phased, with the first set of requirements - to publish timetable data - coming into effect from 31 December 2020.

This will be followed by:

• location and simple fares by 07 January 2021
• punctuality data for the preceding calendar year (August to December 2020) to be provided by 31 March 2021
• complex fares data by 7 January 2023

This guidance has been updated to include details on publishing location and simple fares, and on the new Analyse Bus Open Data Service, which will support operators in providing punctuality data.

The Department for Transport (DfT) is helping operators meet the statutory requirement through the provision of the Bus Open Data Service (BODS). It’s a new digital service which provides access for third-party data consumers to a distributed model of bus open data, where the data is, largely, held by the operators who run the services.

BODS was launched in January 2020. The timetable service was made publicly available at the same time, allowing operators to become ‘early adopters’ of the service and start publishing their data ahead of the statutory deadline. We’ve been helping operators to learn how to use the new digital service and the data creation tools provided with it. We now have 340 operators registered onto BODS ^{[footnote 1]}. And, we’ve had 109 operators publishing their timetables data, including 4 of the ‘Big 5’ bus operators.

In October 2020, we added the location data service to BODS and now have 79 operators publishing approximately 10,000 vehicle location feeds (out of 32,500 vehicles). The BODS fares data service was also made publicly available in November 2020. We now have 14 operators publishing 160 datasets.

DfT will continue to offer business change support to bus operators during the transitional period, which is scheduled to run until December 2021. We’d encourage operators to continue to engage with the Bus Open Data team and take advantage of this opportunity.

Timetable data indexed in BODS as of 16 December 2020.

A map of the United Kingdom with the geo-location of all the timetables and routes highlighted in different colours which have been published onto the Bus Open Data Service as of 16 December 2020.

Accessing the system

At the beginning of 2020, the Bus Open Data Service (BODS) was launched, and organisations were invited by email to become ‘early adopters’ of the service. The email contains a link, which operators can use to register for an account for the service.

If you run a local bus service in England, you should have received an email inviting you to register. If you’ve not received an email, or you’re a new operator, please contact the Department for Transport (DfT) at bodshelpdesk@kpmg.co.uk. We’ll arrange for a link to be sent out for you to register for an account so that you can access the system.

The links expire after 72 hours, therefore, it’s important to use the link promptly to register for the service. If the link is not working, it’s likely it’s expired. Please contact bodshelpdesk@kpmg.co.uk to obtain a new link to register for an account and make sure that the new registration link is used promptly. If you’re still experiencing issues, please email us at bodshelpdesk@kpmg.co.uk.

Group bus operators or bus operators with multiple depots may choose to split their data publishing across multiple sites. In those instances, DfT advises that the central office or headquarters registers for an account with BODS and that the central office adds its system administrators to the system using the permissions settings. This will enable regional depots to each have access to the system to publish open data for regional level bus services. However, it also offers the group a central overview and the ability to monitor compliance with the group’s legal obligations.

DfT is currently offering business change support. And this includes assisted digital services offered both at local authority and central government level.

We’ve helped over 200 bus operators with a business change team focused on working with operators on publishing processes, with a plan to invite and register all operators by the end of 2020.

We started workshops across multiple regions during 2019 which were attended by over 100 operators and, due to social distancing restrictions in 2020, have instead adapted to hosting webinars to support operators. We’ve also provided local authorities with ‘how-to’ guides and hands-on training on how they can support operators.

The BODS team continue to keep in touch with stakeholders through the monthly newsletter and regular online meetings and phone calls. Once social distancing restrictions are lifted, we hope to meet with operators again through face-to-face workshops and sessions. Any planned future events will be publicised through the newsletter, please email busopendata@dft.gov.uk to subscribe and keep up to date with future activity.

Using an agent

Bus operators can use an agent to generate data, including timetable, fares and location data on their behalf as part of BODS. Agents are defined as people outside the operator’s organisation that can publish data on behalf of an operator. This service is being provided in response to requests from smaller operators who may not have the time or resources to upload and publish their own data. This service will look and feel similar to setting up an accountant on the HMRC tax service.

It’s expected that agents and operators will have contracts establishing the services and expectations with agents, before allocating them as an agent on this service. The statutory requirement to publish data on BODS will remain the responsibility of the operator. Therefore, we would always recommend that, when working with an independent service provider or agent, you have robust contractual provisions in place to ensure that a legal remedy is available in the event your agent or provider fails to host your data, due to their solution being compromised without resolution.

To be able to set up agent mode, bus operators will need to be registered on BODS first. Please contact bodshelpdesk@kpmg.co.uk who will send you an invitation. Once you’ve registered and set up an account, the operator will need to be signed in, and will then be able to email an invitation to the agent of their choice who will then be able to accept the request.

If you’re an agent working with multiple bus operators, you’ll be able to navigate easily between operators and datasets using the navigation tools on the website. When an agent publishes data, all admin users will receive an update about this. Agents will be able to publish one or all of the data types, can host the data on the operator’s behalf, create fares data, publish live location data and respond to feedback or data-quality issues.

Local authorities can act as agents if appointed by operators, but not all agents will be local authorities. There may be occasions where a bus operator would like to appoint a not-for-profit organisation or a private consultant (such as a transport data expert) to generate data on their behalf. We recommend speaking to your local authority to discuss this if you need support choosing an agent.

Using the Bus Open Data Service

Overview

The Bus Open Data Service (BODS) and its design is based upon a distributed model of data publishing, with bus operators publishing data at source through the service provided by the Department for Transport (DfT). All data can, as a result, be discovered by application developers or anyone wishing to use the data. The onus for publishing bus datasets is placed on bus operators who we believe are best placed to preserve the integrity, quality and provenance of that data.

However, some smaller bus operators expressed concerns about their ability to publish their own data, which is a key feature of BODS. Therefore, DfT will offer data hosting for smaller bus operators, defined as operators running 40 services or fewer, and currently support operators through the business change period. This will support smaller bus operators to comply with the regulations by removing the burden of establishing data publishing mechanisms.

Data you need to publish

Operators and local transport authorities (LTAs), for areas where franchising is in place, are required to publish data for local bus services across England outside London. This includes cross-border services (that is, services running into and outside of London and Scotland or Wales into England) for the English leg of the journey only if there are stopping places in England (outside London). However, we realise it might be more practical for operators to publish data for the entirety of their cross-border services.

This means that, if the part of the service that crosses the boundary of London into, for example, Essex, also has stopping places there, this part of the route in Essex will be treated as a separate service from the part in London and will fall within the scope of the BODS.

Services that are out of scope of legal requirements for data publication include:

• those operating under Section 19 or Section 22 permits
• coach services
• tour services
• unregistered closed school services or those services which have been voluntarily registered as closed school services

But tour services are not exempt if they take any passengers on point-to-point journeys rather than a full tour. All other local bus services are in scope for data publication.

However, operators who wish to provide data on services that are not in scope may do so using the defined Bus Open Data TransXChange (TxC 2.4) profile. For instance, publishing school services data has helped parents and students to have access to school bus tracking apps so that students arrive at school on time, and bus operators can deliver efficient journeys.

BODS is the channel mandated for data publication to meet the statutory requirements. However, this does not prohibit operators from sharing data in other ways in addition to publishing it to BODS and we’d encourage operators to do so. In addition to this, LTAs will be required to maintain and update data about bus stops by 31 December 2020, which is the latest date to comply.

This data, however, will not be published through BODS but will continue to be maintained through DfT’s National Public Transport Access Node (NaPTAN) database. Operators will also be required to provide punctuality reports for the previous calendar year, starting from 31 March 2021. For the first year, it’s expected that in some circumstances operators may only be able to provide punctuality data for the period from August to December 2020 if the punctuality report is being provided using data within BODS. More detail about this is included in the Analyse Bus Open Data Service.

Automatic vehicle location data and fares and tickets data (basic fares) will need to be provided to BODS by 7 January 2021. Complex fares and ticket data will be required by 07 January 2023. Punctuality data will be required by 31 March 2021 and 31 March of subsequent years, for the preceding calendar year but in the first year only for the period August to December 2020.

Organisational readiness

BODS can be accessed through your web browser from desktop and laptop computers. Bus operators can link or upload their data via the Publish Bus Data Service.

If you’re a bus operator, you’ll need to make sure that you’re aware of your National Operator Code (NOC). The NOC is used to uniquely identify every bus operator in England, Wales and Scotland. This data is contained within an online Traveline database and is often used for the creation of Traveline data and within a range of datasets in the transport industry.

It’s best to find out in advance what your NOC is it’s a requirement for BODS. The NOC database can be accessed through the Traveline NOC dataset. An example of a NOC code can be seen below:

NOC code	Operator Public Name	Mode	Group
FECS	First Norfolk & Suffolk	Bus	First

Your organisation will also need access to the service registration number for each of your registered services, for inclusion in the TxC data file. This will be a required data attribute as it will enable the department to cross-reference registered local bus services against published local bus services and identify any data publishing gaps. The Office for the Traffic Commissioner (OTC) publishes a list of all registered local bus services which includes services registration numbers. The local bus service registration list is updated on a weekly basis.

We recommend that you arrange for key staff to familiarise themselves with BODS in advance of the statutory duty coming into effect so that you’re confident that you have all the necessary arrangements in place. If you currently use transport data management software or a scheduling system to create timetable or routes data, please refer to help and guidance provided by your system supplier on how to create TxC files.

Your organisation may already have procedures for creating and publishing bus open data including timetables data (TxC), fares data (NeTEx) and location data (SIRI VM). DfT will make operators aware of updates to standards and protocols through the Bus Open Data GOV.UK site, supported by updates via GOV Notify in the Bus Open Data newsletter or as bespoke notifications. These updates will also be made available to the OTC and Driver and Vehicle Standards Agency (DVSA) to notify local bus service operators through their regular publications.

If you intend to put timetable data on your website for the first time, you will need to go through the appropriate internal IT procedure. You may want to connect your transport data management system to publish data to your website automatically. Once your Uniform Resource Locator (URL) has been provided to BODS, this will automatically update your data on BODS whenever you update your routes and timetables data on your internal systems. If you’re publishing your data on your own website and providing it to BODS through a URL, it will be your responsibility to ensure an appropriate data hosting solution is in place.

Small operators

If you’re a small operator, running 40 registered services or fewer, you can upload your data file to BODS, and you do not need to host it yourself. The data files may be created using your existing transport data management software and uploaded to BODS.

Alternatively, if you do not have access to such software, you may wish to use the Bus Open Data Timetables tool to create a TransXchange 2.4 file for BODS. This tool is provided on a free-to-access basis as part of the service. Once the data files have been created and uploaded to BODS, DfT will provide the required hosting solution.

Medium and large operators

All other operators, running more than 40 registered services, can either publish the data on their own website (we recommend that you do this) or through an appointed independent service provider who can host the data on your behalf. However, it’s your statutory responsibility to ensure that your hosting solution is reliable and the data is available. Therefore, we would always recommend that when working with an independent service provider or agent that you have robust contractual provisions in place to ensure that a legal remedy is available in the event your agent or provider fails to host your data due to their solution being compromised without resolution.

Before visiting the BODS website, you’ll find it useful to have already generated the TxC 2.4 file or link that you intend to share. Should BODS become unavailable for any unforeseen reason, we’ll seek to resolve this within 24 hours. Furthermore, even if the service is offline, TxC 2.4 data files can be created using the TxC tool in preparation for provision to the service once it’s available. If the service is unavailable for a period, Traffic Commissioners will not penalise operators for failing to upload data during that period and DfT will notify operators as soon as BODS is back online.

The tool is available for use by all bus operators. However, we’ve noted that this has been mostly beneficial for small and micro operators who require it to create timetable data files.

This provision has made it easier for smaller operators to provide their data to BODS. Most small operators are either time or resource-constrained. Yet they are often also operating important local bus services that are often socially necessary. We understand that these operators will be sensitive to additional costs which might impact their business. However, we’re committed to ensuring that such operators can continue to run their vital services.

Publishing timetable data

Overview

The Bus Open Data Service (BODS) launched in January 2020 so that operators could have a year to publish their timetable data ahead of the requirements coming into effect from 31 December 2020. We’ve been accepting timetable data in all major versions of TransXChange and, from 2021, we’ll require that this data is published using TXC version 2.4 only.

Example of an interactive map which shows geo-location of timetable and routes data for a bus operator and their route in a specific town.

Timetables data standards

Timetable data must be published using TransXChange (TxC), the agreed industry standard for the publication of schedule data. During 2020, we’ve been accepting all major current versions of TxC to include versions 2.1, 2.4 and 2.5. We’ll eventually expect operators to upgrade their systems/processes and upskill their staff to provide data using TxC 2.4 from 2021.

The reason we’ve selected TxC 2.4 is, based upon expert advice, that this version addresses many of the glitches and issues present in version 2.1 and many of the technology suppliers have adapted their systems and technology to handle this version. Our research also suggests that many operators are currently capable of creating a TxC 2.4 timetable data file.

Accessibility data

Whilst TxC 2.5 does include accessibility data, for example, whether the vehicle has low floors or kneeling devices, we’re aware that many bus operators are still not using this version. Similarly, some technology suppliers have not yet adapted their products to deliver a 2.5 export. Therefore, we feel that TxC 2.4 strikes the right balance in terms of its development and industry maturity, enabling a smoother implementation in the long run.

However, we remain committed to ensuring bus operators are still able to supply accessibility data onto BODS which will be important in providing accessible travel options within journey planning applications. We’ve ensured that some accessibility fields are included within the TxC 2.4 data standard as optional fields, and would encourage bus operators to provide this data.

In TxC 2.4, there’s a block of information that can be provided, which is attached to a vehicle record, including:

• whether a vehicle is wheelchair accessible
• if there’s passenger information on-board
• how many wheelchair spaces are available and if they need booking in advance

We’ll continue to review the collection of this data to establish whether we need to legislate and require operators to provide this data to realise benefits for those with accessibility needs.

What data is required?

The final Bus Open Data (BOD) TxC 2.4 profile has now been released, and many of the major scheduling software suppliers have created BODS compliant 2.4 exports which are currently being released to enable operators to meet the new statutory requirements by 31 December 2020. The version of the Bus Open Data TxC 2.4 profile that operators will be required to comply with for the statutory deadline is v1.0. The TxC 2.4 profile includes additional types of data that are not specified in the regulations but will be required for the file to be successfully validated and published through BODS.

The route and timetable information must include the following information that’s stipulated in the regulations:

• the name, and where applicable the trading name, of the operator
• the operator’s National Operator Code (NOC)
• the number of its public service vehicle operator’s licence applicable to the service
• the number or name of the service
• the number under which the service is registered with a traffic commissioner (except in areas where a franchising scheme is in operation)
• the route of the service, including the principal starting and finishing points
• the stopping places of the service in the order of stopping
• information to ensure identification of a stopping place, comprising — the stop code, taken from the National Public Transport Access Nodes ^{[footnote 2]} database: and includes: the Ordnance Survey grid reference, relevant landmarks, a topographic reference taken from the National Public Transport Gazetteer ^{[footnote 3]}, and an indication of whether the stopping place is used as a timing point
• the arrival and departure time (defaulting to departure time) at each stopping place or, where applicable, the frequency of the service
• the days on which the service runs, or is to run, and any public holidays or other days on which the service does not run
• where a service is provided for the purpose of serving a school, college or other educational establishment, the dates of terms for that school, college or other educational establishment
• any change in the information provided under sub-paragraphs (a) to (j) and, where the service has been or is to be terminated, information about the termination

In relation to topographic references mentioned in point (h), the National Public Transport Gazetteer provides a topographic database of towns and settlements in the UK. It provides a common frame of reference for the National Public Transport Access Nodes (NaPTAN) schema and other UK Public Transport Information schemas such as JourneyWeb. It provides a useful way of describing places and towns.

School services

Under the requirements, operators that run school services – those which are required to register the service with the Traffic Commissioners (TCs) under section 6 of the Transport Act 1985 – will need to publish this service. If the service is a closed school service (meaning, only pupils, parents or staff) and is commissioned by a local authority in pursuance of its legal obligations or powers and so is not required to be registered (with the Traffic Commissioner), this will not need to be published.

However, we understand that in some instances local authorities have asked for these kinds of school services to be registered. If you’ve voluntarily registered a closed school service in response to a request from a local authority, then this will not fall within scope of the regulations as it is not registration under section 6. If you’re publishing details of a registered, closed school service, the ‘CLOSED’ field should be selected in the TXC file.

New registrations

For new registrations of local services, the process for publishing open data will be aligned with the process for applying to a traffic commissioner for registration of the new service. The date when the application for registration of a new service is made to a traffic commissioner (the 42-day period), is the last date by which the data should also be provided to BODS.

Variations and updating data

Most timetable changes will result in an application to a traffic commissioner for a variation of the registration. From 31 December 2020, we’ll require operators to submit open data updates for all timetable changes, both where they trigger a variation to the registration and where they do not. This is because passenger applications, products and services require complete, current and accurate data regarding timetables to enable passengers to plan their journeys effectively.

Variations requiring an application to a traffic commissioner (that is, where there are alterations which trigger the need for formal registration of a variation) are required to be submitted to BODS by the time of the application going to the Transport Commissioner (TC) for final review (the 42-day period).

For changes that do not trigger the variation to the registration threshold, these can be made to the BODS file at any point prior to the change coming into operation. For example, if the timetable change were to come into effect today at noon, the operator would legally be able to update their open data file up until 11:59am.

Those operators publishing their data through a URL which is automatically connected to their scheduling software, when the file is updated in your existing transport data management software, the data endpoint ^{[footnote 4]} will automatically update on BODS. BODS will be programmed to search for new and updated links twice daily. Once searches are complete, if a change is identified, a notification will be sent to you and may ask you to log into the system to check the data quality report, review the feedback and address any issues prior to publication.

Therefore, if you’re an operator sharing data through a URL, we strongly encourage operators to update the data at least 2 days before the change (which does not trigger a variation to the registration) is due to come into effect. This will ensure that BODS has discovered the new data end-point and application developers have been able to refresh their data in a timely manner.

If existing data files for local bus services that have already been published to BODS need to be updated due to variations or changes that don’t trigger the application for variation threshold, it’s a legal requirement to make sure that the file on BODS is also updated. This will help application developers offer complete and accurate data to passengers when journey planning.

Cancellations and removing data

If you’re planning to cancel a bus service, you’ll need to notify the local transport authority of your intention and apply to the Office of the Traffic Commissioners for cancellation of the registration. Once you’ve confirmed the final date that the service will cease to operate, it’s important - and a legal requirement - that you update the TxC 2.4 file or link in BODS. Otherwise, application developers will potentially create products and services that suggest the service is running.

There are 2 main ways in which the data can be updated. It may be that you wish to add an end date for the file that corresponds to the service that’s being cancelled. The end date or expiry date should correspond with the final date that the service is running.

Alternatively, if you’ve published your service data in one file with multiple lines, it may be that you wish to update your TxC 2.4 file with 2 datasets - 1 dataset that corresponds to current services and is dated to run until the service in question is cancelled. The other dataset contained within the file should correspond to the future service provision and should be dated to run after the service in question has been cancelled.

Either approach to updating your files is perfectly acceptable. Ultimately, it’s a decision for your organisation to make and will most likely be influenced by your data managers’ and staff preferences, current organisational processes and the needs of your passengers.

Once the service has been cancelled, and the file deleted from your list of published services, it’s worth noting that your organisational administrators or agents using BODS will still be able to find the data on the site in the list of archived datasets. It will be marked as an expired dataset.

Holiday periods and temporary timetables

In respect of the Easter week, Christmas week and any other weeks containing a Bank Holiday when operators may need to run temporary timetables (for which an application for variation of the registration is not required), we would strongly encourage bus operators to publish their temporary timetables to BODS at least 7 days before these come into operation but ideally if business operations permit, up to 14 days ahead of operation.

Holiday periods are a key opportunity for bus operators to grow patronage and a time when non-bus users may consider using public transport. Up-to-date and accurate information is vital to ensure that they can plan a future trip and have a positive experience and maybe the difference between such passengers continuing to use the bus in the future or simply reverting to their mode of choice such as a car.

A nominal notice period of 1 to 2 weeks enables data consumers to download the data from BODS and ensure their applications, products and services contain up-to-date and accurate information for those passengers using buses during the public holiday periods or other periods when temporary timetables are in effect.

Publishing fares data

Overview

The Bus Open Data Service (BODS) regulations will require the open publication of fares and tickets data. From 7 January 2021, operators will be required to publish simple fares data. This will be followed by complex fares and tickets data by 07 January 2023.

The BODS fares service was launched in November 2020. The BODS fares service will accept the simple fares such as single, some zonal and period tickets transformed into NeTEX format. However, operators may need to provide some of the information required under the complex fares requirements. Since July 2020, early adopters have been able to publish data using the Transport for North Fares Data Build Tool which is now renamed as the ‘Create Fares Data’ service.

Fares data standards

There’s been a lack of data standards for fares and tickets in the industry. This has led to a barrier to publishing data. In 2019 industry-standard leads developed the UK NeTEx profile for fares to standardise the publication of fares data within the UK bus industry.

NeTEx is a highly interoperable CEN standard that can be used to represent aspects of multi-modal transport networks, allowing the quick and easy exchange of static data, including both timetables and fares. For this reason, NeTEx may be considered for expanded use by the Department for Transport (DfT) and the European Community as the data standard of the future.

The UK NeTEx profile allows for accurate representations of operators’ fares offerings to the market, which can then be accessed and used in journey planning applications. This standard will be interoperable across EU countries, can be used across modes, and is now being updated to include travel for e-scooters and other micro-mobility options.

You can find more information on the UK Profile and the schema on FareXChange and NETEX STANDARD

Publishing data using Create Fares Data

Operators will be able to use the free Create Fares Data service to produce their own data in NeTEx standard format. The tool has been developed by Transport for the North (TfN).

Screenshot of the ‘Create fares data’ homepage. It has links for users to create fares data and for data consumers to download fares data.

Screenshot of the ‘Select a fare type’ page of the ‘Create Fares Data’ service. The page states the bus operator’s name and a list of ticket options for single selection that includes:

• single ticket - point-to-point
• period ticket (day, week, month and annual)
• return ticket - single service
• flat fare ticket - single journey
• multi-operator - a ticket that covers more than one operator

Operators can create NeTEx for all ‘simple’ ticketing products covering all passenger types:

singles and returns period passes (both geographic and services-based) group tickets multi-operator tickets

Associated information around age and time restrictions or methods of payment can also be defined.

The Create fares data service will be free to use for bus operators and local transport authorities (LTAs). The tool combines fares tables and rules with timetables data and outputs this into the UK NeTex profile. Operators can appoint an agent to use the service on their behalf.

Publishing if you have an electronic ticket machine

Operators who have Electronic Ticket Machine (ETM) suppliers can talk with them about hosted NeTEx solutions. A large proportion of fares data already resides within ETM systems. This can be leveraged to provide data in NeTEx standard format to BODS. There may be a need for additional product development, so ensure your needs are understood by your supplier.

Operators providing 40 or fewer local services can provide fares data to the service either through providing a URL link to the hosted NeTEx file or by uploading NeTEx files directly.

Screenshot from the BODS website showing options for operators to provide fares data through a URL link or by uploading a file.

Simple and complex fares

‘Simple fare and ticket information’ means information about:

• adult single and return fares and tickets
• child single and return fares and tickets
• group fares and tickets
• period tickets
• single operator fares and tickets
• multi-operator fares and tickets
• zonal fares and tickets
• how fares can be paid
• which tickets can be purchased in advance and which can only be purchased onboard a vehicle
• age restriction
• time restrictions

‘Complex fare and ticket information’ means information about fares that vary depending on:

• the route taken
• the duration of the journey
• the type and the number of passengers
• the method of payment
• the amount of subsequent travel undertaken in a given period
• whether a discount or cap are applied to the fare

It’s been agreed with industry stakeholders that for fares data to be represented accurately within BODS, we’ll require some complex information to be published alongside the simple-fares requirements.

From January 2021, operators should also provide data that includes the type and number of passengers as well as the method of payment. For example, this will inform the age specified for child and adult tickets and the number of people allowed for group tickets. It will also ensure that ticket prices affected by payment methods are also represented for passengers.

This will ensure that the published data provides the appropriate level of information required by bus passengers to make informed decisions, and increase passenger trust.

Updating and changing fares data

The regulations state that any changes to services relating to fares and ticketing must be shared through BODS anytime up until the change in pricing comes into effect. This will allow bus operators to respond quickly to varying market conditions and any specific requests they may receive from their customer base, such as large events that require additional and tailored bus services.

Simplifying fares data

We recognise that since the deregulation of buses in the UK, fares structures have become increasingly complex. Through BODS, we want to give passengers clearer information on ticketing and drive simplification of fares structures across the country. The current fares structure is complex and difficult to replicate digitally. And, due to a lack of an agreed industry standard, no publishing tools exist to do this. Currently, Traveline does not provide fares data, although passengers have expressed a strong interest to know when their bus will arrive and how much it will cost.

We believe that through mandating the publication of fares data and agreeing standards that this will drive the simplification of the fares structure – as we saw in London following the publication of data in 2007. Operators that maintain easy-to-understand fare structures will see many benefits such as data consumers will be more likely to access this data and share this with passengers which will increase public trust and usage in buses.

In the long-term, we want BODS to support the innovation around fares and how operators can offer different ticket types. As part of the restart following the Covid-19 crisis, we want to see bus operators have the option to provide innovative ticket types across bus and other modes such as part-time season tickets and discounts for vulnerable groups. We will encourage bus operators to understand how to use NeTEx to support these ticket types to fit around passenger and consumer lives.

Case Study: Ticketer assisting operators to publish fares data

Ticketer is a smart ticketing systems supplier offering ETMs on buses throughout the UK.

Most bus operator’s tickets and fares are hosted within the ETM and so Ticketer holds much of the information needed to be published onto BODS. Ticketer is working with bus operators to create an export of the required fares information in the required UK NetEX standard and automatically publish this data to the BODS system to ensure operators meet this requirement. In addition, Ticketer are developing functionality for operators with the ‘Schedule Adherence’ module to also automatically export their timetable data to the BODS too.

Case Study: Pilkington Bus publishing using the Create Fares Data service

Accrington-based bus operator Pilkington Bus have been heavily involved in Alpha and Private Beta phases of the Create fares data service developed by Transport for the North and Infinity Works.

All of Pilkington’s current fare data is stored within their Electronic Ticket Machine (ETM) system and can be accessed by the owners and specific employees within the business. These ticket machines are provided by Lancashire County Council under a lease agreement.

Using files exported directly from their ETMs, Pilkington Bus has been able to generate NeTEx files for single, return and period tickets. They’re able to define specific passenger profiles, route data, sales information and validity of each fare offered to passengers. These files have been uploaded to the BODS platform and shared with their current app provider along with other data consumers.

They will continue to be involved in all future development of the tool including, testing new features and providing feedback on the current functionality.

Publishing location data

Overview

Operators will be required to provide the Bus Open Data Service (BODS) with automatic vehicle location data. Vehicle location data must be supplied including specified fields and at an update frequency of between 10-30 seconds commencing from 7 January 2021.

Automatic vehicle location data will need to be provided using a SIRI-VM data feed that can be provided by some real-time/ETM suppliers. Bus location data is also known as Automatic Vehicle Location (AVL) and gives information about the bus location at that point in time. All data feeds published must be in the SIRI-VM Version 2.0 or 2.0Q format.

What is SIRI-VM?

The Standard Interface for Real-Time Information (SIRI) was created to specify a European interface standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

SIRI-VM is the vehicle monitoring service, which allows for the exchange of real-time positions of public transport vehicles. Under these circumstances, real-time information for public transport provides Global Positioning System (GPS) coordinates about where a vehicle is and for BODS this will be updated every 10-30 seconds. The location is sent to a central server, which then provides a live feed for all vehicles. Some versions of SIRI-VM can also include further information about upcoming stops, such as the vehicle’s Estimated Time of Arrival (ETA) and allow data consumers to produce a map of live tracking of vehicles.

The service is designed to exchange vehicle monitoring information between control systems, and to distribute to journey planners, alert systems and displays that wish to process and match real-time positions based on structured elements. This will allow passengers to track where their vehicle is and make informed decisions about their journey, and for bus operators to monitor the efficiency of their network. More information can be found on the SIRI-VM website.

Producing real-time information data feeds

Operators with an electronic ticket machine (ETM), location system or real-time supplier should contact them to discuss their ability to provide a feed that aligns with the Department for Transport (DfT) SIRI-VM Profile.

Case Study: Ticketer assisting operators to publish location data

All Ticketer ETMs are equipped with GPS, so are location-aware. They communicate in real-time with the Ticketer back office, sending location data continuously to the Ticketer back office.

This information can be exposed through SIRI-VM as required by the bus open data regulations. Most operators already deliver SIRI-VM from their Ticketer solution to local authorities, websites or mobile apps and BODS just requires another SIRI feed which has been specified by DfT. Bus operators with Ticketer ETMs can work directly with Ticketer to set up this feed on your behalf.

Location Matching

Data consumers will need to combine information from timetables and location datasets to produce journey-planning applications with real-time information. Following discussions with data consumers, we’ve identified specific data fields necessary to ensure different data types can be matched correctly.

The Department for Transport (DfT) profile will be need to be implemented with certain elements for this data to be accurate for data consumers. It’s fundamental that the data for OperatorRef, BlockRef and Vehicle JourneyRef are populated correctly. They must use the same ID to the corresponding object in the timetables TransXChange data supplied to the service. This enables consumers and DfT to match different data types.

Operators are encouraged to include the BlockNumber field in all their TransXChange 2.4 files because it enables data consumers to combine information from timetables and bus location data more easily and accurately. This enables them to provide quality information to passengers. If it’s not provided, partial matching methods are used, which reduces the quality of data that third parties can supply to passengers. It also reduces the number of data consumers willing to use the data within their apps and services.

Changes to vehicle and driver operations that result in changes to BlockRef and VehicleJourneyRef will require the upload of a revised TransXChange file to BODS to ensure that the data in the TransXChange file matches the operational data in the SIRI-VM feed.

Crowdedness data

Information about the crowdedness of public transport options has become a key metric for passengers and their modal decisions. Passengers need to be able to assess their safety, both temporally and spatially. They need to know what time of day, and which journey option is the safest. By providing clear data on crowdedness, operators can enable themselves to balance safety and capacity considerations and enable potential passengers to modal shift safely towards local bus options. Operators are encouraged to include this information to ensure the safety of passengers and help increase the trust of passengers during these times.

There are certain fields that would be required in SIRI-VM, and within the DfT SIRI-VM Profile for crowdedness data to be shared accurately. Currently, Ticketer is the main ETM supplier making this data available in the SIRI VM location data feed. For operators who have Ticketer ETMs, DfT would be grateful if you could grant permission to Ticketer or your ETM supplier to make this data available to BODS as part of the SIRI VM feed.

Time Synchronisation and Accuracy

To ensure the accuracy of data supplied, and the ability to use the location data to provide high-quality information to customers, it’s important to ensure that all equipment and services in the data chain know the time accurately.

To achieve this, all components in the production and processing of SIRI data should be regularly synchronised with an accurate time service. This could be, for example, GPS for a ticket machine or tracking device and a reliable internet time service for servers.

All timestamps are stated in UTC (Coordinated Universal Time). The use of UTC avoids problems with changeover to and from British summertime. It’s recommended that time is synchronised at least once-per-day to ensure time is known to a 1-second accuracy.

The role of local authorities

Overview

We believe that local transport authorities (LTAs) have a vital role to play in supporting bus operators to meet their new statutory obligations. It’s a discretionary decision to be taken by LTAs across England as to what services they choose to provide if any at all. LTAs will be best placed to determine the level of support required. We would encourage LTAs to support operators who may lack the digital skills, capabilities and resources in their organisations and so would be at greatest risk of not complying.

Traveline national database

We encourage local authorities that currently provide data to Traveline to continue to do so, in parallel with data being provided to the Bus Open Data Service (BODS). It will be essential to support the production of the TNDS beyond the point at which the regulations come into force. This will allow sufficient time for BODS to become embedded without disrupting customer information provision.

The transitional period is scheduled to run until the end of 2021 and, during that time, we’d advise that LTAs continue production of the regional datasets.

If you’re a local transport authority considering stopping contributing to the regional Traveline datasets, please contact the Bus Open Data Team at busopendata@dft.gov.uk. We’ll then complete a local transport authority operator audit with you to determine whether all the operators in your area are publishing timetable data to BODS. Once confirmed, it’s then a local authority decision about whether you cease to contribute to the regional Traveline datasets.

Local authorities offering a bureau service

In some areas, it may be that LTAs agree to offer a bureau type service supporting operators to independently publish their own data. This is different from a local authority being an agent where they become responsible for publishing data on behalf of the operator. Instead, local authorities are encouraged to equip operators with the ability to provide accurate data and teach them to adopt digital tools through training and support.

This will involve offering access to tools such as TxC 2.4 that will be provided by the Department for Transport (DfT) and training operators to use them, to enable them to develop their digital capabilities and independently publish their own data.

Some local authorities may have a tool of choice that can be made available to bus operators. For example, the Norfolk County Council model involved making TxC 2.4 data-creation tools, such as the HOGIA tool, freely available to bus operators who then independently created their own timetable files to provide to Traveline without any further assistance from the LTA.

If you have software for creating TxC 2.4 files, you could train and support your operators to use the software to create their data files for BODS (providing that the licensing terms from your software provider permit this). DfT provides a tool that is freely available and enables the creation of TxC 2.4 files using a spreadsheet. The user adds their timetable data to a spreadsheet (which may be prepopulated with their last submission). This is then converted into a TxC 2.4 file, and the operator can then upload this file into BODS.

We’re currently considering whether to provide a web-based timetables service instead that offers a similar user experience to the Create fares data service. Your feedback and thoughts on whether this would be useful would be welcomed either via Twitter @busopendata or via email at busopendata@dft.gov.uk.

Other roles for local authorities

LTAs might also wish to support bus operators in the conversion of automatic vehicle location data feeds into useful Real-Time Passenger Information (RTPI). However, local authorities do not have a statutory duty to provide RTPI, and, if a local authority chooses not to, it will be up to the market to provide RTPI solutions. It’s important to note that high-quality automatic vehicle location data will make this possible.

A local authority may provide support by offering a back-office system if they, or a neighbouring local authority, already have a system. Another option would be to encourage operators with Electronic Ticket Machines (ETMs) to subscribe to the location data feed to offer a real-time information service for their passengers - this can often be offered at cost-effective rates and significantly transforms the passenger’s experience.

Case Study: Essex County Council - Assisting operators to publish data

At the Real-Time Information Group Annual General Meeting (March 2019), Essex County Council announced their plans to offer a Bus Open Data bureau service to operators in their local area.

The types of services they will offer include:

• supporting operators to create TransXChange (TxC 2.4) data files by offering free to access tools
• providing data to the Bus Open Data Service on behalf of operators (if acting as an appointed agent)
• supporting downstream users to consume data

Also, Essex County Council will be offering a small-operator solution for transmitting automatic bus location data by fitting buses with GPS transponders that directly communicate with the Council’s real-time information system. Although the duty to provide the automatic bus location data rests with the operator.

We were delighted to hear their plans for a bureau service, and, would encourage LTAs across England to think about how they can support their operators to improve their information offer for existing and prospective bus passengers.

Publishing data about bus stops

Overview

The bus open data regulations include a statutory requirement for Local transport authorities (LTAs) to maintain and update data in the NaPTAN dataset for bus stops and stations. In practice, this means data staff at the LTAs will need to update the DfT database when:

• new bus stops are added
• temporary stops are added
• bus stops are either moved or removed

The data that will need to be provided by LTAs for stopping places within its area, will include:

• the location
• the stop code or the National Public Transport Access Nodes code
• the area code
• spatial coordinates
• relevant landmarks
• a topographic reference to the National Public Transport Gazetteer of Places ^{[footnote 6]}
• details of any change in its location

The importance of accurate information about bus stops and the maintenance of the NaPTAN dataset is integral to BODS, as this data will be a key connector for the other 3 sources of data. As many bus stops and bus stations are owned and maintained by local authorities, it seemed appropriate that a statutory requirement to maintain the NaPTAN datasets be placed on local authorities (for bus data only).

Publishing NaPTAN data

LTAs will have a statutory duty to ensure that the NaPTAN data is accurate and up-to-date for their local area. The Public Service Vehicle Open Data Regulations will mandate this data to be provided by 31 December 2020.

After successful testing with Lancashire and Teesside authorities, BODS offered a temporary free service to assist local authorities with improving their NaPTAN data, in preparation for the statutory requirements. The team developed an algorithm to highlight data quality issues within the location, bearing and street name of NaPTAN stops. Analysis from this algorithm has shown the bus stop data inside England to be accurate 97% of the time. The 3% of stops that require further inspection has been distributed to the local authorities across England, where authorities have diligently worked through the proposed corrections, accepting the changes where necessary, and uploading to the national database. So far, analysis shows that more than 99% of stop data in England is accurate.

Local authorities must update their NaPTAN database, and we would encourage authorities to continue monitoring their NaPTAN data using the different services available. Other tools include the DfT NaPTAN Application and Passenger’s Bus Stop Checker.

NaPTAN will be managed alongside other transport open standards by DfT as it’s a central database that covers transport access nodes across multiple modes of transport, rather than simply just buses. However, it’s worth noting that the statutory requirement for local authorities to maintain and update NaPTAN data will only apply to bus stops and bus stations rather than stops and stations for other modes of transport.

DfT will continue to explore options for driving further development of the NaPTAN system. For example, we may look at offering new ways to upload or download NaPTAN data if there’s a high level of demand and clear benefits to users.

If warnings are spotted within the NaPTAN data for your area, you must fix them in your NaPTAN system and push the changes to the national NaPTAN database. If you spot warnings or errors within an area covered by another local authority, please contact that authority with details so that they can make corrections.

If, as an operator, you believe that there are errors in the NaPTAN (bus stop) data, please report this to the relevant local authority, who are responsible for maintaining and updating the data. This applies especially if it relates to a new stop.

Maintaining the NaPTAN database

NaPTAN data is used by bus operators, data managers and other local authority staff. The data is used to manage public transport-related software or services. NaPTAN data can also be used for local and national transport apps and services. It’s available to the public to download for free, but not upload data.

You can only upload data if you work for a local authority. To register for an account, you will need to request access to the NaPTAN app.

NaPTAN data for each administrative area is created and maintained by local authorities using the data supplier’s preferred editing tool, and then uploaded to the NaPTAN data management website. NaPTAN data can be uploaded in XML format, zipped or unzipped.

DfT produced guidance for data managers on how to use and maintain NaPTAN in their administrative area. There are a set of tools and libraries used internally within the department to investigate the data quality of NaPTAN. This set of tools has been released under the name OpenNaPTAN. The tools can be found at our GitHub repository.

If you have an issue with the management website, please contact naptan.nptg@dft.gov.uk.

NaPTAN redevelopment work

DfT are currently working to rebuild the NaPTAN service to ensure that it can continue to meet the needs of transport users now and in the future.

Firstly, in response to new accessibility legislation which came into force in September 2020, we’ll be reviewing the structure, design, and content of the website, which still uses a legacy design. The primary aim is to make all web-based NaPTAN information, guidance and interfaces accessible, under the legislation.

Secondly, in June we finished the ‘discovery phase’ for the future of services powering the NaPTAN dataset. We’ve reviewed the existing service and will now rethink how data is captured, stored and exported. Although the service itself is functioning, the underlying technology is due an upgrade.

DfT are also working to deliver a replacement NaPTAN Data Quality Checking Service. We’ve taken the step to make the code library open- source, enabling users to assess data quality and visualize the stops to aid research with NaPTAN data. The library performs a series of internal and geospatial consistency checks on the daily NaPTAN data release. It also features an interactive document map allowing a user to search all active NaPTAN entries within an administrative area. DfT are currently considering the future roadmap for this new service and any enhancements that may be needed for the service.

We’re also working with Ito World to ensure that users of the legacy NaPTAN data quality tool are successfully migrated over to the new DfT Data Quality Checking Service.

Introducing the Analyse Bus Open Data Service

Overview

With the advent of the Bus Open Data Service (BODS), there’s a growing appetite amongst stakeholders to use the data to enhance existing processes across the industry. The Analyse Bus Open Data Service is a new managed service within BODS that will enable the use of open bus data for reporting and analytics purposes and the first module will be available to use from end of December 2020.

This service will run off an Integrated Transit Model (ITM), surfacing data around many issues that stakeholders have requested. This will include:

• vehicle-location feed monitoring
• alerting of delayed service
• journey completeness,
• on-time performance
• headway reporting
• enhanced vehicle data, route and operator statistics

It will give transport operators, local authorities, government, and other associated parties up-to-date data enabling them to:

• perform existing bus data analysis in faster and easier ways
• produce more accurate and detailed analysis reports
• improve on collaboration between different organisations
• inform transport policy and compliance monitoring across the industry

Location data feeds

This module will enable operators and regulators to monitor the provision of location data feeds in line with the The Public Service Vehicles (Open Data) (England) Regulations 2020. It will be launched by the end of December 2020.

The module will provide real-time, and recent historical reports, on the performance of SIRI-VM feeds provided to BODS and associated with bus operator National Operator Codes. Also, notifications can be configured and sent to operators, ticket machine suppliers, local authorities and other stakeholders when the performance of feeds is impacted in real-time. This aims to help operators meet their statutory requirements of providing real-time location information for the buses that they operate, and improve the quality of real-time data feeds.

The service will support operators by providing feed monitoring reports from January 2021. Vehicle location data will be used to determine the actual and expected number of vehicles that should be running at a specified point in time. This will allow operators to identify gaps in data provision from expected vehicles or times when feeds are absent of data. Detail will be provided to assist operators to diagnose whether the issue is with the feed or vehicle/driver.

Also, feed completeness, adherence to schema and update frequency can be reported on to help operators improve the quality of the vehicle data being provided in BODS and to support alignment with statutory requirements. To meet a bus operator’s statutory requirement, they should ideally check notifications and remedy any issues promptly.

Punctuality data

This module will provide historic punctuality reports based on location data to help operators meet statutory punctuality reporting, give local authorities digital tooling to support punctuality partnerships and support compliance monitoring by DVSA. This will be available from March 2021 to support operators in providing punctuality reports, which will be legally mandated from then.

Punctuality data will be created from the combination of timetable data which should be uploaded onto BODS by 31 December 2020 with location data. The AVL Location Data Service will be ready to go from 7 January 2021, where real-time location data will get pulled through to the RAAS tool and be combined with timetable data.

If operators have joined BODS as early adopters of the location service, they’ll be able to provide punctuality reports for August to December 2020, as required by the regulations, once this service is released in March 2021.

The service will show the punctuality and real-time information in a dashboard which can analyse punctuality levels at bus stops and of routes and services which can be viewed in a graph. Operators can view their punctuality levels across days of the week. Local authorities will be able to view punctuality and operator performance levels in their administrative area. This will allow local authorities to see who are the best-performing operators as well as a list of operators that may need further attention.

This data can also be exported into CSV files which can be sent directly to authorities if needed.

Enhanced vehicle statistics

The service will be extended at the end of September 2021 to provide a statistical module to digitally transform the process of government and support existing and new types of analysis by statisticians, analysts and economists. This module will include reporting on additional data provided in the SIRI-VM feeds to BODS. This data aims to help all stakeholders see information above and beyond on-time performance, feed monitoring and statutory compliance, to help improve the operation and provision of bus services.

Supplementary data provided in the SIRI-VM feeds such as raw GPS positions, traversal time of service links and other metadata provided in-vehicle position updates, can be used to enhance the service. Extra reports can be generated where data is available to do so, for example:

• vehicle type used
• estimated distance travelled
• route share and availability
• average journey time and speed

Accessing the Analyse Bus Open Data Service

For the first time, small and medium-sized operators will be given free access to a data transport tool which they may not have previously had access to before. Operators of all sizes will be able to use the tool to view their service levels in real-time and generate reports to help improve the efficiency of their routes. By providing local authorities with an overview of services in their area, this will help them with public transport planning provision.

The Analyse Bus Open Data Service is currently being tested with stakeholders and has had positive feedback from local authorities stating that this will be significant to the transport and highway network management teams. Operators have commented that this tool will be useful for them and is what operators have asked for.

If you’re interested in getting access to the Analyse Bus Open Data Service as soon as this becomes available for testing, please email us at busopendata@dft.gov.uk.

The role for central government

Overview

To meet the requirements of the Bus Open Data Service (BODS), operators and local authorities operating local bus services across England will need access to appropriate software to generate the data files and also create digital and data capabilities within their organisations by upskilling their existing staff or recruiting additional new staff.

The cost of doing this will vary by operator and local authority, depending on:

• current position
• whether they already have some software capability and can generate some digital data
• available employees and their skills

The Department for Transport (DfT) recognises that the sector may need support in overcoming the barriers and so has taken a key role in guiding bus operators and local authorities, and providing basic tools and training to help them meet the legal requirements of data provision.

Early Adoption

DfT have been building a service for BODS and encouraging operators of all sizes, through the business change phase, to sign up for the service and help operators to publish location and timetable data ahead of the deadline.

Case study: Bus Open Data team supports Green Bus Company

Green Bus is a small company in Birmingham running 10 services throughout the county. Green Bus had heard about the new Bus Open data legislation but did not know how to produce a location feed or have the skills within their team to publish fares data through NeTEx.

The Bus Open Data team worked closely with the Green Bus Company to upskill the team so they could become early adopters of the service. We worked with the web cloud-hosting team of Green Bus (known as Cloud Heroes) to design a Sir-VM subscription service from scratch. We supported the team through emails and online meetings on how to produce their first NeTEx file, and they will be able to do this on their own in future.

Provision of tools

DfT is working with KPMG, ITO World, Transport for the North and Traveline to deliver digital tools to support creation and open publishing of TransXChange (TxC 2.4) and NeTEx data files which form part of the wider BODS offer. More details about publishing of NeTEx and using the fare data build tool will be provided during 2020 ^{[footnote 7]}.

The TxC tool discussed earlier is intended to provide spreadsheet level functionality to support bus operators to create their TxC 2.4 files to be uploaded on to BODS. This is to help overcome the historical barriers to the publishing of TxC 2.4 data as many smaller bus operators have been unable to afford transport data management software.

The Create fares data service which is being delivered by Transport for the North, can:

• provide browser-based functionality to create and export NeTEx files to BODS
• ensure that bus operators can meet the fares and tickets data requirement without facing barriers to upstream data creation

These tools have been made available during the business change period, and will be made freely available to the industry as part of the Bus Open Data Service.

In a later software release, DfT will also provide new functionality in BODS to support bus operators to generate punctuality reports and meet the statutory requirement that will come into effect from 31 March 2021 to provide reports covering the previous 12 months operating performance.

It’s noted that for the 31 March 2021 the legal requirement only applies in respect of August 2020 to December 2020. If operators have joined BODS as early adopters of the location service, you’ll be able to provide your punctuality reports for this period once the Analyse Bus Open Data Service is released in March 2021. However, if BODS data is not their only data source operators may supply punctuality data for all of 2020.

Training and events

Department officials had planned to deliver business-change events and activities during 2020 to upskill the industry and prepare bus operators and local transport authorities [LTAs] to use the new BODS and publish bus data. Instead, officials have adapted to social distancing restrictions to deliver online workshops and webinars to upskill local authorities and bus operators on the new data standards and systems. This has been supported by briefing packs and online training material for both bus operators and LTAs.

Department officials will continue to work with operators to support them and help them to meet the new requirements. We realise that, during 2020, and against the challenges presented by the Covid-19 crisis, many operators will need practical support and time to adapt, particularly for the smallest operators. The BODS support team can be contacted for information on how to create and publish data, using tools which are free to use.

Details of upcoming training and events are usually shared on our Twitter channel, follow us on Twitter @busopendata.

Setting standards

DfT, both now and in the future, will have a key role to play in both the development and setting of standards. We’ll collaborate with industry partners to both maintain and review existing standards and where appropriate, lead on the development of new standards. Updates will be provided to the sector:

• on the Bus Open Data GOV.UK pages
• in the Bus Open Data newsletter
• through workshops and events where appropriate
• through our delivery partner network
• on our Twitter channel @busopendata

These updates will also be made available to the OTC and DVSA to notify local bus service operators through their regular publications.

Standards that will be managed by the DfT include TxC 2.4 which is used to support the creation of routes and timetable data and the NaPTAN database which is used to support the creation of data about bus stops and stations.

The DfT has commissioned the development of a UK profile for the Network Timetable Exchange (NeTEx) standard which will be used to support the creation of fares and tickets data - this will be managed by the European Committee for Standardisation (CEN). It’s important to note that CEN is independent of the European Union (EU) and European Commission (EC) therefore our membership of CEN will persist irrespective of EU membership.

DfT officials will work with both bus operators and data standards leads as well as industry groups such as the Public Transport Information Co-ordination Committee (PTIC) and the Real-Time Information Group (RTIG) to seek expert advice in the maintenance and development of these standards and ensure that government is able to fulfil an effective leadership role in the setting of industry standards. The department will also work with local authorities, operators and system suppliers to ensure they are consulted on standards and any changes to them.

Quality assuring data

Overview

The department will not legally mandate quality standards for the data. If the data file passes first-stage basic validation checks, it can be openly published for use by data consumers. For timetables data, bus operators can review their second stage data quality report and make these further changes before confirming the file is ready to be published. We would encourage bus operators to make use of the data quality reports which the system will provide. This may require the investment of additional time to address observations that are flagged in the data quality reports.

The process of providing data to the Bus Open Data Service (BODS) has been streamlined to make it very easy to use and to align it with existing processes to minimise the burden placed upon bus operators in meeting the new requirements.

Basic validation checks for all data types

For timetables, fares and location data there are several checks that occur to ensure quality.

Timetable data is first validated to ensure it’s the required type and format (meaning, its route and timetable information in TxC format ). The data’s checked against the appropriate schema to ensure that all mandatory fields have been completed and that it’s a valid TransXChange file. We will check that the fares data complies with the NeTEX schema.

Location – check it’s the right feed (meaning a Siri-VM feed and that it’s working).

If the file does not pass the first stage validation checks, it will not be accepted for publication onto BODS. Therefore, it’s crucial that operators are aware of the outcomes from their validation checks and make any changes that are required to remain within the bounds of the law.

Enhanced quality checks for timetable data

If the file or link passes the basic validation checks, it will then undergo enhanced quality checks to examine the quality of the data and its suitability for providing passenger information. Tests are run to assess the timeliness, completeness, accuracy and richness of the data. The enhanced quality checks provide more detailed analysis of the timetables, identifying issues such as:

• fast timings
• incorrect stop orders
• missing stops
• duplicate services

In all, over 20 checks are performed on the datasets.

An interactive web-based report is generated listing any errors or warnings and made available to the bus operator. Reports are provided through BODS and list the potential errors. This allows the operator to drill down into the detail, viewing the relevant information on maps and in timetable or tabular views. This report will provide the information that an operator or appointed agent needs to fix the issues in their source systems.

Overall, there are 19 quality tests included at this stage. The tests we’re using have been selected by industry experts and validated with bus operators. We believe they provide key data-quality observations that would adversely impact the passenger experience, if unaddressed. These tests include:

• incorrect NOC - a National Operator Code (NOC) is considered to be incorrect if it doesn’t match the NOC Code assigned to your organisation within BODS: if you’are unsure about your organisation’s NOC, please check the NOC database

• stop(s) are not found in NaPTAN - this observation identifies cases where a stop is used in a timetable, but it’s not in NaPTAN: a stop is reported as not in NaPTAN if a stop reference is provided and the stop reference is not found in NaPTAN (temporary stops that are defined within a TxC file and do not include a reference to NaPTAN are also reported)

• first stop is set down only - this observation identifies timing patterns where the first stop is designated as set down only, where it means that the bus is not scheduled to pick up passengers at this stop

• last stop is pick up only - this observation identifies timing patterns where the last stop is designated as pick up only

• missing stops - this observation identifies cases where a stop may be missing from a stopping pattern from the data you have provided (for example, if some journeys stop at A, B, C and D and another journey stops at only A, B and D, stop C will be identified as a possible missing stop: therefore, for limited-stop services, it’s likely that a higher number of observations will be reported)

• same stop is found multiple times - this observation identifies timing patterns that feature the same stop multiple times: it’s raised if a stop is included in a timing pattern four or more times (while this may not be an error, it’s often caused by stringing many journeys together

• incorrect stop type - stopping patterns are considered to be using stops of the incorrect type if the stops are not designated at bus stops within NaPTAN: expected stop types are BCT, BCQ or BCS

• first stop is not a timing point - a timing point is a designated stop where the bus has been registered to depart from at a specific time: this observation identifies timing patterns where the first stop is not designated as a timing point

• last stop is not a timing point - a timing point is a designated stop where the bus has been registered to depart from at a specific time: this observation identifies timing patterns where the last stops is not designated as a timing point

• fast timing between timing points - this observation identifies links between timing points which appear unfeasibly fast: a link between a pair of timing points is considered too fast if it would require a vehicle to travel between the points as the ‘crow flies’ at over 70mph

• slow timing between timing points - this observation identifies links between timing points which appear unfeasibly slow: a link between a pair of timing points is considered too slow if it would require a vehicle to travel between the points as the ‘crow flies’ at a speed of less than 1 mph

• backwards timing - this observation identifies timing patterns with incorrect time sequences: a timing pattern is considered to include a backwards timing if the timing of a stop is before the previous stop, or if the departure time is prior to the arrival time

• fast running time between stops - this observation identifies links between stops which appear unfeasibly fast: a link between a pair of stops is considered too fast if it would require a vehicle to travel between the stops as the ‘crow flies’ at over 70mph

• slow running time between stops - this observation identifies links between bus stops which appear unfeasibly slow: a link between a pair of stops is considered too slow if it would require a vehicle to travel between the stops as the “crow flies” at a speed of less than 1 mph

• no timing point for more than 30 minutes - this observation identifies timing patterns where the interval between a pair of timing points is more than 30 minutes

• duplicate journey(s) has been found - this observation identifies any journeys that are included in data sets more than once: journeys are considered to be duplicated if they have the same date range, follow the same timing pattern and have the same operating period and operating days

• backward date range - his observation identifies services which have a start date later than their end date

• journey overlap - this observation identifies cases where journeys partially overlap: a journey is considered to be partially overlapping if they follow the same timing pattern for at least 10 stops and there’s at least 1 day of their operating period in which they both run

• missing destination display - this observation identifies any journeys that do not have a destination display defined: destination display is the name of a destination to which the bus ultimately goes, and is fixed for the whole journey

We’re currently gathering feedback from users regarding the data quality reports and, if based on the feedback, we understand we need to make changes to the Data Quality Managed Service (DQMS), we’ll consider incorporating these in the future.

During 2020, data quality reports will not be made available to data consumers. This is to allow time for bus operators to adapt to meeting the new requirements and addressing data quality issues. Beyond 2020, we’ll consider how best to openly provide this data to data consumers for consideration when building applications, products and services.

The Bus Open Data team are currently reviewing the DQMS. Updates include which tests have been designated as critical, and which ones as advisory and whether operators can suppress the tests or whether they should act on the feedback.

The data quality reporting will be iteratively improved so it separates critical observations that should be immediately addressed by operators, from advisory observations that are subjective, and may contain false positives.

Advisory observations should be addressed by operators, or suppressed if they’re intended by the operator. These observations will remain suppressed within the data set.

A feature is also being designed which will display new data quality reports in a separate group to those encountered in the second report. This way, the user can easily find new information that was not displayed in the first report.

Updating data and quality checks

When a data file is updated using a URL, BODS will identify that the dataset endpoint has changed and that a new dataset has been created. Enhanced quality checks will be automatically performed for the updated data file and the bus operator will receive an email notification which will either explain that the file has been successfully updated, or that there may be an issue with your data and action is required.

It’s important that if or when you receive such an email notification that you respond to it immediately to ensure that your published data are of the highest quality. We’d encourage bus operators and their data staff to actively consider any errors identified and seek to address these at the earliest opportunity.

If you do not agree with the data quality report and think that what has been reported as an observation is, in fact, factually correct (for example a fast timing), it’s at the operator’s discretion to disregard these observations. We would, however, encourage bus operators to actively consider observations and only disregard observations that are false positives.

The quality of the data published by bus operators will be their primary responsibility. While DfT will seek to create the enabling environment required to publish high-quality data by providing data quality reporting tools, we cannot warrant the accuracy and quality of the data.

Although it’s not a requirement to fix all data quality observations, the idea is that the assessment gives the operator the tools they need to begin to enhance their data. The quality of published data will have a direct bearing on the quality of applications, products and services that application developers can offer passengers.

It’s anticipated that those bus operators who prioritise the publication of high quality and accurate bus open data will realise the benefits of bus open data far sooner by, for example, having more passengers using their services.

Data consumers can use the data quality score to get an overall view of the data quality, including accuracy. Data consumers will also be able to view the data quality observations so that they can understand the observations, and whether this will impact their user cases.

Missing files and corrupt links

BODS is programmed to perform twice-daily automatic checks on data files and links contained within the service. If your file or link disappears or corrupts, the system will identify this during the checking process and send you an automatic notification explaining to you that there’s an issue with your file or link, and asking you to log into to the system and perform the required checks.

You must address any issues as soon as is possible, as a failure to publish data will be treated as non-compliance if an operator cannot evidence their plans to address the issue, re-provide their data and comply with the requirements.

Using data to develop products

The policy intent behind the bus open data regulations is that data about local bus services be made freely available and without restrictions on its use or disclosure, thereby enabling the creation of useful end-products, services and applications and encouraging innovation within and beyond the sector

However, the Department for Transport (DfT) does also recognise that some bus operators are concerned about how their data may be used and have sought reassurances from DfT officials that their will be safeguarded if their data is misused or used for illegal purposes.

Use and disclosure of published data

Open data is defined as data that’s made available, without restrictions on use and disclosure, is machine-readable and is free of charge to access. It should be standardised and machine-readable to support reuse and redistribution by anyone. This includes data consumers being able to combine the data with other datasets, transform it if they wish it and share it with others on a commercial or non-commercial basis.

In keeping with definitions of open data, bus operators are required to provide their information without restrictions on its use and disclosure. Therefore, bus open data will be truly open and may be used for any purpose, which we believe is the required approach to stimulate innovation with the data. We anticipate that the primary use will be to make applications which help passengers plan journeys. However, data consumers may do academic research and/or inform government policy in other areas (for example, planning locations of public buildings whilst considering access to public transport).

Data consumers are free to find commercial or non-commercial uses of the data. The regulations permit data consumers or application developers to copy, adapt, publish, distribute and transmit the information for commercial and non-commercial reasons, through inclusion in their own applications, products and services.

Data consumer requirements

The key requirement placed upon data consumers will be that they must register for an account for the Bus Open Data Service (BODS), in a similar manner to bus operators, if they wish to use the Application Programming Interface functionality.

To register for an account, data consumers using the Find Bus Open Data Service will be required to supply an email address. The purpose of this requirement is to enable the service to notify data consumers of relevant updates and changes to data. In addition, these details will enable us to restrict data consumers access to API keys and data, should data be used illegally, unfairly or inappropriately. Otherwise, there are very few conditions attached to registration, and access to bus open-data is non-discriminatory - it’s free to access by all who wish to do so. The few conditions we’ve attached to data use are described below.

Attribution of data sources

Data consumers must acknowledge the source of information in their product or application through a statement of attribution. Data should be attributed back to BODS. If data has only been used from one bus operator, it may also be attributed back to the individual bus operator.

It’is important that data consumers note that their use of BODS data does not equate to endorsement of their product, application or service by either DfT or those bus operators from whom the data has been sourced.

Any attempt to suggest otherwise would be false and considered to be a misrepresentation unless specific endorsement was obtained directly from the bus operator. Data consumers will be prevented from further using the service if they state or imply that their product, application or service has the endorsement of the DfT.

It’s also important that data consumers note, that while DfT will seek to preserve the quality and integrity of data published on BODS and encourage bus operators to improve the quality of that data, we cannot warrant its accuracy or quality. Data consumers will be prevented from further using the service if they do not state this in their product, application or service.

Reporting issues with data quality

BODS provides a data quality score and a data quality report for each timetables data set, which contains the details of data quality observations found in the data. The operator should aim to address all critical observations before publishing the data. We’re strongly encouraging bus operators, where necessary, to improve the quality of their data before publication to help ensure that application developers are working with high quality and accurate data.

Also, if an application developer becomes aware of an issue with the quality of data provided by a bus operator, a feedback mechanism will be provided within BODS which will enable application developers or data consumers to directly communicate with bus operators to make them aware of such issues and seek resolution before the data being used in applications, products or services. Consumers can provide feedback on timetables, bus location and fares data sets.

We’d encourage data consumers or application developers to make use of the feedback mechanism within BODS to resolve such issues as it creates one feedback loop or channel for issue handling.

Misuse of data

The regulations also make provision for the Secretary of State to be able to exercise a power to switch off access to BODS due to illegal use or misuse of data. This may be exercised, for example, if one registered user with an application programming interface key is repeatedly overusing the system and placing a significant strain upon the system such that it’s adversely impacting the ability of other users to either access or use the system. This scenario is most likely for automatic vehicle location data, although the right to switch off access will extend to all data types.

Data security

Any data stored within BODS is protected with industry-standard security techniques and policies. If publishing data yourself, you should work with your IT department or service provider to ensure they are adhering to industry-standard cybersecurity principles.

Integrated Transit Model

As data is uploaded to the Bus Open Data Service (BODS), the Integrated Transit Model (ITM) ingests timetables and vehicle location data and matches these datasets to each other, providing an always up-to-date, national view of the public transport network.

The ITM will support consumers to use timetables and vehicle location data more easily.

When operators publish their data to BODS, timetables data is submitted in TransXChange format, and vehicle location data is submitted in SIRI-VM format. Operators’ datasets are also supplied separately from another. The ITM brings these datasets together into a single source, matching timetable and location data together, and delivers them in one common format – General Transit Feed Specification (GTFS) – which allows the data to be more easily interpreted from BODS.

GTFS format schedule data has been made available as downloads in BODS as a national dataset, and as smaller regional datasets. GTFS-RT (matched schedule and vehicle location data) is available via the BODS API.

The ITM provides a reliable source of data which we will make it easier for us to implement future quality enhancements and allows us to convert data into any format we may require in future so this data can continue to reach different data consumers.

The ITM is also the basis of the data that feed into the Analyse Bus Open Data Service (launching from the end of 2020 onwards).

During 2020, schedule data used in the Integrated Transit Model may be supplemented by the TNDS dataset, if an operator is yet to publish their schedule data on BODS. Data for operators in the devolved nations (Wales and Scotland), and other transit modes such as subway, tram and ferry - which are also represented in TNDS - are also being included in the GTFS feeds. In this way a complete, GB, multi-modal dataset for developers is being provided through BODS.

Case study: Passenger - assisting operators to publish data automatically through bus apps.

Supporting the work of DfT, Passenger began to launch website-based Open Data portals for its bus operator customers throughout the UK in May 2019. This was designed to build compliance with the forthcoming regulations into the existing workflow of operator teams who were already publishing network data into their own apps and websites.

This hosted data can then be dynamically linked to the operators account in BODS, meaning that every time they update their own apps and websites through Passenger’s platform, the data in BODS is automatically updated at the same time. This direct link removes the need for data to be uploaded to BODS separately, reducing the risk of human error in maintaining the datasets.

These open data portals have been launched with over 20 operators including:

• Nottingham City Transport
• Brighton and Hove Bus
• Go North East
• Transdev and Blackpool Transport

For Reading Buses, Passenger has added further data to its existing open data portal. Whilst the regulations only apply to England, Cardiff Bus in Wales and Borders Buses in Scotland, have also chosen to make their data available.

Mark Fowles, Managing Director at Nottingham City Transport and Traveline Chairman comments: “Many [bus companies] in the industry are still unaware of the full implications of the Bus Services Act. By publishing accurate data openly on our website, as well as into the national open datasets, I hope this step will act as a call-to-arms for industry colleagues and continue to underline the importance of open data.”

Passenger’s myTrip product, launched in September 2020, makes use of the same approach to hosting open data hosting for smaller bus operators, reducing the administrative overhead for a subset of operators who would also benefit from automatic updates to BODS.

Compliance and enforcement

Overview

Under Section 155(1)(c) of the Transport Act 2000 (sanctions) a Traffic Commissioner (TC) can take necessary enforcement action against bus operators if the required information is repeatedly, without reasonable excuse, not received from the bus operator or local transport authority beyond 31 December 2020.

Sanctions may include operators being ordered to pay a penalty, or compensation to passengers or to spend money to make improvements to the service so that they avoid loss of repute and removal of the operator licence.

Regardless of whether the bus operator independently publishes data or goes through a third-party appointed agent/local transport authority to publish their data, it’s the bus operators who will be liable for non-compliance.

Beyond the TC imposing the above penalties, they could also attach conditions to the operator’s licence under section 26 of the Transport Act 1985 if the operator has been guilty of any serious misconduct (whether or not constituting a criminal offence) concerning the operation of a local service.

Monitoring Compliance

The Department for Transport (DfT) is working closely with the Office for the Traffic Commissioner (OTC) and the Driver and Vehicle Standards Agency (DVSA) to monitor compliance. This has involved checking registers of local bus services as registered with the OTC against those services published on BODS.

Where gaps are identified, we have been engaging with the bus operator during the transitional year to identify what plans are in place to publish their data through the service, including dates by which operators are expected to have published their data. We continue to engage with bus operators and/or their agents to foster compliance by the dates set out in the regulations. However, we will continue to offer business change support into 2021 to those operators who will need assistance to comply.

BODS is an online-only service and is the only place where bus operators can openly publish their data to comply with the Public Service Vehicle Open Data regulations. If the service is unavailable, the TCs will not penalise operators for failing to upload data during that period and DfT will notify operators as soon as BODS is back online. If your data is already online and you’re worried about whether your data will be affected if the service goes down, your data will remain unaffected if you’re publishing it on your own site.

Implication of coronavirus on BODS

The department have provided significant funding for the bus industry during this time, which has played a crucial role in keeping public services running. COVID-19 has highlighted the value of useful passenger information for journey planning and crowding data, enabling social distancing and a modal shift from private hire vehicles. It’s accelerated the delivery of innovation and transport tech solutions to keep passengers safe and key workers on the move. For example, increased use of bus apps for payments and highlighting the need for contactless and closed booking systems.

The policy measures being delivered through BODS will support the restart of the bus industry to return to pre-COVID-19 patronage levels as live location and fares data will be important for increasing customer confidence in using public transport again.

The BODS team have adapted to remote working and have continued to support operators and local authorities through online webinars and keeping in touch through telephone calls to ensure that operators are on-boarded to the new system ahead of the statutory deadlines.

We fully understand that there have been delays in bus operator timelines such as training staff onto the new data standards who may have been furloughed or reprioritised onto other workstreams. Further to this, timetables have been changing constantly to adapt to restart calendar, which may make it difficult for bus operators to start uploading this data permanently.

We’ll continue to work with bus operators and provide them with extensive support to meet the deadlines against a backdrop of difficulties caused by COVID-19. For example, the BODS team have created a timetable data creation tool and will create timetables data files for operators who require additional assistance due to lack of time, resource or digital skills.

We’ll ensure we give those operators breathing space and, if there are genuine mitigating reasons, we’ll work with the TCs to adopt a lenient approach to financial penalties.

Glossary of terms

Application Programming Interface (API): an API is a software intermediary that allows 2 applications or systems to talk to one another and share data.

ATCO: Sometimes referred to as ATCO code. an identifier for bus stops in the NaPTAN database, which has been imported into OpenStreetMap (OSM) in parts of the UK.

Automatic Vehicle Location (AVL): automatic vehicle location is a means for automatically determining and transmitting the geographic location of a vehicle.

Basic fares: refers to fares such as adult single and return fares and tickets, child single and return fares and tickets, group fares and tickets, period tickets, single operator fares and tickets, multi-operator fares and tickets, zonal fares and tickets, the ways in which fares may be paid.

Bus open data regulations: the regulations made under section 141A of the Transport Act 2000 which was inserted by section 18 of the Bus Services Act 2017 in order to require the provision of information by operators and local authorities and to provide related exemptions.

Bus: except where indicated, refers to a bus providing a local bus service.

CEN standard: this is a document which has been ratified by the European Committee for Standardization.

Complex fares: refers to fares that vary depending on the route taken, the duration of the journey, the type and the number of passengers, the method of payment, the amount of subsequent travel undertaken in a given period, or whether or not a discount or a cap is applied to the fare.

Data endpoint: the location of a datafile URL in the Bus Open Data Service.

Data Feed: this refers to a mechanism for data consumers to receive updated data from data sources. It’s commonly used by real-time applications.

Data Consumer: a data consumer is a person or organisation that takes open data and uses it to create applications, products or services for consumption by end-users or passengers.

Distributed Data Model: refers to a model that enables the storage of data across multiple computers which improves performance at end-user worksites by allowing transactions to be processed on many machines, instead of being limited to one.

End User: an end-user is a passenger or consumer of open data through applications, products or services offered by data consumers, usually for the purposes of journey planning (in this guidance).

ETM (Electronic Ticket Machines): public transport fare collection systems. Ticketer is the UK’s leading supplier of ETMs, serving approx. 70% of the market. The built-in GPS means that the ticket machines double up as a tracking device, and therefore both AVL and Fares data feeds may be generated from an ETM.

European Committee for Standardization (CEN): this is a public standards association that brings together the National Standardization Bodies of 34 European countries. They provide a platform for developing and defining European Standards and technical documents within a range of fields and sectors to ensure product and service consistency and compatibility throughout the EU.

GTFS (General Transit Feed Specification): GTFS is a data specification that allows public transit agencies to publish their transit data in a format that can be consumed by a wide variety of software applications. GTFS is split into a static component that contains schedule, fare, and geographic transit information and a real-time component that contains arrival predictions, vehicle positions and service advisories.

ITM (Integrated Transit Model): The ITM will ingest both static and real-time data into an always up-to-date view of the public transport network, will automatically match the real-time data to the schedules, and will generate GTFS and GTFS-RT feeds.

Local Service: a local service refers to a bus service that uses public service vehicles to carry passengers who pay separate fares over short distances - usually less than 15 miles from the point of boarding. Presently all local services are registered with the Office of the Traffic Commissioner. (with the exception of franchised areas, where the local transport authority assumes the registration role).

Metadata: metadata is a set of data that describes and gives information about other data and can be used for the purposes of discovery and identification.

NaPTAN: National Public Transport Access Nodes dataset which is a GB system for uniquely identifying all points of access to public transport, including bus stops as well as railway stations, coach stations, ferry terminals, airports and taxi ranks.

NeTEx: Network Timetable Exchange. The multimodal data standard that can be used to transmit bus information including routes and timetables, fares and tickets and real-time information.

NOC: National Operator Codes (NOCs) contain unique national operator codes that link to the local operator codes in the Traveline National Data Set (TNDS).

NPTG: National Public Transport Gazetteer provides a topographic database of towns and settlements in the UK. It provides a common frame of reference for the National Public Transport Access Nodes (NaPTAN) schema and other UK Public Transport Information schemas such as JourneyWeb.

Open Data: data that is accessible in a machine-readable format and can be used by those who need it to create digital applications, products and services.

Operator: an operator is a person or organisation who runs local bus services.

Public Service Vehicle (PSV): this refers to a bus or coach used by members of the public to travel to and from places on a particular route or in a catchment area.

Real-Time Passenger Information (RTPI): live information about the arrival of services at bus stops.

SIRI: Standard Interface for Real-time Information (SIRI) is a European technical standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

Static File: a static file refers to any content that can be delivered to end-users without being generated, modified or processed by a data consumer - for example, images and PDF documents.

Stop code: the ATCO stop code is an identifier for bus stops in the NaPTAN database, which have been imported into Open Street Maps in parts of the UK.

Stop or stopping place: a location at which a service is scheduled to call.

TransXChange (TxC) is the UK national standard for publishing bus schedules and related data, used primarily for bus service registration and creation of journey planning information

URL: URL refers to Uniform Resource Locator and is used to specify addresses on the World Wide Web.

User Types for the Bus Open Data Service

Publisher Admin: this person would be typically an operator who would play the primary role in maintaining data on behalf of a bus operating company on BODS. They would have all the admin rights related to the bus operating company’s profile on BODS.

Publisher Standard: this person would typically be an operator but would play the secondary or tertiary role in maintaining data on behalf of a bus operating company on BODS. An example of a Publisher Standard user would be additional employees of a bus company or regional employees (for a large-sized operator).

Publisher Agent: this person would typically be an ‘agent’ assigned to maintain data on behalf of an operator. He or she would have the ability to access, publish and maintain all 3 types of data on behalf of a bus operator. Examples can include local authorities and private agents.

Consumer: this person would typically be a consumer or user of bus open data. They would be either using the user interface to interrogate open data, bulk download all data on BODS, or use the Interactive API to use the open data on BODS.

1. This is accurate as of 14 December 2020. ↩

2. The National Public Transport Access Nodes (NAPTAN) database lists all points of access to public transport in Great Britain. It records approximately 400,000 bus stops across England, Scotland and Wales, as well as other transport terminals including railway stations and airports. The NAPTAN database is managed by the Department for Transport and updated on a voluntary basis by local authorities. ↩

3. The National Public Transport Gazetteer (NPTG) is a database providing topographic information about cities, towns villages and other settlements in the United Kingdom. It provides a useful way of describing places and towns. Data from the NPTG supports the NAPTAN database. The NPTG database is maintained under contract by the Department for Transport. ↩

4. A data endpoint is the location of the file or the URL in the digital service where the data file is indexed. ↩

5. https://data.gov.uk/dataset/3b1766bf-04a3-44f5-bea9-5c74cf002e1d/national-public-transport-gazetteer-nptg ↩

6. http://netex-cen.eu/ ↩