On Sun 04 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
I think we should have this fixed in the latest SVN. It has code (using MySociety's Geo::HelmertTransform) which is able to do the switch between WGS84 and OSGB36, which then allows your eastings and northings to come out correct.
I think you just need to install Geo::HelmertTransform, set geo_handler to 1, and force_wgs84 to 0
I don't think this is quite it. As I understand it, this is what's happening:
I'm putting OSGB eastings/northings into the Guide edit form (either direct from my GPS or converted on the OS website). The Guide is running Geography::NationalGrid::GB on it, to convert these into OSGB lat/long. This gets stored in the database.
For Google maps display, the stored OSGB lat/long are converted using Helmert transforms into WGS84 lat/long, and passed to Google to do its thing.
The data in the database, and displayed on the page in RDF, are still in OSGB lat/long, though. This is a problem because (a) the RDF is claiming that these are WGS84 (xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#") and (b) people will assume the lat/long displayed on the page are WGS84, because (as far as I know) nobody actually uses OSGB lat/long.
We could use Geo::HelmertTransform in other places in the code in order to make the database lat/long into WGS84 - but this is still only an approximation. I'd really like the option to configure my Guide to use something more exact (the OS reference implementation), since my GPS readings are already inexact.
(I wouldn't have any problem rewriting everything in my Guide in order to correct the lat/long data already in the database, BTW.)
(Alternatively, Graham's code uses the datafiles from the reference implementation to change OSGB x/y into WGS84 x/y, so something along these lines could be plugged in before we run Geography::NationalGrid::GB, but this would involve someone writing a (admittedly of wider use) module that bundled the datafiles.)
Does that make sense? Have I got anything wrong?
Kake