In this second part of John’s session from the TCF20 virtual event run by SMARTEX, John talks about what BODS is and what Ticketer is doing to support operators.
So, what is BODS?
BODS is the Bus Open Data Service and we’ve had a huge amount of information, presentations and webinars around it, but it is important just to reiterate what it is looking to do.
It’s looking to do primarily one thing, and that is to simply make it easier for people to travel by bus. And the mechanism to do so is to use open data. What’s interesting to me is that we are continuing to get greater requirements for different feeds as we go forward, so initially, it was three things: To enable the passengers to plan their journeys with confidence, to know where the bus is so you spend less time waiting and finally to find the best value tickets. Or to put it more simply, the where, the when and the how much.
Additionally, there is other data that may be useful; capacity for example, because I want to actually know what the capacity is on the vehicle that I’m going to take and if I know that vehicle is full, then I might wait at home until I know there’s a vehicle coming along that has capacity. We also added for our operators’ wheelchair provision – so they can get it out to passenger apps. My daughter once said that she didn’t want to go down to the bus stop with the buggy because she didn’t know if she would be able to get on if the wheelchair space was taken. We now have the capacity to add that. So, whilst we are starting with small ambitions on the data front, I think it will ultimately extend to include other types of data in due course.
But let’s just look at the three things that we’re talking about now.
1. THE WHERE – VEHICLE LOCATIONS
All our ETMs are equipped with GPS which means we track them in real time, so we already have all the infrastructure to deliver ‘the where’ for BODS.
Over 90% of our operators are already delivering location feeds to local authorities and mobile app providers and BODS is just another feed! So, it’s really easy for us to do. We already have over 84 operators (adding more every day) providing a location feed to BODS which covers over 10,000 of our ticket machines providing data to the Location Data Service. The rest can be easily added, but requires operator approval to activate the feed for them.
So, it exists, it works and it’s simple.
2. THE WHEN – TIMETABLES
Ticketer added support for adding and managing timetables through our popular schedule adherence package, and so, like location data, we already hold the data required for providing timetables to BODS. The DfT have defined a new format for this data to be exported in; the PTI 1.1 profile has just been formally released and we’re currently developing support for exporting timetables in this format which will be delivered before the year end. Whilst this is a very tight timescale, we already support the requirement for exporting timetables in TransXchange version 2.4, it’s just that it needs amending to export timetables as per the definition of the PTI profile.
We’re also introducing an ‘SA lite’ package for our operators who don’t have schedule adherence, but also for non Ticketer operators who may want to use our ability to host data even though they do not use our ETMs. About 85-90% of our operators already have our schedule adherence package, so they’re already able to provide this data. The key is that we host everything for our operators and even with the PTI new profile, we’ll be fully compliant by the year end. The key for us, and just as we do with ITSO, is to ensure that our operators don’t have to worry about it.
As requirements change, it’s our job to deliver, not the operators! It’s all about making it nice and simple.
3. THE HOW MUCH – FARES
Up until now, there has been no standard for defining fares; whenever we onboarded operators, getting the fares out of the existing system has always been a manual data entry task. So going forward, the DfT have selected NeTeX as the standard. Like timetables and the PTI 1.1. profile, we are working to export fares in this standard to be available by this year end. We will do all the necessary work with the DfT to ensure our data is in the right format and we will host the data for our operators – again, they don’t have to do anything – we handle it. And this is why we think it’s key, that the ticket machine at the end of the day is the source of all data.
SO HOW IS TICKETER SUPPORTING BODS?
In case you missed it, we’re going to host everything for them! We will send all the data to DfT, and all our operators have to do is to log in to the Ticketer Portal, to the tab that says ‘Data’, which will provide a URL which they can then cut and paste into the BODS solution and that’s the end of it. Everything is now done. Any changes from DfT get sorted by us, any changes by the operator on their Portal, like changing a fare, changing a timetable, they’ll do it once, because they have to do that to run their system, and it goes through to BODS with no additional effort on behalf of the operator. Nothing more. So, there’s no need to manually update the hosted files, everything is done. And as BODS evolves, and I’m absolutely convinced it will, any updates or additional feeds will also be put through our Portal. I think it will get immensely popular and we will continuously be getting requirements for different feeds to make it even better for the passenger.
So in summary, it’s three things, we support it, we deliver it, we update it and that’s the end of it. Simples!
