Cross-matching live & timetable bus
We offer bus information, query-able by bus stop, giving timetable data at one endpoint, and live data at another. We always regarded these as belonging quite closely together, and the response structures were always arranged in a similar way (a set of departures optionally grouped by line). But recently we’ve been working to bring the yin and yang of live and timetable data into even closer alignment.
We’ve started to do cross-matching with timetables each time we get live bus data for a stop. This has allowed us make improvements and additions to the response. Here are a few new things to look out for:
The “operator” code will now be populated from timetable data. Operator code schemes are confusingly different in live bus data sources. These will now (where possible) align with the operator code schemes used within timetable data.
The “dir” field of the timetable response gives a value, typically (“inbound” or “outbound”) indicating which direction a bus is moving along route. A useful field to add into the live departures data, because the inbound/outbound distinction is a necessary part of identifying a timetabled bus departure. Speaking of which….
The “id” field is a new hyperlinked API approach, which we are trialling so far just for this endpoint. Combining the above fields plus others, the id gives a URL to another part of the API. Specifically it links you through to the timetable departure endpoint. It’s a link which we noticed developers struggling with, or were not aware was possible. The URL can also be regarded as the unique id of the departure resource (hence the field name)
We’re also ensuring certain fields are always present, such as “best_departure_estimate“, in order to achieve greater consistency, and make it very easy to write code which works with both live and timetable.
These new fields (along with the new fields we mentioned recently in relation to bus stop names) are described in the “schema” section of our API reference docs for the live stop endpoint, and timetable stop endpoint.
It must be noted that these fields can only be populated where the cross-matching has been possible. When it’s working well, live bus information is in basic alignment with bus timetables, with delay information added. However, behind the scenes we have very different data sources and data processing operations to bring you live versus timetable. The result can occasionally be some more drastic misalignments e.g. a live data source reporting the existence of a bus which our timetable data does not include at all. In that case we’ll continue to bring you live data, but with these new fields containing ‘null’.
There’s lots going on behind the scenes of the bus live and timetable endpoints, in terms of data processing and cleansing. More on that to come!
