The GeoTIFF format identifies geodetic datums primary by reference to EPSG datum identifiers. It is also possible to define datum by providing the underlying ellipsoid definition.

In order to effectively use geospatial data it is important to be able to transform between datums. When a well known EPSG datum code is used, it is possible to either lookup available datum shift transformations from/to that datum in the EPSG dictionary or for software packages to maintain a preferred datum transformation for these well known datums. However, there is currently no way of expressing which of several available datum transformations is preferred for a particular dataset in GeoTIFF, nor is there a way of providing a suggested datum shift transformation for user defined datums.

As a step forward, I (Frank Warmerdam) am proposing to extend the GeoTIFF specification with a new GeogTOWGS84GeoKey parameter which could hold the 3/7 parameter datum shift to WGS84 in a manner similar to the TOWGS84[] parameter in OGC WKT coordinate system definitions as defined in OGC document 01-009 OpenGIS Implementation Specification: Coordinate Transformation Services.

OGC TOWGS84 Definition

That document defines the parameter this way:

This indicates a list of up to 7 Bursa Wolf transformation parameters. These parameters can be used to approximate a transformation from the horizontal datum to the WGS84 datum. However, it must be remembered that this transformation is only an approximation. For a given horizontal datum, different Bursa Wolf transformations can be used to minimize the errors over different regions.

If the DATUM clause contains a TOWGS84 clause, then this should be its "preferred" transformation, which will often be the transformation which gives a broad approximation over the whole area of interest (e.g. the area of interest in the containing geographic coordinate system). Sometimes, only the first three or six parameters are defined. In this case the remaining parameters must be zero. If only three parameters are defined, then they can still be plugged into the Bursa Wolf formulas, or you can take a short cut. The Bursa Wolf transformation works on geocentric coordinates, so you cannot apply it onto geographic coordinates directly. If there are only three parameters then you can use the Molodenski or abridged Molodenski formulas.

The DATUM clause may not contain a TOWGS84 clause in the following situations:

a) The writing application was using the Simple Features specification, which does not specify TOWGS84 as a valid keyword

b) The writing application did not have an available transformation.

c) There is no possible transformation. For example, the horizontal datum could be a surface that rotates relative to the Earth's surface.

In particular, if the DATUM does contain a TOWGS84 clause, and the parameter values are zero, then the receiving application can assume that the writing application believed that the datum is approximately equal to WGS84.

Parameter Definition

GeogTOWGS84GeoKey

KeyID = 2062
Type = 3/7 * DOUBLE
Values = dX, dY, dZ, Rx, Ry, Rz, dS

This key allows the specification of a position vector 7 parameter transformation (as defined by EPSG:9606) between the coordinate reference system of the file and the WGS84 system. dX, dY and dZ define the translation vector and are given in meters. Rx, Ry and Rz define the rotation in seconds of an arc. dS is the scale correction expressed in parts per million.

Note that there exists another 7 parameter transformation (the coordinate frame rotation, EPSG:9607) which differs from the method used here only in the signs of the rotation parameters Rx, Ry, Rz.

Also the more simple 3 parameter transformation (geocentric translation, EPSG:9603) can be expressed with this geokey by simply setting Rx, Ry, Rz and dS to zero.

GeoTIFF Implementation

I propose to add a new GeogTOWGS84GeoKey with the value 2062. It will be rather unique numeric geokeys in having more than one value though the libgeotiff API is already setup to handle this gracefully. The values key would have either 3 or 7 values as discussed in the OGC document.

Furthermore, the normalization API (GTIFGetDefn() function and GTIFDefn structure) will be extended to hold the TOWGS84 parameters if they are in the file. No attempt will be made to lookup a TOWGS84 transformation from the EPSG database at this time as part of normalization.

The changes are incorporated into libgeotiff trunk (r1983) and will appear in libgeotiff 1.3.1 when released.

Sample File

A sample file prepared by Christian Zietz can be found at:

​http://download.osgeo.org/geotiff/samples/GeogToWGS84GeoKey

Recording EPSG Transformations

In keeping with the GeoTIFF approach of referencing definitions from EPSG whereever possible, it might also be desirable to have a GeoKey to reference an EPSG transformation method as preferred. This GeoKey would presumably reference the "coord_op_code" identifier in the EPSG coordinate_operation table. I have not prototyped this yet.