/StopPoint search by radius is inaccurate

Unified API
1

Hi,

I’m developing a web app and want to show the nearest bus stop(s) to the user.

Unfortunately, the /StopPoint search within a radius of a given lat/lon pair seems to be almost useless as it is truncating the given lat= and lon= to only three places of decimals. Sometimes, when standing at a bus stop, the inaccuracy is so great that the stop you’re standing at is outside the 200m radius search!

As an example, the following query:
https://api.tfl.gov.uk/StopPoint?radius=200&stopTypes=NaptanBusCoachStation,NaptanPublicBusCoachTram&lat=51.5267869&lon=-0.1072012

Returns as part of the JSON:

"$type": "Tfl.Api.Presentation.Entities.StopPointsResponse, Tfl.Api.Presentation.Entities",
  "centrePoint": [
    51.526,
    -0.107
  ],

which rather proves the point. Could this be fixed please, or do I need to source my own database of accurate stop locations?

I know that when returning a bus stop’s StopPoint, the lat and lon are returned to 6 decimal places. Not quite GPS accuracy, but certainly close enough to be useful; this makes it doubly odd that the search is limited to only 3 decimal places!

Thanks in advance,

John

2

This is true. I worked around this by first adding a few hundred meters to my search radius.

When the data returned there was more than I needed, so I used a lat,long pair to distance meters calculation to work out which of the items returned was within my original search radius.

Yes, it’s always annoying to have this, but it it also understandable that the back-end needs to use three decimal places to allow for request caching.,

3

Yes. I can see that limiting to only 3 decimal places increases the cache-ability hugely, and therefore may well not get changed. But arguably, by not presenting the user with their nearest StopPoint the API is not particularly useful.

If it seems that this cannot be “fixed”, then API users would either need to (a) do as you did, placing additional load on the server to pull back too many StopPoints, wasting CPU time and bandwidth at both ends; or (b) create a local database of StopPoint locations and query that, with the appropriate update overhead that entails.

I’m hoping for a answer to this either way, or else I’ll have to investigate an alternative solution, which would leave the (otherwise excellent) API unused.

John

1 Like
4

@briantist is correct - the aim of the rounding is to improve cacheability. The third decimal place is usually accurate to with ~100m, so the issue here is perhaps that 200m isn’t a great default for the radius parameter. But since users can increase that value fairly easily, it’s not really an issue.

@JohnSmith I would suggest increasing the radius to at least 300m should fix your problem. (Option a) in your list).

Some native applications I’m aware of do retrieve all StopPoints into a local database (e.g. by paging through /StopPoint/Mode/bus) this is useful if you need very rapid resolution of nearby assets - i.e. within milliseconds of app startup.

1 Like
5

Thanks for the reply, Tim. I’ll take some remedial action in my code. :slight_smile: