What are bus data standards and why should a Transport Authority care?
Bus data is useful only when an Authority, its Operators and their systems share the same definition of a route, fare or vehicle location.
People search for
In this article
Most Authorities recognise the need for better data from bus Operators. The problem often appears in everyday work rather than as a system failure. One Operator may send a spreadsheet, another a PDF and a third an export that the Authority’s reporting or passenger-information tools cannot load. Staff must then reconcile route names, stop references and fare products before answering ordinary questions about the network.
A data standard sets predictable rules for the structure and meaning of information. It is like agreeing a common form before several organisations must process it. It cannot correct an inaccurate timetable or make a late vehicle punctual. It allows data to be checked, combined and passed between systems without someone rebuilding it by hand each time.
The standards an Authority is likely to encounter
For local bus services in England outside London, the Bus Open Data Service has narrowed the choice of formats. The Public Service Vehicles (Open Data) (England) Regulations 2020 require Operators and franchising Authorities for services within their schemes to provide specified data. Exceptions apply, so an Authority should check whether a particular service is covered rather than assume every vehicle operation is included.
The main standards serve different purposes:
| Data area | Standard | What it carries |
|---|---|---|
| Timetables and stops | TransXChange | Planned stopping points and times. |
| Fares and tickets | UK NeTEx profile | Fare products, conditions and related ticket information in the UK profile required for BODS. |
| Live bus location | SIRI-VM | Vehicle Monitoring data: a bus’s location and, where available, its relation to a stop or journey. |
| Wider app or system distribution | GTFS or GTFS Realtime | A widely used passenger-information standard that may be appropriate for an app or third-party interface, but is separate from the BODS formats. |
Conforming to a schema does not guarantee operationally sound data. A file may contain a valid stop code but attach the journey to the wrong stop, omit a temporary timetable change or identify a vehicle that cannot be reliably matched to its planned trip. Passengers then encounter familiar problems: a service missing from a journey planner, an outdated fare shown before travel or a bus disappearing from a live departure board part-way through its route.
Put the requirement where it can be managed
Contract Managers need not be data specialists. The specification must say what is to be supplied, which standard and version apply, and how the data will be tested. “Provide open data” is too loose when the Authority also needs the data for its network map, performance reporting, contact centre or passenger app.
For a timetable or fare change, specify the notice period, who is responsible for publication and how the Authority will be notified when the feed changes. For vehicle locations, agree a monitoring report covering missing vehicles, stale updates, invalid records and services that cannot be matched to the scheduled network. The BODS duty establishes a baseline. Contract controls are still needed for data that must work beyond an Operator’s own systems.
The specification must be supported by an acceptance process. Before mobilisation, ask for a sample feed and test a small set of passenger journeys covering awkward cases: a school-day variation, a diversion, a fare with a time restriction or a late-running bus. Retest after a major timetable change or system replacement. Where a Supplier produces a feed, the contract should identify who must correct it and the deadline.
Do not treat a proprietary format as a harmless convenience. A Vendor may offer useful tools around its format, but the Authority needs to receive the underlying data in the agreed open standard and move it into another system if the arrangement changes. The issue is continuity and evidence.
Useful questions
Before approving a specification or reviewing a data issue, ask the people responsible to answer these points in writing:
- Which data item is needed for the passenger or operational purpose and which standard and version will deliver it?
- Does the requirement cover accuracy, completeness, update timing and matching to the Authority’s route and stop data, rather than file format alone?
- Who will monitor exceptions, contact the Operator or Supplier and confirm that a correction has appeared in the live feed?
- Can the Authority see test results for a timetable change, a fare change and a missing vehicle-location update before the service goes live?
- If the current Vendor or Operator changes, can the Authority retain and use the data without rebuilding its network information from scratch?
More on Data & Governance