27 Jun 2022 by David Mountain

Showing the location of buses on a map is a game-changer for Real Time  Information. No matter how accurate the predicted arrival times of buses  at stops, this information alone falls short of the Uber app experience  that users now expect.

Telling a user that a bus is three minutes away is useful, but without  more context that explains the uncertainty in that estimate, that user  will become frustrated with both app and bus operator, if that  prediction turns out not to be exactly right.

However, show them the location of that bus on a map, with frequent updates to show its progress, and they understand that context: it becomes obvious where and why a bus might be briefly delayed. Rather than end users staring in frustration at a prediction that doesn’t change, they can track its progress on a map, and have confidence that it is indeed, on its way.

So how is this done?

A set of locations and associated vehicle IDs isn’t much use on its own. End users aren’t interested in all the buses in their vicinity – they care about the select few that enable them to complete the journey from their current origin, to destination.

To achieve this, matching these bus movements to schedules is key. TAPI Bus Information‘s  bus/service_timetables API endpoint can filter down to just the service of interest, that calls at the specific stops a user will board and alight at.

TAPI Bus Information has been used to power Buses On A Map screens in realworld mobile apps for several years. The first implementations used the operator’s own schedule data and vehicle location feeds, which can be kept in tight synchronisation. This allows matching locations to schedules using very precise ID fields. More recently BODS SIRI VM has provided another source of locations, however matching these to schedules is not so simple.

The first question is what schedules those locations should be matched against: Traveline National DataSet, BODS timetables, something else? The second question is how to achieve that matching. The precise ID fields aren’t always present or populated as expected, and it’s not always possible to keep locations and schedules in the tight synchronisation required to use these fields. TransportAPI have solved this problem using a matching algorithm that works through a cascade of steps, depending on what fields are available in the source data. By doing this, we have been able to expand the geographic coverage of TAPI Bus Information’s bus/service_timetables API endpoint from being available only for specific operators, to Nationwide coverage, for all the location feeds in BODS. We have several clients using TAPI Bus Information to achieve this, for purposes including passenger information, and control room displays.

We first launched the feature in the First Bus App, and this remains our most widely used implementation. We also use the bus/service_timetables API endpoint internally as part of TAPI Bus Performance in order to source and archive the vehicle location data and provide analytics on it.

For more information how to use TAPI Bus Information’s bus/service_timetables API endpoint to power a Buses on a map screen, check out our developer example. A streaming subscription based version of this endpoint over a Websocket connection is also available.