We are aware that the DfT BODS team are contacting operators who are not publishing all three data requirements; AVL, Timetables and Fares.
So, we thought it would be timely in this blog to remind operators how Ticketer can help them meet, and keep up to date, with their Bus Open Data Service (BODS) requirements.
For most operators, tickets and fares are being managed within the ticketing system together with our Schedule Adherence feature, which supports the addition of timetables to the mix. It should therefore be no surprise that the Ticketer System already holds much of the information that needs to be made available to meet the DfT’s open data requirements. Because of this, we felt it was a natural extension to the Ticketer Solution to fully support operators in meeting their BODS obligations. That’s not just in creating the data in the required formats, but our support extends to hosting the data as well, to avoid operators having to find alternative and costly ways to make this data available to BODS.
Since the mid-2020, we have been supporting operators with Location feeds and Timetable hosting, and at the end of 2020, to complete the set, we added the ability to export and host Fares in the specified NeTEx standard. We also introduced a “SA-Lite” module, so if you are not already a user of Ticketer’s Schedule Adherence feature, we can still host and supply your timetables in the required TransXchange format (you just won’t have access to the operational compliance and performance reports that are generated when the timetables are fully used by the system).
As mentioned, not only do we generate the data into the required standard, but we also host the data for you and seamlessly update the content as the data in the Ticketer System is modified by you or your team. So, as a user, you don’t have to do anything special to get any new services, updates or changes reflected into your BODS data – this will all be handled by the Ticketer System as part of your everyday use in managing the changes for the ETMs. “Configure once. Don’t touch again” – that’s the way your BODS obligations should be handled.
If you are not a user, you may be sceptical that this sounds too good to be true. However, currently, we are supporting 276 AVL data feeds for BODS and hosting 228 Timetable data files. So, by choosing Ticketer to manage this requirement for your organisation, you would be in great company!
We do our best to work closely with the DfT to understand any new developments in the BODS system, in order for us to continuously update our system to reflect those changes. This way, everything should be seamless for operators, who can be reassured that they are always covered. The compliance requirements can though sometimes change at short notice, and naturally there may be a short lag between what the BODS system expects and what we are producing. But rest assured, we are aware what is needed, and the BODS team know that we, as the largest supplier of BODS data for operators, are continuously working to meet the updated requirements.
So, what is the latest state of our exports to BODS?
AVL
In December last year, the BODS team released their SIRI validator, albeit without prior notice. This checks the compliance of the data being sent via the SIRI feed at random intervals.
There are two areas which are currently being reviewed to ensure full compliance.
1. SIRI Feed Stop References
The first area is relating to stop references in the SIRI feed. The DfT moved away from using “standard” SIRI VM fields and have opted to include stop references at the start and end of the trip, to assist with the task of data matching (against the data in the timetables).
For those operators that use our SA package, we do have this data and we are pleased to announce that we have just extended our SIRI feeds for BODS to include these datapoints. If you do not use our SA package, then we can estimate this for you, if you have added Bus Stops to the system. If you would like to have more details on how to do this, please contact our Support Team and if you check out the documentation library on the Support System, you will find a helpful datasheet on the subject.
2. VehicleJourneyRef
The second area is the VehicleJourneyRef. Note that this is only highlighted as an error should there be something else amiss with the data feed, so those operators with timetables will be shown as fully compliant. Those operators for whom we don’t have stop information for will also see this issue highlighted on their daily compliance reports. The DfT team have informed us that this is an issue that sits with them. They will be updating their validator to accept the data we are using for this field, so the advice for operators is to simply hold tight until there is a future BODS update.
TIMETABLES
In Autumn 2021, the BODS team released their first validator, checking the data quality of timetables made available to BODS. This checks to make sure the timetables are exported in the described format and quality checks certain fields.
Ticketer’s timetables are fully compliant, but a current bug in the BODS system can raise partially compliant warnings with our files, even though they are valid. We are working with the DfT to help them resolve this. There is a workaround, but that requires operators to deactivate the existing dataset and upload the revised timetables as a new timetables set, which can be frustrating and inconvenient for operators (and directly flies in the face of our “Configure once. Don’t touch again” mantra that was discussed earlier). We will continue to work with the DfT to resolve this issue as we appreciate the pain this currently causes to operators. You can follow the progress of this in a future update.
FARES
And finally, the newest kid on the block; Fares. Over the course of last year, we extended our Fares export to support single and return ticket types, as introduced in our “single use QR code” feature. We also added support for the Alighting Bus Stop to Fare Stage mapping, should this differ from the boarding setup, once the DfT defined how that data should be included in the specified schema. Even more recently, we extended the Fares export to utilise the passenger classes that were introduced earlier this year.
The DfT plans to introduce a Fares validator later this year, so not only do we expect further changes that we will need to make to the export routine, but it may be that some of these recent additions may become mandatory. We will keep you posted on that front, so you can update your data in good time.
Of course, currently only ‘simple’ fares are in scope, so during this year we expect the DfT to define how ‘complex’ fares (through fares, capped fares, etc.) should be handled in the Netex schema which will inevitably require further changes. But not to worry, at Ticketer we will monitor those changes and make sure operators are kept compliant as the specification evolves.
And of the future? Well, the DfT are keen to extend BODS to support disruptions, discussions of which we are involved in, so we will keep you posted as those requirements progress. If you are not comfortable with including explicit occupancy data in your SIRI feeds, we will be introducing an aggregated view of reporting of that data, and we also have an exciting development lined up to support off-bus fares. More details on all of these will be shared in a future edition.
Although I’d love to, I won’t go into much more technical detail here (but we will soon release a Help Sheet which will go into that detail). As you can see, the Ticketer BODS developments never stop, and we will continue to support the current, and future, DfT requirements around BODS.
Our door is always open, so if you are currently using our exports but want to understand some of the new additions I have described – or if you are not using us for your BODS data, but are interested to understand more on how we can help – our friendly Support team are always here to help: [email protected].
This article was originally published by Ticketer.
