OGC GeoTIFF standard

A GeoTIFF file is a valid TIFF 6.0 file.

The GeoKeyDirectoryTag Requirements Class specifies the requirements for implementing the reserved GeoKeyDirectoryTag TIFF tag.

A GeoTIFF file stores projection parameters in a set of "Keys" which are virtually identical in function to a TIFF tag, but have one more level of abstraction above TIFF. Like a tag, a Key has an ID number ranging from 0 to 65535, but unlike TIFF tags, all key ID’s are available for use in GeoTIFF parameter definitions.

The Keys in GeoTIFF (also called "GeoKeys") are all referenced from the GeoKeyDirectoryTag tag. The first four keys form the GeoKey Directory Header. The keys which make up this header are: KeyDirectoryVersion, KeyRevision, MinorRevision, and NumberOfKeys.

The GeoKey Directory Header is followed by <NumberOfKeys> Key Entries. Each Key Entry consists of four values.

For consistency, several key codes have the same meaning in all implemented GeoKeys

The "undefined" code means that this parameter is intentionally omitted or unknown.

In some cases, additional GeoKeys are required when the "User-Defined" value is used. Those requirements are included within a Requirements Class, where appropriate.

The following requirements govern the storage of parameter values when there are two or more values of type Short.

The following requirements govern the storage of parameter values when the values are of type Double.

The following requirements govern the storage of parameter values when the values are of type ASCII. All text values in a TIFF file must be null-terminated ASCII.

Example of a GeoAscii tag containing only one string: "NAD27 / UTM zone 11N|{NULL}" (where {NULL} is the ASCII character of code 0)

Example of a GeoAscii tag containing two strings: "NAD27 / UTM zone 11N|NAD27|{NULL}"

This requirements class establishes the Raster Space used. There are currently only two options: RasterPixelIsPoint and RasterPixelIsArea. No user-defined raster spaces are currently supported. For variance in imaging display parameters, such as pixel aspect-ratios, use the standard TIFF 6.0 device-space tags.

The use of this geokey is highly recommended for accurate georeferencing of raster.

This GeoKey defines the type of Model coordinate reference system used, to which the transformation from the raster space is made:

If the Model coordinate reference system is from the GeoTIFF standard CRS register (i.e., EPSG register), then only the registered CRS code need be specified. See Requirements for definition of Model CRS (when Model is from GeoTIFF CRS register).

If the Model coordinate reference system is not from the GeoTIFF standard CRS register, then it requires the specification of some or all CRS elements. See Requirements for definition of user-defined Model CRS.

The GeoTIFF v1.0 format has also been used to describe pseudo-3D compound CRSs consisting of a projected CRS and a vertical CRS or a geographic 2D CRS and a vertical CRS, as well as a geographic 3D CRS. In this document, this usage is permitted but not explicitly described through the GTModelTypeGeoKey. Recommendations are given in Annex D.

When the Model CRS is included in the GeoTIFF CRS register (i.e., EPSG register), only its register code is required. For 2D projected CRSs ("map grids") the code is given through the ProjectedCRSGeoKey. For geodetic CRSs (geographic 2D and geocentric CRSs) the code is given through the GeodeticCRSGeoKey. If the Model CRS is a pseudo-3D compound CRS consisting of either a projected 2D CRS or a geographic 2D CRS together with a vertical CRS, the code of the vertical component is given through the VerticalGeoKey.

This key is used to specify the projected coordinate reference system from the GeoTIFF CRS register or to indicate that the Model CRS is a user-defined projected coordinate reference system.

This key is provided to specify the geodetic (geographic or geocentric) coordinate reference system from the GeoTIFF CRS register or to indicate that the Model CRS is a user-defined geodetic coordinate reference system.

This key is provided to specify the vertical coordinate reference system from the GeoTIFF CRS register or to indicate that the CRS is a user-defined vertical coordinate reference system. The value for VerticalGeoKey should follow the recommendations for including height in model CRS definitions as provided in Annex D.

The GTCitationGeoKey is provided to give an ASCII reference to published documentation on the overall configuration of the GeoTIFF file. The GeodeticCitationGeoKey, ProjectedCitationGeoKey and VerticalCitationGeoKey are used to describe Model CRS elements through ASCII free text. A citation may be included with a CRS identified through the GeoTIFF CRS register ([Requirements for definition of Model CRS (when Model CRS is from GeoTIFF CRS register)]). A citation is mandatory for a user-defined CRSs and CRS objects (Requirements for definition of user-defined Model CRS). The GeodeticCitationGeoKey, ProjectedCitationGeoKey and VerticalCitationGeoKey are used with CRSs and CRS components.

These keys are used to specify Units of Measure (UoM) through the identification of a unit from the GeoTIFF CRS register or to indicate that the unit is user-defined.

The GeogAngularUnitsGeoKey key is used to specify the angular unit for:

The GeogAzimuthUnitsGeoKey key is used to specify the angular unit for user-defined map projection parameters when these differ from the angular unit described through the GeogAngularUnitsGeoKey.

The GeogLinearUnitsGeoKey key is used to specify the linear unit for:

The ProjLinearUnitsGeoKey key is used to specify the linear units for:

The VerticalUnitsGeoKey key is used to specify the linear unit for:

These keys allow the definition of size of user-defined angular and linear units, given in the SI base unit for that unit type (meters for length, radians for angle).

Note: this specification does not support user-defined units for vertical coordinate reference systems.

This key may be used to specify the vertical datum for a user-defined vertical coordinate reference system.

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/Core

Requirements:

Purpose: Verify that the GeoTIFF file conforms to the TIFF specification.

Pre-conditions: None

Test Variables: None

Test Process:

There is no authoritative conformance test for TIFF 6.0. 2 basic tests may be done on TIFF header (4 first bytes), called TIFF magic: • Bytes 0-1 (byte order within the file) = 0X4949 ("II" = little endian) or 0X4D4D ("MM" = big endian). • Bytes 2-3 = the short integer value 42 interpreted using the byte order specified in bytes 0-1.

The best that can be achieved is to use a TIFF reference implementation to successfully read a GeoTIFF file. The OGC recommends the use of tiffdump based on the open source LibTIFF library (https://gitlab.com/libtiff/libtiff) for dumping the content of TIFF tags (displaying error messages if any), or opensource TIFF file validator (such as the JHOVE tool, opensource developed in Java - cf. http://jhove.openpreservation.org/).

Once TIFF 6.0 conformance has been validated, execute test http://www.opengis.net/spec/GeoTIFF/1.1/conf/TIFF.Tags.

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/TIFF.Tags

Requirements:

Purpose: Verify the TIFF header and prepare for processing the GeoTIFF tags.

Pre-conditions: None

Test Variables:

Test Process:

Validate and process the TIFF header

Process each IFD using the following pseudocode:

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/GeoKeyDirectory

Requirements:

Purpose: Verify the GeoKey Directory

Pre-conditions A GeoKey Directory has been located

Test Variables:

Test Process:

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/ShortParameters

Requirements:

Purpose: Verify Short parameters

Pre-conditions The GeoKeyDirectory and GeoKeyOffset values have been set Test Variables:

Test Process:

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/DoubleParameters

Requirements:

Purpose: Verify Double parameters

Pre-conditions The GeoKeyDirectory, DoubleValues and GeoKeyOffset values have been set.

Test Variables:

Test Process:

Double GeoKey Tests

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/AsciiParameters

Requirements:

Purpose: Verify ASCII parameters

Pre-conditions The GeoKeyDirectory, ASCIIValues and GeoKeyOffset values have been set.

Test Variables:

Test Process:

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/Raster2Model_CoordinateTransformation_GeoKey/ModelPixelScaleTag

Requirements:

Purpose: Verify the contents of the ModelPixelScaleTag parameter

Pre-conditions The TagLength and TagValue values have been set.

Test Variables:

Test Process:

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/Raster2Model_CoordinateTransformation_GeoKey/ModelTiepointTag

Requirements:

Purpose: Verify the contents of the ModelTiepointTag parameter

Pre-conditions The TagLength and TagValue values have been set.

Test Variables:

Test Process:

Test id: http://www.opengis.net/spec/GeoTIFF/1.1/conf/Raster2Model_CoordinateTransformation_GeoKey/ModelTransformationTag

Requirements:

Purpose: Verify the contents of the ModelTransformationTag parameter

Pre-conditions The TagLength and TagValue values have been set.

Test Variables:

Test Process:

The GeoTIFF 1.0 specification (Ritter and Ruth, 1995) includes a detailed description of the structural approach used in GeoTIFF and the semantics and values of the tags. The tag specifications are included in Clause 7 of this standard as requirements. This Annex provides an informative overview of the structure of a GeoTIFF file and tags. Much of this information is excerpted from Ritter and Ruth, 1995.

GeoTIFF fully complies with the TIFF 6.0 specifications, and its extensions do not in any way go against the TIFF recommendations, nor do they limit the scope of raster data supported by TIFF.

GeoTIFF uses a small set of reserved TIFF tags to store a broad range of georeferencing information, catering to geodetic as well as projected coordinate reference system needs. No information is stored in private structures, IFD’s or other mechanisms that would hide information from naive TIFF reading software.

GeoTIFF uses a "MetaTag" (GeoKey) approach to encode dozens of information elements into just 6 tags, taking advantage of TIFF platform-independent data format representation to avoid cross-platform interchange difficulties. These keys are designed in a manner parallel to standard TIFF tags, and closely follow the TIFF discipline in their structure and layout. New keys may be defined as needs arise, within the current framework, and without requiring the allocation of new tags from Aldus/Adobe.

GeoTIFF uses numerical codes to describe coordinate reference systems, datums, ellipsoids, etc. The codes are derived from the EPSG list compiled by the International Association of Oil and Gas Producers, and mechanisms for adding user-defined systems or their components have been established. The GeoTIFF information content is designed to be compatible with the data decomposition approach used by the National Spatial Data Infrastructure (NSDI) of the U.S. Federal Geographic Data Committee (FGDC).

While GeoTIFF provides a robust framework for specifying a broad class of existing coordinate reference systems, it is also fully extensible, permitting internal, private or proprietary information storage. However, since this standard arose from the need to avoid multiple proprietary encoding systems, use of private implementations is to be discouraged.

Every effort has been made to adhere to the philosophy of TIFF data abstraction. The GeoTIFF tags conform to a hierarchical data structure of tags and keys, similar to the tags which have been implemented in the "basic" and "extended" TIFF tags already supported in TIFF Version 6 specification. The following are some points considered in the design of GeoTIFF.

GeoTIFF requires support for all documented TIFF 6.0 tag data-types, and in particular requires the IEEE double-precision floating-point "DOUBLE" type tag. Most of the parameters for georeferencing will not have sufficient accuracy with single-precision IEEE, nor with RATIONAL format storage. The only other alternative for storing high-precision values would be to encode as ASCII, but this does not conform to TIFF recommendations for data encoding.

It is worth emphasizing here that the TIFF spec indicates that TIFF-compliant readers shall honor the 'byte-order' indicator, meaning that 4-byte integers from files created on opposite order machines will be swapped in software, and that 8-byte DOUBLE’s will be 8-byte swapped.

A GeoTIFF reader/writer, in addition to supporting the standard TIFF tag types, must also have an additional module which can parse the "Geokey" MetaTag information. A public-domain software package for performing this function is available (libgeotiff), see https://trac.osgeo.org/geotiff#libgeotiff.

This section describes the abstract file-format and "GeoKey" data storage mechanism used in GeoTIFF. Uses of this mechanism for implementing georeferencing and geocoding is detailed in sections Coordinate Transformations and Geocoding Raster Data.

A GeoTIFF file is a TIFF 6.0 file, and inherits the file structure as described in the corresponding portion of the TIFF spec. All GeoTIFF specific information is encoded in several additional reserved TIFF tags, and contains no private Image File Directories (IFD’s), binary structures or other private information invisible to standard TIFF readers.

The number and type of parameters that would be required to describe most popular projection types would, if implemented as separate TIFF tags, likely require dozens or even hundred of tags, exhausting the limited resources of the TIFF tag-space. On the other hand, a private IFD, while providing thousands of free tags, is limited in that its tag-values are invisible to non-savvy TIFF readers (which don’t know that the IFD_OFFSET tag value points to a private IFD).

To avoid these problems, a GeoTIFF file stores projection parameters in a set of "Keys" which are virtually identical in function to a "Tag", but has one more level of abstraction above TIFF. Effectively, it is a sort of "Meta-Tag". A Key works with formatted tag-values of a TIFF file the way that a TIFF file deals with the raw bytes of a data file. Like a tag, a Key has an ID number ranging from 0 to 65535, but unlike TIFF tags, all key ID’s are available for use in GeoTIFF parameter definitions.

The Keys in GeoTIFF (also call "GeoKeys") are all referenced from the GeoKeyDirectoryTag, which defined as follows (Clause 7.1).

This tag may be used to store the GeoKey Directory, which defines and references the "GeoKeys", as described below.

The tag is an array of unsigned SHORT values, which are primarily grouped into blocks of 4. The first 4 values are special, and contain GeoKey directory header information. The header values consist of the following information, in order.

Header={KeyDirectoryVersion, KeyRevision, MinorRevision, NumberOfKeys} where

This header is immediately followed by a collection of <NumberOfKeys> KeyEntry sets, each of which is also 4-SHORTS long. Each KeyEntry is modeled on the "TIFFEntry" format of the TIFF directory header, and is of the form:

Following the KeyEntry definitions, the KeyDirectory tag may also contain additional values. For example, if a Key requires multiple SHORT values, they shall be placed at the end of this tag and the KeyEntry will set TIFFTagLocation=GeoKeyDirectoryTag, with the ValueOffset pointing to the location of the value(s).

All key-values which are not of type SHORT are to be stored in one of the following two tags, based on their format:

This tag is used to store all of the DOUBLE valued GeoKeys, referenced by the GeoKeyDirectoryTag. The meaning of any value of this double array is determined from the GeoKeyDirectoryTag reference pointing to it. FLOAT values should first be converted to DOUBLE and stored here.

This tag is used to store all of the ASCII valued GeoKeys, referenced by the GeoKeyDirectoryTag. Since keys use offsets into tags, any special comments may be placed at the beginning of this tag. For the most part, the only keys that are ASCII valued are "Citation" keys, giving documentation and references for obscure projections, datums, etc.

Note on ASCII Keys.

Special handling is required for ASCII-valued keys. While it is true that TIFF 6.0 permits multiple NULL-delimited strings within a single ASCII tag, the secondary strings might not appear in the output of naive "tiffdump" programs. For this reason, the null delimiter of each ASCII Key value shall be converted to a "|" (pipe) character before being installed back into the ASCII holding tag, so that a dump of the tag will look like this.

A GeoTIFF-reader must check for and convert the final "|" pipe character of a key back into a NULL before returning it to the client software.

GeoKey Sort Order:

In the TIFF spec it is required that TIFF tags be written out to the file in tag-ID sorted order. This is done to avoid forcing software to perform N-squared sort operations when reading and writing tags.

To follow the TIFF philosophy, GeoTIFF-writers shall store the GeoKey entries in key-sorted order within the GeoKeyDirectoryTag.

The first line indicates that this is a Version 1 GeoTIFF GeoKey directory, the keys are Rev. 1.2, and there are 6 Keys defined in this tag.

The next line indicates that the first Key (ID=1024 = GTModelTypeGeoKey) has the value 2 (Geographic 2D), explicitly placed in the entry list (since TIFFTagLocation=0). The next line indicates that the Key 1026 (the GTCitationGeoKey) is listed in the GeoAsciiParamsTag (34737) array, starting at offset 0 (the first in array), and running for 12 bytes and so has the value "Custom File" (the "|" is converted to a null delimiter at the end). Going further down the list, the Key 2051 (GeogLinearUnitSizeGeoKey) is located in the GeoDoubleParamsTag (34736), at offset 0 and has the value 1.5; the value of key 2049 (GeogCitationGeoKey) is "My Geographic."

The TIFF layer handles all the problems of data structure, platform independence, format types, etc., by specifying byte-offsets, byte-order format and count, while the Key describes its key values at the TIFF level by specifying Tag number, array-index, and count. Since all TIFF information occurs in TIFF arrays of some sort, we have a robust method for storing anything in a Key that would occur in a Tag.

With this Key-value approach, there are 65536 Keys which have all the flexibility of TIFF tag, with the added advantage that a TIFF dump will provide all the information that exists in the GeoTIFF implementation.

This GeoKey mechanism is used extensively in Clause 7 where the parameters for defining Coordinate Reference Systems and, if necessary, their underlying component elements are specified.

In standard TIFF 6.0 there are tags that relate raster space R with device space D, such as monitor, scanner or printer. The list of such tags consists of the following:

In GeoTIFF, provision is made to identify earth-referenced coordinate systems (model space M) and to relate M space with R space. This provision is independent of and can co-exist with the relationship between raster and device spaces. To emphasize the distinction, this specification shall not refer to "X" and "Y" raster coordinates, but rather to raster space "J" (row) and "I" (column) coordinate variables instead, as defined in section Raster Space.

'Real world' coordinate reference systems are imposed on models of the earth, hence the term model coordinate reference system used in GeoTIFF.

In GeoTIFF, standard CRSs are identified through reference to an EPSG CRS code. This is sufficient to define the CRS component objects. Further information on EPSG codes is given in [Requirements for definition of Model CRS (when Model CRS is from GeoTIFF CRS register)].

GeoTIFF attempts to allow Model CRSs that are not described in the standard CRS register to be defined through user-defined keys. However the provisions made are limited in that:

In practice, user-defined Model CRS definition is limited to the following cases.

For the transformation from raster space to model space, some implicit convention is made about axis positive direction and axis order. It is assumed that:

Within the EPSG Dataset each object has a code. There have been three generations of coding.

The GeoTIFF v1.0 specification refers to "obsolete EPSG/POSC codes." These refer to the numeric part of the alphanumeric coding in (i) above. These values had been used in some GeoTIFF v0.x files and for backward compatibility with those earlier files GeoTIFF v1.0 retained references to them. As all of these alphanumeric codes were changed to the integer coding in (ii) above, reference to these obsolete codes should now be unnecessary. In effect, for model CRS GeoKeys the obsolete code range may be treated as a reserved code range.

Note: 'EPSG/POSC obsolete codes' refers specifically to the coding in generation (i) above, and should not be confused with codes from generations (ii) and (iii) which have been given the status of 'deprecated.'

A reference to an EPSG coordinate reference system code is sufficient for a complete definition: it implies use of the CRS components (datum, ellipsoid, map projection, etc.) that are associated with that CRS in the EPSG Dataset definition. The EPSG codes for coordinate reference system components should only be referenced when describing a user-defined coordinate reference system.

We have an aerial photo which has been orthorectified and resampled to a UTM grid, zone 60, using WGS 84 coordinate reference system; the coordinates of the upper-left corner of the image are given in easting/northing, as 350807.4m, 5316081.3m. The scanned map pixel scale is 100 meters/pixels (the actual dpi scanning ratio is irrelevant).

Notes:

For the rest of these examples we will only show the GeoKey-level dump, with the understanding that the actual TIFF-level tag representation can be determined from the documentation.

We have a USGS State Plane Map of Texas, Central Zone, using NAD83, correctly oriented. The map resolution is 1000 meters/pixel, at origin. There is a grid intersection line in the image at pixel location (50,100), and corresponds to the projected coordinate reference system easting/northing of (949465.0, 3070309.1).

Notice that in this case, since the projected CRS is a standard code, we do not need to define the base Geographic CRS, geodetic datum, etc, since those are implied by the projected CRS code. Also, since this is NAD83, meters are used rather than US Survey feet (as in NAD27).

We have a 500 x 500 scanned aeronautical chart of Seattle, WA, using Lambert Conformal Conic projection, correctly oriented. The central meridian is at 120 degrees west. The map resolution is 1000 meters/pixel, at origin, and uses NAD27 datum. The standard parallels of the projection are at 41°21’N and 48°40’N. The latitude of the origin is at 45 degrees North, and occurs in the image at the raster coordinates (80,100). The origin is given a false easting and northing of 200000m, 1500000m.

Notice that the Tiepoint takes the false easting and northing into account when tying the raster point (50,100) to the projection origin.

The U.S. Defense Mapping Agency (now NGA) produces ARC digitized raster graphics datasets by scanning maps and geometrically resampling them into an equirectangular projection, so that they may be directly indexed with WGS 84 geographic coordinates. The upper left corner is 120 degrees West, 32 degrees North. The scale for one map is 0.2 degrees per pixel horizontally, 0.1 degrees per pixel vertically. If stored in a GeoTIFF file it contains the following information:

We have an aerial photo, and know only the WGS 84 GPS location of several points in the scene: the upper left corner is 120 degrees West, 32 degrees North, the lower-left corner is at 120 degrees West, 30 degrees 20 minutes North, and the lower-right hand corner of the image is at 116 degrees 40 minutes West, 30 degrees 20 minutes North. The photo is not geometrically corrected, however, and the complete projection is therefore not known.

Remark: Since we have not specified the ModelPixelScaleTag, clients reading this GeoTIFF file are not permitted to infer that there is a simple linear relationship between the raster data and the geographic model coordinate space. The only points that are known to be exact are the ones specified in the tiepoint tag.

We have a scanned standard British National Grid, covering the 100km grid zone NZ. Consulting documentation for BNG we find that the southwest corner of the NZ zone has an easting, northing of 400000m, 500000m. This scanned map has a resolution of 100 meter pixels, and was rotated 90 degrees to fit onto the scanner, so that the southwest corner is now the northwest corner. In this case we must use the ModelTransformation tag rather than the tiepoint/scale pair to map the raster data into model space:

Remark: the matrix has 100.0 in the off-diagonals due to the 90 degree rotation; increasing I points north, and increasing J points east.