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 http://www.nearby.org.uk/coord.cgi?p=NW3+3HJ, 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!)