Bus stop direction/bearing and overall data quality


#1

Hi there,

I’m currently using the countdown ‘instant_V1’ api for my application and I’m thinking about migrating over to the unified API.

However, I’m noticing that some of the quality of the data of this newer API is going to worsen the user experience.

Firstly, in the countdown API - I’m getting a ‘Bearing’ property back in degrees. I then use an arrow on top of bus stop pins to show the direction the bus goes. This arrow is exact to the direction of the road. In the newer API I get back one of 8 directions (N, NE,E,SE,S etc). This shows oddly and sometimes incorrectly on some bus stops.

Secondly, some bus stops are in the wrong location vs the older countdown API. E.g. Burnt Oak station, stop R.

  • Do you plan to deprecate the countdown api?
  • Is the stop direction something you’d consider iterating on? Perhaps adding a bearing property to the API? Please check out ‘dubbledecker’ from the iOS app store and have a look at the map view to see what I mean. It’s one of the most loved features of the app as it helps users to identify their desired bus stop quickly.
  • In the case of the incorrect location for Burn Oak - How often is bus stop location data improved?

Cheers!

Kish


#2

Hi Kish, thanks for the feedback. The points you’ve raised about data quality are very important to us so I’ll get them chased up by our technical team.

  • We don’t have any plans to deprecate the countdown API;
  • Exposing the bearing in degrees in the Unified API would be useful TECH-221;
  • We’ll investigate the Burnt Oak data issue you’ve reported - Countdown and the Unified API should be in sync, as they both rely on the same reference data sets. The data is reloaded from source (MoT and the timetable team here) at least once a week. SVC-3594

#3

Perfect, thanks for the reply Tim!

I see you have included some ticket reference codes, is there a public way to see the progress of those? I’d love to be able to migrate over to the unified API fully eventually.


#4

I’m afraid they’re internal references for the time being, but we will update forum threads when those problems are resolved.