TFL (Actually Not) Off with API Data

UPDATE: I took another look at it, and it appears that TFL is giving its northing as 1,000,000-REAL_NORTHING (source), where REAL_NORTHING is the standard definition of northing based on the OSGB36 grid. I hadn’t noticed that beforehand. Maybe they do it to make all northings 6 digits?

The rest of the post I wrote on Tuesday is below:

I blogged yesterday about being unable to use the user’s current location in the Journey Planner API. I have managed to get around this issue by reverse-geocoding the user’s location (latitude/longitude) to an address, which works. The problem, however, wasn’t the reverse-geocoding (which is straightforward). The problem was that TFL did not recognize a lot of the addresses that were reverse-geocoded. After many hours of work, I built a small feature that clarifies the user’s inputs, in the same way that TFL does when a user gives an incomplete address. This feature works, but is dependent on TFL’s website staying the same (which will probably be the case), as it uses TFL’s “suggestions” to suggest more specific parameters.

For the moment, that has been taken care of. Unfortunately, I’ve encountered a new issue: eastings and northings. Eastings and northings are a form of coordinate system involving measured distances from a certain origin (in the east and north directions) along the Earth’s surface. It’s sort of like a grid map. For some reason, TFL prefers to use these over latitudes and longitudes, which is unfortunate for the rest of the world and for iPhones.

Having spent a long time understanding eastings and northings, as well as looking up ways to convert between the two programatically, I have managed to overcome that difficulty. I have a working piece of code that converts from northing/easting to latitude/longitude. However, it seems that TFL’s data for northings on its Journey Planner API is plain wrong. For example, for the postcode NW3 3HJ, TFL’s API gives the northing as 815532. However, using, I found the actual northing to be 184468. That’s a huge difference!

Somehow, the northings are correct in the rest of TFL’s feeds, just not in the journey planner API online. This is frustrating since I cannot accurately show a map between two points if I’m not given the right coordinates. If anybody could provide suggestions on how to correct this false northing, please let me know by commenting on this post. If someone from TFL (or a fellow developer) sees this, please let me know what I’m missing. Is the data supposed to be this far off?

Until next time (probably in 2012!)

Laksh Bhasin


4 thoughts on “TFL (Actually Not) Off with API Data

  1. Thanks for the post, I’ve been working in a way to convert from NE to lat/lon and I have partially managed to do so, they specify the use the Bessel 1841 Ellipse which I don’t know if is true, I think they are using plain osgb36.

    However I found that the conversions where plain wrong, they conversion worked for the buses stations but not for the journey planner route. If I do 1000000 – northing, being northing the value they specify on the XML, I get a reasonable location in London, seems to be alright. Is this what are you doing?

    • Hi,

      I think they are using OSGB36 coordinates.

      Yup, that’s exactly what I’m doing. 1,000,000-northing gives a very accurate location. Let me know if you have any more questions!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s