geographical accuracy

[Raphael Mankin]

Be wary when using code issued by the Ordnance Survey. It may well have
been updated since I used it, but when they sent me their booklet on the
transformations I found that the algorithms did not always converge with
32-bit arithmetic. There were problems with chains divisions that lost
so much accuracy that they would only converge on a 64-bit arithmetic
unit.

I had to reorganise several expressions of the form a/b/c to read
a/(b*c). Sometimes the sequence of divisions occurred in separate
statements, so the rewriting was not always entirely obvious.

Anyway, if you are losing accuracy look carefully at the code you were
given. Or use Snyder's book, which does take account of these issues.

If you get stuck contact me off list and I will email you some C++ code.
(I really ought to get around to releasing it under LGPL.) I also have
code for Lambert equal area, Lambert conformal conic (France, Belgium),
Albers (USA), Bonne (Portugal), Mercator, Oblique Mercator (Switzerland,
Indonesia), equidistant conic, Cassini, strereographic (Netherlands),
van der Grinten and Miller projections. 

van der Grinten and Miller projections are mostly useful for whole-world
maps where they are more convenient than Mercator.

On Sat, 2007-02-24 at 13:45 +0000, Graham Seaman wrote:
> Just in case anyone else runs into the same issue, here's a description 
> of the problem and a (bodgy) solution:
> 
> The task:
> Given a set of UK ordnance survey eastings and northings, convert them 
> into latitude and longitude for use with google maps
> 
> The problem: Geo::Coordinates::OSGB and Geography::NationalGrid::GB,  
> when (correctly) set to use the WSG84 ellipsoid return values which 
> agree with one another to 6 decimal places. Unfortunately the results 
> only agree to 2 decimal places with the values expected by Google maps. 
> The Google map value coincides with the results returned by the 
> reference converter at http://gps.ordnancesurvey.co.uk/convert.asp, so 
> there is nothing strange happening at the google end.  But I have around 
> 20 metres of error in my output, enough to look silly on the map 
> (features in the middle of rivers, in roads, etc)
> 
> 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..
> 
> Cheers
> Graham
>