GPS Coordinate transformations

[Lev Bishop]

On Thu, 5 Sep 2002, Olly Betts wrote:

> Sorry for a very belated reply (nearly 8 months later!)
> 
> On Sun, Jan 13, 2002 at 09:05:36PM +0000, J Wood wrote:
> > 1. Can anyone point me in the direction of the appropriate transformation
> > from GPS Lat, Lon, Height to UK OS grid reference?

The OS has an extremely helpful guide, which is very readable and gives an
excellent overview of Terrestrial Reference Systems, Terrestrial Reference
Frames (and how its confusing that people often use "datum" to mean either
TRS or TRF depending on the circumstances), grid systems, height datums,
coordinate system conversions, various equations for converting lat-long
to/from grid coords, lat-long to/from cartesian coords, and so forth. Its
very useful, non-mathematical and very easy-to-read and anyone who needs
to convert coordinates should read it to get the "big picture" before
getting their hands dirty with GEO/Tralaine/etc.

This document is at:
http://www.gps.gov.uk/guidecontents.asp
Read it!

> GEO can do conversions between pretty much any pair of coordinate
> systems.  It's a bit cryptic though - you need to write a script file
> to convert coordinates:

GEO can do conversions between TRSs but _cannot_ convert between TRFs.  
This means that it may or may not be very accurate in any given situation.  
Eg, for the UK it could manage about 5m accuracy. It can only convert
between grids that are a variant of Transverse Mercator (aka Gauss-Kruger)
projections, which covers many national grids but not, all (eg france has
a lambert conformal conic projection, switzerland has a double projection
first onto a sphere and then onto the plane, etc) so that may make it
unsuitable. It is capable of 7-parameter Helmert transormations (giving
5mish accuracy for the UK), but the datum.cfg file supplied with it has
only 3-parameter transformations (almost certainly taken from NIMA
technical report TR8350.2, available at
http://www.nima.mil/GandG/tr8350_2.html ) in all but 2 cases so you'd have
edit it with your own Helmert parameters. (one place to find them is from
NATO:  ftp://164.214.2.65/pub/gig/datums/NATO_DT.pdf , or for the UK the 
helmert parameters are given in the OSGB guide mentionned at the start of 
this message.)

As Olly said GEO is also a bit difficult to use because of its scripting 
language.

A bit easier to use and a lot more full-featured is Tralaine, which can 
deal with all sorts of crazy grid projections (oblique mercator, 
Modified Polyconic Azimuthal Equal Area, etc, etc) 
has a nice windows interface but is definitely not Free. I think mostif 
not all of its conversions are between TRSs and hence at the 5m or worse 
accuracy level but it might be able to do TRF conversions in special cases 
where it has the parameters (I haven't looked closely enough to be sure).
http://www.mentorsoftwareinc.com/

For the UK there is a program OSTN02 which converts between WGS-84
(realized as ETRS-89 in high accuracy surveys) and OSGB36 (the reference
frame of the national grid). This is a full TRF converter. In fact OSGB36
is now *defined* by the results of OSTN02 when applied to ETRS-89
coordinates. For vertical coordinates there is a similar programme OSGM02
which converts from WGS-84 (ETRS-89) ellipsoid heights to ODN heights. ODN
is not defined by OSGM02, but OSGM02 matches to within 2cm to ODN.

OSTN02 and OSGM02 are available at http://www.gps.gov.uk/ Since they are
Free and precise there is no reason not to use them for UK projects. One
thing to be aware of if you use OSGM02 is that it needs ellipsoid heights
as input and I'm pretty sure no handheld GPSs actually give you the
ellipsoid height, so there may be no point in using OSGM02 or indeed in
trying to convert the height datum at all (see discussion at the end of
this message).

> As others suggested, you could just type coordinates into a GPS and read
> them back in the other system.  However I've read that some GPS units use
> simplified coversion formulae which only approximate the correct answer.
> Which units and how approximate I don't know I'm afraid.

Sticking with OSGB36 as an example, if you read
http://www.gps.gov.uk/gpssurveying.asp#gpssurveying6 you'll see that to
convert precisely from WGS-84 to OSGB36 you need just under 2 million
parameters for the conversion. And that's just for the UK.  Clearly no GPS
unit is going to devote several megs of ram to doing precise conversions
per country. The manufacturers of GPS units don't give details on the
formulas used but it seems likely that they just do a TRS conversion
rather than a TRF conversion. For the UK, if a full Helmert transformation
is done you can acheive accuracies in the conversion of about 5m. For
larger land masses than the UK, or in places where the surveying was not
as careful as in the UK and the TRF is more distorted, the discrepancies
could be much larger. Also bear in mind that many countries consider
precise mapping a matter of national security and thus accurate TRS
conversion parameters may not be available for all areas, let alone TRF
parameters.  On top of this, the actual equations for the full helmert
conversion require fairly complicated iterative proceedures to calculate,
and its likely that most receivers will instead use the simplified
Molodensky transforms which don't proceed via cartesian coordinates and
hence are simpler and faster to evaluate, but because they don't include
the rotation parameters, are less accurate still. A further problem with
using the conversions built into GPS units (most of which are also limited
to Transverse-Mercator/Gauss-Kruger type grids) is that frequently they
don't use the official names for the datums and since you can't get access
to the underlying equations you can never be sure whether the GPS units'
"Europe" datum is supposed to be the ED50 datum or some other one. All in
all its almost certainly best to record GPS positions in WGS-84 and use
some other software to convert coordinates. At least that way you know 
whats happening to your data.

Similar programmes to OSTN02 and OSGM02 may be available from other 
countries' mapping agencies. I think Australia and the USA at least have a 
similar scheme whereby the national TRF is defined by such a programme. 

At the end of th day, if all you want to do is to fix a bunch of
entrances using GPS then since only _relative_ positions matter, you don't
even need to convert coordinates. If you have a dataset where some fixes
come from GPS and others come from a local TRF, eg surface surveys to trig
points or mountain peaks, features read off maps, etc., then you'll need
to do some conversions. In the UK and some other countries there is
software to do the conversion precisely because thats the definition of
the conversion, in other cases you'll have to do approximate conversions,
which might be off by maybe 50m if all you have is molodensky coefficients
for a large area and are unlucky, or maybe 5m if you have the 7 Helmert
coefficients.  Still, doing the conversion is better than not doing the
conversion because if you don't you could be as much as a kilometre out.

If your mapping area is small and thus TRF distortion is small across it,
you can always measure the transformation from WGS-84 to local coords
simply by GPSing 4 or more points with known coords in the local system
and then fitting a translate-scale-rotate transformation between the
systems.  Taking more than 4 points will allow you to estimate the error
in this process, and of course you'll want to space these "control points"
evenly across your area of interest.

Finally, a word about heights. Height datums are traditionally separate to
horizontal datums for practical surveying reasons. It is even trickier to
convert between local and global height references than for the horizontal
case.  Thankfully handheld GPS units aren't accurate enough in h for this
really to be an issue and instead you're stuck with reading contours off a
map or using a barometric altimeter (calibrated of necessity to a height
reference in the local system). There are differences of up to 100m
between ellipsoid height and geoid height, but I think modern GPS
receivers don't ever output ellipsoid height but rather have their own
geoid model internally (likely based on a truncated version of the order
and degree 360 spherical harmonic expansion of EGM96 global geoid model
(which has 130317 parameters in its full form)). This will some kind of
height-above-MSL output from the unit with unspecified conversion accuracy
but almost certainly swamped by the receivers height measurement error
rather than the geoid model's accuracy (except perhaps when WAAS or
similar is used, or when the unit has a built in altimeter as well (as in
the case of some of the eTrex models)). If we wanted to attempt to perform
accurate height conversions we'd first have to remove the GPS's built-in
and unknown geoid model before applying our own vertical datum conversion
to it. This will be near impossible unless we can discover the details of
the internal geoid model from the manufacturer (unlikely). However, as I
said all of this is pretty much irrelevant because the measurement error
of a consumer GPS unit in the vertical dimension is nearly always going to
be the limiting factor. Calibrated altimeters are what you need to do 
better than this. For data processing of those appropriate to cavers uses 
see:
http://www.biber.fsnet.co.uk/altim.html

Hope all of that made some sense and was useful to somebody....

To reiterate: read the OSGB guide and reach enlightenment:
http://www.gps.gov.uk/guidecontents.asp

Lev

PS: I'm not trying to sound authoritative on this subject. I don't really 
know any more about it than what I've learnt by reading the documents I've 
linked to in this email. So probably some of what I've said is completely 
wrong and you shouldn't take anything I've said as gospel... I'd hate for 
you to invest a lot of effort in a surveying project and have it all 
invalidated because you listened to me :-)