geographical accuracy

[Dirk Koopman]

Andy Armstrong wrote:
> On 24 Feb 2007, at 13:45, Graham Seaman wrote:
>> The partial solution (a better one would be to rewrite one of the perl
>> modules..): download the document 'Transformations and OSGM02 User
>> Guide' from the gps.ordnancesurvey site. Apply the iterative
>> transformation titled 'inverse transformation (OSGB36 to ETRS89)' 
>> (page 22) to your OS eastings and northings, using the lookup tables
>> provided in the zip file with the document. Use the resulting  ETRS89 
>> eastings and northings as input to either of the two perl modules.
>> Result: on a quick sample of the outputs, I'm getting around 4 to 5
>> decimal places of agreement with google and the reference converter.
>> Not perfect, but good enough for what I need..
> 
> Glad you got it sorted.
> 
> I have a Perl implementation here that I derived from the information on
> the OS site. That gets ~5 DP of accuracy compared with streetmap.co.uk's
> conversion. I guess I should release it.
> 

You should.

I have C implementations, but a pure perl one would be much better.

The OSGB transformations are all based on iterative polynomial
operations whereas the all the 'simple' transformations that claim to do
OSGB are fairly straight line trig based on (universal) transverse
mercator type conversions. Always use the real OSGB algorithms.

And then there are the fudge factors :-)

Still, 20m is not bad considering that when I was trying to do
WGS84->UTM for New Delhi, the error was nearer 100-120m - but then I
discovered that the spheroid was "Everest 18??" and that the maps are
deliberately offset by a non-constant fudge factor which you are only
told if you successfully get to do the job for them.