Geotiff Spec

8/12/2019 Geotiff Spec

1/95


2/95


3/95

+----------------------------------+

1.1 About this Specification

This is a description of a proposal to specify the content and

structure of a group of industry-standard tag sets for the managementof georeference or geocoded raster imagery using Aldus-Adobe's publicdomain Tagged-Image File Format (TIFF).

This specification closely follows the organization and structure ofthe TIFF specification document.

+----------------------------------+

1.1.1 Background

TIFF has emerged as one of the world's most popular raster fileformats. But TIFF remains limited in cartographic applications, sinceno publicly available, stable structure for conveying geographicinformation presently exists in the public domain.

Several private solutions exist for recording cartographic informationin TIFF tags. Intergraph has a mature and sophisticated geotie tagimplementation, but this remains within the private TIFF tagsetregistered exclusively to Intergraph. Other companies (such as ESRI,and Island Graphics) have geographic solutions which are alsoproprietary or limited by specific application to their software'sarchitecture.

Many GIS companies, raster data providers, and their clients haverequested that the companies concerned with delivery and exploitationof raster geographic imagery develop a publicly available, platforminteroperable standard for the support of geographic TIFF imagery. SuchTIFF imagery would originate from satellite imaging platforms, aerialplatforms, scans of aerial photography or paper maps, or as a result ofgeographic analysis. TIFF images which were supported by the public"geotie" tagset would be able to be read and positioned correctly inany GIS or digital mapping system which supports the "GeoTIFF"standard, as proposed in this document.

The savings to the users and providers of raster data and exploitation

softwares are potentially significant. With a platform interoperableGeoTIFF file, companies could stop spending excessive developmentresource in support of any and all proprietary formats which areinvented. Data providers may be able to produce off-the-shelf imageryproducts which can be delivered in the "generic" TIFF format quicklyand possibly at lower cost. End-users will have the advantage ofdeveloped software that exploits the GeoTIFF tags transparently. Mostimportantly, the same raster TIFF image which can be read and modifiedin one GIS environment may be equally exploitable in another GIS


4/95

environment without requiring any file duplication or import/exportoperation.

+----------------------------------+

1.1.2 History

The initial efforts to define a TIFF "geotie" specification began underthe leadership of Ed Grissom at Intergraph, and others in the early1990's. In 1994 a formal GeoTIFF mailing-list was created andmaintained by Niles Ritter at JPL, which quickly grew to over 140subscribers from government and industry. The purpose of the list is todiscuss common goals and interests in developing an industry-wideGeoTIFF standard, and culminated in a conference in March of 1995hosted by SPOT Image, with representatives from USGS, Intergraph, ESRI,ERDAS, SoftDesk, MapInfo, NASA/JPL, and others, in which the currentworking proposal for GeoTIFF was outlined. The outline was condensedinto a prerelease GeoTIFF specification document by Niles Ritter, andMike Ruth of SPOT Image.

Following discussions with Dr. Roger Lott of the European PetroleumSurvey Group (EPSG), the GeoTIFF projection parametrization method wasextensively modified, and brought into compatibility with both the POSCEpicentre model, and the Federal Geographic Data Committee (FGDC)metadata approaches.

+----------------------------------+

1.1.3 Scope

The GeoTIFF spec defines a set of TIFF tags provided to describe all"Cartographic" information associated with TIFF imagery that originatesfrom satellite imaging systems, scanned aerial photography, scannedmaps, digital elevation models, or as a result of geographic analyses.Its aim is to allow means for tying a raster image to a known modelspace or map projection, and for describing those projections.

GeoTIFF does not intend to become a replacement for existing geographicdata interchange standards, such as the USGS SDTS standard or the FGDCmetadata standard. Rather, it aims to augment an existing popularraster-data format to support georeferencing and geocoding information.

The tags documented in this spec are to be considered completelyorthogonal to the raster-data descriptions of the TIFF spec, and impose

no restrictions on how the standard TIFF tags are to be interpreted,which color spaces or compression types are to be used, etc.

+----------------------------------+

1.1.4 Features


5/95

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

GeoTIFF uses a small set of reserved TIFF tags to store a broad rangeof georeferencing information, catering to geographic as well asprojected coordinate systems needs. Projections include UTM, US StatePlane and National Grids, as well as the underlying projection typessuch as Transverse Mercator, Lambert Conformal Conic, etc. Noinformation is stored in private structures, IFD's or other mechanismswhich would hide information from naive TIFF reading software.

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

GeoTIFF uses numerical codes to describe projection types, coordinatesystems, datums, ellipsoids, etc. The projection, datums and ellipsoidcodes are derived from the EPSG list compiled by the PetrotechnicalOpen Software Corporation (POSC), and mechanisms for adding furtherinternational projections, datums and ellipsoids has been established.The GeoTIFF information content is designed to be compatible with thedata decomposition approach used by the National Spatial DataInfrastructure (NSDI) of the U.S. Federal Geographic Data Committee(FGDC).

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

+----------------------------------+

1.2 Revision Notes

This is the final release of GeoTIFF Revision 1.0, supporting the newEPSG 2.x codes.

Changes from 1.8.1 document: Added GCS code to required codes for"user-defined" PCS systems.

Changes from 1.8 document: minor spelling and typo corrections.

+----------------------------------+


6/95

1.2.1 Revision NomenclatureA Revision of GeoTIFF specifications will be denoted by two integersseparated by a decimal, indicating the Major and Minor revisionnumbers. GeoTIFF stores most of its information using a "Key-Code"pairing system; the Major revision number will only be incremented whena substantial addition or modification is made to the list ofinformation Keys, while the Minor Revision number permits incrementalaugmentation of the list of valid codes.

+----------------------------------+

1.2.2 New Features

Revision 1.0 New Transformation Matrix Tag.

Index Table added in Section 6.4 to assist in looking up geodesy codes.

+----------------------------------+

1.2.3 ClarificationsRevision 1.0:

o The former ModelTransformationTag (33920) conflicts with an internal Intergraph implementation and is being deprecated, in favor of a new tag (34264, registered to JPL).

o The "Origin" keys have been renamed with "Natural" or "Nat" prefixes, to distinguish from "False" origins, and to have a closer match to EPSG/POSC terminology. All Revision 0.2 names shall be recognized in a backward-compatible fashion.

o The GeoTIFF/Cartlab web page addresses have been moved out

of the author's ~ndr/ personal directory, and may now be found at:

http://www-mipl.jpl.nasa.gov/cartlab/geotiff/geotiff.html

Revision 0.2:

o South Oriented Gauss Conformal is Transverse Mercator with South pointing up, and so has been given a distinct code, rather than aliased to Transverse Mercator.

Revision 0.1:

o GeoTIFF-writers shall store the GeoKey entries in key-sorted order within the GeoKeyDirectoryTag. This is a change from preliminary

discussions which permitted arbitrary order, and more closely follows the TIFF discipline.

o The third value "ScaleZ" in ModelPixelScaleTag = (ScaleX, ScaleY, ScaleZ) shall by default be set to 0, not 1, as suggested inpreliminary discussions. This is because most standard model spaces are 2-dimensional (flat), and therefore its vertical shape is independent of the pixel-value.


7/95

o The code 32767 shall be used to imply "user-defined", rather than 16384. This avoids breaking up the reserved public GeoKey code space into two discontiguous ranges, 0-16383 and 16385-32767.

o If a GeoKey is coded "undefined", then it is exactly that; no parameters should be provided (e.g. EllipsoidSemiMajorAxis, etc). To provide parameters for a non-coded attribute, use "user-defined".

+----------------------------------+

1.2.4 Organizational changes

None.

+----------------------------------+

1.2.5 Changes in Requirements Changes to this preliminary revision:

o Support for new transformation matrix tag (34264) required.

+----------------------------------+

1.2.6 Agenda for Future Development

Revision 1.0, which is the first true "Baseline" revision, is proposedto support well-documented, public, relatively simple ProjectedCoordinate Systems (PCS), including most commonly used and supported inthe international public domains today, together with their underlyingmap-projection systems. Following the critiques of the 0.x Revisionphase, the 1.0 Revision spec is hereby released in Sept '95.

In the coming year, incremental 1.x augmentations to the "codes" listwill be established, as well as discussions regarding the future "2.0"requirements.

The Revision 2.0 phase is proposed to extend the capability of theGeoTIFF tagsets beyond PCS projections into more complex map projectiongeometries, including single-project, single-vendor, or proprietarycartographic solutions.

TBD: Sounding Datums and related parameters for Digital ElevationModels (DEM's) and bathymetry -- Revision 2?

+----------------------------------+


8/95

1.3 Administration+----------------------------------+

1.3.1 Information and Support:The most recent version of the GeoTIFF spec, EPSG/POSC tables, andsource code is available via anonymous FTP at:

ftp://mtritter.jpl.nasa.gov/pub/tiff/geotiff/

and is mirrored at the USGS:

ftp://ftpmcmc.cr.usgs.gov/release/geotiff/jpl_mirror/

There are several subdirectories called spec/ tables/ and code/.

The USGS also has an archive of prototype GeoTIFF images at:

ftp://ftpmcmc.cr.usgs.gov/release/geotiff/images/

Information and a hypertext version of the GeoTIFF spec is availablevia WWW at the following site:

http://www-mipl.jpl.nasa.gov/cartlab/geotiff/geotiff.html

A mailing-list is currently active to discuss the on-going developmentof this standard. To subscribe to this list, send e-mail to:

[email protected]

with no subject and the body of the message reading:

subscribe geotiff your-name-here

To post inquiries directly to the list, send email to:

[email protected]

+----------------------------------+

1.3.2 Private Keys and Codes:

As with TIFF, in GeoTIFF private "GeoKeys" and codes may be used,starting with 32768 and above. Unlike the TIFF spec, however, theseprivate key-spaces will not be reserved, and are only to be used forprivate, internal purposes.

+----------------------------------+


9/95

1.3.3 Proposed Revisions to GeoTIFFShould a feature arise which is not currently supported, it should beformally proposed for addition to the GeoTIFF spec, through theofficial mailing-list.

The current maintainer of the GeoTIFF specification is Niles Ritter,though this may change at a later time. Projection codes are maintainedthrough EPSG/POSC, and a mechanism for change/additions will beestablished through the GeoTIFF mailing list.

+--------------------------------------------------------------------+

2 Baseline GeoTIFF+--------------------------------------------------------------------+

+----------------------------------+

2.1 NotationThis spec follows the notation remarks of the TIFF 6.0 spec, regarding"is", "shall", "should", and "may"; the first two indicate mandatoryrequirements, "should" indicates a strong recommendation, while "may"indicates an option.

+----------------------------------+

2.2 GeoTIFF Design ConsiderationsEvery effort has been made to adhere to the philosophy of TIFF dataabstraction. The GeoTIFF tags conform to a hierarchical data structureof tags and keys, similar to the tags which have been implemented inthe "basic" and "extended" TIFF tags already supported in TIFF Version6 specification. The following are some points considered in the designof GeoTIFF:

o Private binary structures, while permitted under the TIFF spec, arein general difficult to maintain, and are intrinsically platform-dependent. Whenever possible, information should be sorted into theirintrinsic data-types, and placed into appropriately named tags. Also,implementors of TIFF readers would be more willing to honor a new tagspecification if it does not require parsing novel binary structures.

o Any Tag value which is to be used as a "keyword" switch or modifiershould be a SHORT type, rather than an ASCII string. This avoids commonmistakes of mis-spelling a keyword, as well as facilitating animplementation in code using the "switch/case" features of mostlanguages. In general, scanning ASCII strings for keywords(CaseINSensitiVE?) is a hazardous (not to mention slower and morecomplex) operation.


10/95

o True "Extensibility" strongly suggests that the Tags defined have asufficiently abstract definition so that the same tag and its valuesmay be used and interpreted in different ways as more complexinformation spaces are developed. For example, the old SubFileType tag(255) had to be obsoleted and replaced with a NewSubFileType tag,because images began appearing which could not fit into the narrowlydefined classes for that Tag. Conversely, the YCbCrSubsampling Tag hastaken on new meaning and importance as the JPEG compression standardfor TIFF becomes finalized.

+----------------------------------+

2.3 GeoTIFF Software RequirementsGeoTIFF 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 nothave sufficient accuracy with single-precision IEEE, nor with RATIONALformat storage. The only other alternative for storing high-precisionvalues 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 that4-byte integers from files created on opposite order machines will beswapped in software, and that 8-byte DOUBLE's will be 8-byte swapped.

A GeoTIFF reader/writer, in addition to supporting the standard TIFFtag types, must also have an additional module which can parse the"Geokey" MetaTag information. A public-domain software package forperforming this function is now available; see the "References" insection 5 for the location.

+----------------------------------+

2.4 GeoTIFF File and "Key" Structure

This section describes the abstract file-format and "GeoKey" datastorage mechanism used in GeoTIFF. Uses of this mechanism forimplementing georeferencing and geocoding is detailed in section 2.6and section 2.7 .

A GeoTIFF file is a TIFF 6.0 file, and inherits the file structure asdescribed in the corresponding portion of the TIFF spec. All GeoTIFFspecific information is encoded in several additional reserved TIFFtags, and contains no private Image File Directories (IFD's), binarystructures or other private information invisible to standard TIFFreaders.

The number and type of parameters that would be required to describemost popular projection types would, if implemented as separate TIFF


11/95

tags, likely require dozens or even hundred of tags, exhausting thelimited resources of the TIFF tag-space. On the other hand, a privateIFD, while providing thousands of free tags, is limited in that itstag-values are invisible to non-savvy TIFF readers (which don't knowthat the IFD_OFFSET tag value points to a private IFD).

To avoid these problems, a GeoTIFF file stores projection parameters ina set of "Keys" which are virtually identical in function to a "Tag",but has one more level of abstraction above TIFF. Effectively, it is asort of "Meta-Tag". A Key works with formatted tag-values of a TIFFfile 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 unlikeTIFF tags, all key ID's are available for use in GeoTIFF parameterdefinitions.

The Keys in GeoTIFF (also call "GeoKeys") are all referenced from theGeoKeyDirectoryTag, which defined as follows:

GeoKeyDirectoryTag: Tag = 34735 (87AF.H) Type = SHORT (2-byte unsigned short) N = variable, >= 4 Alias: ProjectionInfoTag, CoordSystemInfoTag Owner: SPOT Image, Inc.

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

The tag is an array of unsigned SHORT values, which are primarilygrouped into blocks of 4. The first 4 values are special, and contain

GeoKey directory header information. The header values consist of thefollowing information, in order:

Header={KeyDirectoryVersion, KeyRevision, MinorRevision, NumberOfKeys}

where

"KeyDirectoryVersion" indicates the current version of Key implementation, and will only change if this Tag's Key structure is changed. (Similar to the TIFFVersion (42)). The current DirectoryVersion number is 1. This value will most likely never change, and may be used to ensure that this is a valid Key-implementation.

"KeyRevision" indicates what revision of Key-Sets are used.

"MinorRevision" indicates what set of Key-codes are used. The complete revision number is denoted .

"NumberOfKeys" indicates how many Keys are defined by the rest of this Tag.


12/95

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

KeyEntry = { KeyID, TIFFTagLocation, Count, Value_Offset }

where

"KeyID" gives the key-ID value of the Key (identical in function to TIFF tag ID, but completely independent of TIFF tag-space),

"TIFFTagLocation" indicates which TIFF tag contains the value(s) of the Key: if TIFFTagLocation is 0, then the value is SHORT, and is contained in the "Value_Offset" entry. Otherwise, the type (format) of the value is implied by the TIFF-Type of the tag containing the value.

"Count" indicates the number of values in this key.

"Value_Offset" Value_Offset indicates the index- offset *into* the TagArray indicated by TIFFTagLocation, if it is nonzero. If TIFFTagLocation=0, then Value_Offset contains the actual (SHORT) value of the Key, and Count=1 is implied. Note that the offset is not a byte-offset, but rather an index based on the natural data type of the specified tag array.

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

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

GeoDoubleParamsTag: Tag = 34736 (87BO.H) Type = DOUBLE (IEEE Double precision) N = variable Owner: SPOT Image, Inc.

This tag is used to store all of the DOUBLE valued GeoKeys, referenced

by the GeoKeyDirectoryTag. The meaning of any value of this doublearray is determined from the GeoKeyDirectoryTag reference pointing toit. FLOAT values should first be converted to DOUBLE and stored here.

GeoAsciiParamsTag: Tag = 34737 (87B1.H) Type = ASCII Owner: SPOT Image, Inc. N = variable


13/95

This tag is used to store all of the ASCII valued GeoKeys, referencedby the GeoKeyDirectoryTag. Since keys use offsets into tags, anyspecial comments may be placed at the beginning of this tag. For themost 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 truethat TIFF 6.0 permits multiple NULL-delimited strings within a singleASCII tag, the secondary strings might not appear in the output ofnaive "tiffdump" programs. For this reason, the null delimiter of eachASCII Key value shall be converted to a "|" (pipe) character beforebeing installed back into the ASCII holding tag, so that a dump of thetag will look like this.

AsciiTag="first_value|second_value|etc...last_value|"

A baseline GeoTIFF-reader must check for and convert the final "|" pipecharacter of a key back into a NULL before returning it to the clientsoftware.

GeoKey Sort Order:

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

To follow the TIFF philosophy, GeoTIFF-writers shall store the GeoKeyentries in key-sorted order within the CoordSystemInfoTag.

Example:

GeoKeyDirectoryTag=( 1, 1, 2, 6, 1024, 0, 1, 2, 1026, 34737,12, 0, 2048, 0, 1, 32767, 2049, 34737,14, 12, 2050, 0, 1, 6, 2051, 34736, 1, 0 ) GeoDoubleParamsTag(34736)=(1.5) GeoAsciiParamsTag(34737)=("Custom File|My Geographic|")

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

The next line indicates that the first Key (ID=1024 =GTModelTypeGeoKey) has the value 2 (Geographic), explicitly placed inthe entry list (since TIFFTagLocation=0). The next line indicates that


14/95

the Key 1026 (the GTCitationGeoKey) is listed in the GeoAsciiParamsTag(34737) array, starting at offset 0 (the first in array), and runningfor 12 bytes and so has the value "Custom File" (the "|" is convertedto a null delimiter at the end). Going further down the list, the Key2051 (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, platformindependence, format types, etc, by specifying byte-offsets, byte-orderformat and count, while the Key describes its key values at the TIFFlevel by specifying Tag number, array-index, and count. Since all TIFFinformation occurs in TIFF arrays of some sort, we have a robust methodfor storing anything in a Key that would occur in a Tag.

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

This GeoKey mechanism will be used extensively in section 2.7, wherethe numerous parameters for defining Coordinate Systems and theirunderlying projections are defined.

+----------------------------------+

2.5 Coordinate Systems in GeoTIFFGeotiff has been designed so that standard map coordinate systemdefinitions can be readily stored in a single registered TIFF tag. Ithas also been designed to allow the description of coordinate systemdefinitions which are non-standard, and for the description oftransformations between coordinate systems, through the use of three orfour additional TIFF tags.

However, in order for the information to be correctly exchanged betweenvarious clients and providers of GeoTIFF, it is important to establisha common system for describing map projections.

In the TIFF/GeoTIFF framework, there are essentially three differentspaces upon which coordinate systems may be defined. The spaces are:

1) The raster space (Image space) R, used to reference the pixel values in an image, 2) The Device space D, and 3) The Model space, M, used to reference points on the earth.

In the sections that follow we shall discuss the relevance and use ofeach of these spaces, and their corresponding coordinate systems, fromthe standpoint of GeoTIFF.

+----------------------------------+


15/95


16/95

as point measurements at the vertices of a grid, and not in theinterior of a cell.

2.5.2.2 Raster Space

The choice of origin for raster space is not entirely arbitrary, anddepends upon the nature of the data collected. Raster space coordinatesshall be referred to by their pixel types, i.e., as "PixelIsArea" or"PixelIsPoint".

Note: For simplicity, both raster spaces documented below use a fixedpixel size and spacing of 1. Information regarding the visualrepresentation of this data, such as pixels with non-unit aspectratios, scales, orientations, etc, are best communicated with the TIFF6.0 standard tags.

+----------------------------------+

"PixelIsArea" Raster Space

The "PixelIsArea" raster grid space R, which is the default, usescoordinates I and J, with (0,0) denoting the upper-left corner of theimage, and increasing I to the right, increasing J down. The firstpixel-value fills the square grid cell with the bounds:

top-left = (0,0), bottom-right = (1,1)

and so on; by extension this one-by-one grid cell is also referred toas a pixel. An N by M pixel image covers an are with the mathematicallydefined bounds (0,0),(N,M).

(0,0) +---+---+-> I | * | * | +---+---+ Standard (PixelIsArea) TIFF Raster space R, | (1,1) (2,1) showing the areas (*) of several pixels. | J

+----------------------------------+

"PixelIsPoint" Raster Space

The PixelIsPoint raster grid space R uses the same coordinate axisnames as used in PixelIsArea Raster space, with increasing I to theright, increasing J down. The first pixel-value however, is realized asa point value located at (0,0). An N by M pixel image consists ofpoints which fill the mathematically defined bounds (0,0),(N-1,M-1).


17/95

(0,0) (1,0) *-------*------> I | | | | PixelIsPoint TIFF Raster space R, *-------* showing the location (*) of several pixels.

| (1,1) J

If a point-pixel image were to be displayed on a display device withpixel cells having the same size as the raster spacing, then the upper-left corner of the displayed image would be located in raster space at(-0.5, -0.5).

+----------------------------------+

2.5.3 Model Coordinate Systems

The following methods of describing spatial model locations (as opposedto raster) are recognized in Geotiff:

Geographic coordinatesGeocentric coordinatesProjected coordinatesVertical coordinates

Geographic, geocentric and projected coordinates are all imposed onmodels of the earth. To describe a location uniquely, a coordinate setmust be referenced to an adequately defined coordinate system. If acoordinate system is from the Geotiff standard definitions, the onlyreference required is the standard coordinate system code/name. If the

coordinate system is non-standard, it must be defined. The requireddefinitions are described below.

Projected coordinates, local grid coordinates, and (usually)geographical coordinates, form two dimensional horizontal coordinatesystems (i.e., horizontal with respect to the earth's surface). Heightis not part of these systems. To describe a position in threedimensions it is necessary to consider height as a second onedimensional vertical coordinate system.

To georeference an image in GeoTIFF, you must specify a Raster Spacecoordinate system, choose a horizontal model coordinate system, and atransformation between these two, as will be described in section 2.6

+----------------------------------+

2.5.3.1 Geographic Coordinate Systems


18/95

Geographic Coordinate Systems are those that relate angular latitudeand longitude (and optionally geodetic height) to an actual point onthe earth. The process by which this is accomplished is rather complex,and so we describe the components of the process in detail here.

+----------------------------------+

Ellipsoidal Models of the Earth

The geoid - the earth stripped of all topography - forms a referencesurface for the earth. However, because it is related to the earth'sgravity field, the geoid is a very complex surface; indeed, at adetailed level its description is not well known. The geoid istherefore not used in practical mapping.

It has been found that an oblate ellipsoid (an ellipse rotated aboutits minor axis) is a good approximation to the geoid and therefore agood model of the earth. Many approximations exist: several hundredellipsoids have been defined for scientific purposes and about 30 arein day to day use for mapping. The size and shape of these ellipsoidscan be defined through two parameters. Geotiff requires one of these tobe

the semi-major axis (a),

and the second to be either

the inverse flattening (1/f)or

the semi-minor axis (b).

Historical models exist which use a spherical approximation; suchmodels are not recommended for modern applications, but if needed thesize of a model sphere may be defined by specifying identical valuesfor the semimajor and semiminor axes; the inverse flattening cannot beused as it becomes infinite for perfect spheres.

Other ellipsoid parameters needed for mapping applications, for examplethe square of the eccentricity, can easily be calculated by anapplication from the two defining parameters. Note that Geotiff usesthe modern geodesy convention for the symbol (b) for the semi-minoraxis. No provision is made for mapping other planets in which a tri-dimensional (triaxial) ellipsoid might be required, where (b) wouldrepresent the semi-median axis and (c) the semi-minor axis.

Numeric codes for ellipsoids regularly used for earth-mapping areincluded in the Geotiff reference lists.

+----------------------------------+

Latitude and Longitude


19/95

The coordinate axes of the system referencing points on an ellipsoidare called latitude and longitude. More precisely, geodetic latitudeand longitude are required in this Geotiff standard. A discussion ofthe several other types of latitude and longitude is beyond the scopeof this document as they are not required for conventional mapping.

Latitude is defined to be the angle subtended with the ellipsoid'sequatorial plane by a perpendicular through the surface of theellipsoid from a point. Latitude is positive if north of the equator,negative if south.

Longitude is defined to be the angle measured about the minor (polar)axis of the ellipsoid from a prime meridian (see below) to the meridianthrough a point, positive if east of the prime meridian and negative ifwest. Unlike latitude which has a natural origin at the equator, thereis no feature on the ellipsoid which forms a natural origin for themeasurement of longitude. The zero longitude can be any definedmeridian. Historically, nations have used the meridian through theirnational astronomical observatories, giving rise to several primemeridians. By international convention, the meridian through Greenwich,England is the standard prime meridian. Longitude is only unambiguousif the longitude of its prime meridian relative to Greenwich is given.Prime meridians other than Greenwich which are sometimes used for earthmapping are included in the Geotiff reference lists.

+----------------------------------+

Geodetic Datums

As well as there being several ellipsoids in use to model the earth,any one particular ellipsoid can have its location and orientationrelative to the earth defined in different ways. If the relationshipbetween the ellipsoid and the earth is changed, then the geographicalcoordinates of a point will change.

Conversely, for geographical coordinates to uniquely describe alocation the relationship between the earth and the ellipsoid must bedefined. This relationship is described by a geodetic datum. An exactgeodetic definition of geodetic datums is beyond the current scope ofGeotiff. However the Geotiff standard requires that the geodetic datumbeing utilized be identified by numerical code. If required, definingparameters for the geodetic datum can be included as a citation.

+----------------------------------+

Defining Geographic Coordinate Systems

In summary, geographic coordinates are only unique if qualified by thecode of the geographic coordinate system to which they belong. A


20/95

geographic coordinate system has two axes, latitude and longitude,which are only unambiguous when both of the related prime meridian andgeodetic datum are given, and in turn the geodetic datum definitionincludes the definition of an ellipsoid. The Geotiff standard includesa list of frequently used geographic coordinate systems and theircomponent ellipsoids, geodetic datums and prime meridians. Within theGeotiff standard a geographic coordinate system can be identifiedeither by

the code of a standard geographic coordinate systemor by

a user-defined system.

The user is expected to provide geographic coordinate system code/name,geodetic datum code/name, ellipsoid code (if in standard) or ellipsoidname and two defining parameters (a) and either (1/f) or (b), and primemeridian code (if in standard) or name and longitude relative toGreenwich.

+----------------------------------+

2.5.3.2 Geocentric Coordinate Systems

A geocentric coordinate system is a 3-dimensional coordinate systemwith its origin at or near the center of the earth and with 3orthogonal axes. The Z-axis is in or parallel to the earth's axis ofrotation (or to the axis around which the rotational axis precesses).The X-axis is in or parallel to the plane of the equator and passesthrough its intersection with the Greenwich meridian, and the Y-axis isin the plane of the equator forming a right-handed coordinate systemwith the X and Z axes.

Geocentric coordinate systems are not frequently used for describinglocations, but they are often utilized as an intermediate step whentransforming between geographic coordinate systems. (Coordinate systemtransformations are described in section 2.6 below).

In the Geotiff standard, a geocentric coordinate system can beidentified, either

through the geographic code (which in turn implies a datum), or

through a user-defined name.

+----------------------------------+

2.5.3.3 Projected Coordinate Systems


21/95

Although a geographical coordinate system is mathematically twodimensional, it describes a three dimensional object and cannot berepresented on a plane surface without distortion. Map projections aretransformations of geographical coordinates to plane coordinates inwhich the characteristics of the distortions are controlled. A mapprojection consists of a coordinate system transformation method and aset of defining parameters. A projected coordinate system (PCS) is atwo dimensional (horizontal) coordinate set which, for a specific mapprojection, has a single and unambiguous transformation to a geographiccoordinate system.

In GeoTIFF PCS's are defined using the POSC/EPSG system, in which thePCS planar coordinate system, the Geographic coordinate system, and thetransformation between them, are broken down into simpler logicalcomponents. Here are schematic formulas showing how the ProjectedCoordinate Systems and Geographic Coordinates Systems are encoded:

Projected_CS = Geographic_CS + Projection Geographic_CS = Angular_Unit + Geodetic_Datum + Prime_Meridian

Projection = Linear Unit + Coord_Transf_Method + CT_Parameters Coord_Transf_Method = { TransverseMercator | LambertCC | ...} CT_Parameters = {OriginLatitude + StandardParallel+...}

(See also the Reference Parameters documentation in section 2.5.4).

Notice that "Transverse Mercator" is not referred to as a "Projection",but rather as a "Coordinate Transformation Method"; in GeoTIFF, as inEPSG/POSC, the word "Projection" is reserved for particular, well-defined systems in which both the coordinate transformation method, itsdefining parameters, and their linear units are established.

Several tens of coordinate transformation methods have been developed.Many are very similar and for practical purposes can be considered togive identical results. For example in the Geotiff standard Gauss-Kruger and Gauss-Boaga projection types are considered to be of thetype Transverse Mercator. Geotiff includes a listing of commonly usedprojection defining parameters.

Different algorithms require different defining parameters. A futureversion of Geotiff will include formulas for specific map projectionalgorithms recommended for use with listed projection parameters.

To limit the magnitude of distortions of projected coordinate systems,

the boundaries of usage are sometimes restricted. To cover moreextensive areas, two or more projected coordinate systems may berequired. In some cases many of the defining parameters of a set ofprojected coordinate systems will be held constant.

The Geotiff standard does not impose a strict hierarchy onto such zonedsystems such as US State Plane or UTM, but considers each zone to be adiscrete projected coordinate system; the ProjectedCSTypeGeoKey codevalue alone is sufficient to identify the standard coordinate systems.


22/95


23/95


24/95

Shipping List -------------

This data set consists of 8 files:

PROJCS.CSV Tabulation of Projected Coordinate Systems to which map grid coordinates may be referenced.

GEOGCS.CSV Tabulation of Geographic Coordinate Systems to which latitude and longitude coordinates may be referenced. This table includes the equivalent geocentric coordinate systems and also the geodetic datum, reference to which allows latitude and longitude or geocentric XYZ to uniquely describe a location on the earth.

VERTCS.CSV Tabulation of Vertical Coordinate Systems to which heights or depths may be referenced. This table is currently in an early form.

PROJ.CSV Tabulation of transformation methods and parameters through which Projected Coordinate Systems are defined and related to Geographic Coordinate Systems.

ELLIPS.CSV Tabulation of reference ellipsoids upon which geodetic datums are based.

PMERID.CSV Tabulation of prime meridians upon which geodetic datums are based.

UNITS.CSV Tabulation of length units used in Projected and Vertical Coordinate Systems and angle units used in Geographic Coordinate Systems.

README.TXT This file.

+---------------------------------------------------------------------+

2.6 Coordinate TransformationsThe purpose of Geotiff is to allow the definitive identification ofgeoreferenced locations within a raster dataset. This is generallyaccomplished through tying raster space coordinates to a model spacecoordinate system, when no further information is required. In theGeoTIFF nomenclature, "georeferencing" refers to tying raster space toa model space M, while "geocoding" refers to defining how the modelspace M assigns coordinates to points on the earth.

The three tags defined below may be used for defining the relationshipbetween R and M, and the relationship may be diagrammed as:


25/95


26/95

If possible, the first tiepoint placed in this tag shall be the oneestablishing the location of the point (0,0) in raster space. However,if this is not possible (for example, if (0,0) is goes to a part ofmodel space in which the projection is ill-defined), then there is noparticular order in which the tiepoints need be listed.

For orthorectification or mosaicking applications a large number oftiepoints may be specified on a mesh over the raster image. However,the definition of associated grid interpolation methods is not in thescope of the current GeoTIFF spec.

Remark: As mentioned in section 2.5.1, all GeoTIFF information isindependent of the XPosition, YPosition, and Orientation tags of thestandard TIFF 6.0 spec.

The next two tags are optional tags provided for defining exact affinetransformations between raster and model space; baseline GeoTIFF filesmay use either, but shall never use both within the same TIFF imagedirectory.

ModelPixelScaleTag: Tag = 33550 Type = DOUBLE (IEEE Double precision) N = 3 Owner: SoftDesk

This tag may be used to specify the size of raster pixel spacing in themodel space units, when the raster space can be embedded in the modelspace coordinate system without rotation, and consists of the following3 values:

ModelPixelScaleTag = (ScaleX, ScaleY, ScaleZ)

where ScaleX and ScaleY give the horizontal and vertical spacing ofraster pixels. The ScaleZ is primarily used to map the pixel value of adigital elevation model into the correct Z-scale, and so for most otherpurposes this value should be zero (since most model spaces are 2-D,with Z=0).

A single tiepoint in the ModelTiepointTag, together with this tag,completely determine the relationship between raster and model space;thus they comprise the two tags which Baseline GeoTIFF files most oftenwill use to place a raster image into a "standard position" in modelspace.

Like the Tiepoint tag, this tag information is independent of theXPosition, YPosition, Resolution and Orientation tags of the standardTIFF 6.0 spec. However, simple reversals of orientation between raster


27/95

and model space (e.g. horizontal or vertical flips) may be indicated byreversal of sign in the corresponding component of theModelPixelScaleTag. GeoTIFF compliant readers must honor this sign-reversal convention.

This tag must not be used if the raster image requires rotation orshearing to place it into the standard model space. In such cases thetransformation shall be defined with the more generalModelTransformationTag, defined below.

ModelTransformationTag Tag = 34264 (85D8.H) Type = DOUBLE N = 16 Owner: JPL Cartographic Applications Group

This tag may be used to specify the transformation matrix between theraster space (and its dependent pixel-value space) and the (possibly

3D) model space. If specified, the tag shall have the followingorganization:

ModelTransformationTag = (a,b,c,d,e....m,n,o,p).

where

model image coords = matrix * coords

|- -| |- -| |- -|

| X | | a b c d | | I | | | | | | | | Y | | e f g h | | J | | | = | | | | | Z | | i j k l | | K | | | | | | | | 1 | | m n o p | | 1 | |- -| |- -| |- -|

By convention, and without loss of generality, the following parametersare currently hard-coded and will always be the same (but must bespecified nonetheless):

m = n = o = 0, p = 1.

For Baseline GeoTIFF, the model space is always 2-D, and so the matrixwill have the more limited form:

|- -| |- -| |- -|


28/95

| X | | a b 0 d | | I | | | | | | | | Y | | e f 0 h | | J | | | = | | | | | Z | | 0 0 0 0 | | K | | | | | | | | 1 | | 0 0 0 1 | | 1 | |- -| |- -| |- -|

Values "d" and "h" will often be used to represent translations in Xand Y, and so will not necessarily be zero. All 16 values should bespecified, in all cases. Only the raster-to-model transformation isdefined; if the inverse transformation is required it must be computedby the client, to the desired accuracy.

This matrix tag should not be used if the ModelTiepointTag and theModelPixelScaleTag are already defined. If only a single tiepoint(I,J,K,X,Y,Z) is specified, and the ModelPixelScale = (Sx, Sy, Sz) isspecified, then the corresponding transformation matrix may be computedfrom them as:

|- -| | Sx 0.0 0.0 Tx | | | Tx = X - I/Sx | 0.0 -Sy 0.0 Ty | Ty = Y + J/Sy | | Tz = Z - K/Sz (if not 0) | 0.0 0.0 Sz Tz | | | | 0.0 0.0 0.0 1.0 | |- -|

where the -Sy is due the reversal of direction from J increasing- downin raster space to Y increasing-up in model space.

Like the Tiepoint tag, this tag information is independent of theXPosition, YPosition, and Orientation tags of the standard TIFF 6.0spec.

Note: In Revision 0.2 and earlier, another tag was used for thismatrix, which has been renamed as follows:

IntergraphMatrixTag Tag = 33920 (8480.H)

Type = DOUBLE N = 17 (Intergraph implementation) or 16 (GeoTIFF 0.2 impl.) Owner: Intergraph

This tag conflicts with an internal software implementation atIntergraph, and so its use is no longer encouraged. A GeoTIFF readershould look first for the new tag, and only if it is not found shouldit check for this older tag. If found, it should only consider it to becontain valid GeoTIFF matrix information if the tag-count is 16; theIntergraph version uses 17 values.


29/95


30/95

24 Chemin de la Marie, Harefield Road, 1258 Perly-Geneva, Uxbridge, Switzerland. Middlesex UB8 1PD, England.

Internet: [email protected]

Requests for the inclusion of new data should include supporting documentation. Requests for changing existing data should include reference to both the name and code of the item.

+----------------------------------+

2.6.3 Cookbook for Defining Transformations

Here is a 4-step guide to producing a set of Baseline GeoTIFF tags fordefining coordinate transformation information of a raster dataset.

Step 1: Establish the Raster Space coordinate system used: RasterPixelIsArea or RasterPixelIsPoint.

Step 2: Establish/define the model space Type in which the image is to be georeferenced. Usually this will be a Projected Coordinate system (PCS). If you are geocoding this data set, then the model space is defined to be the corresponding geographic, geocentric or Projected coordinate system (skip to the "Cookbook" section 2.7.3 first to do determine this).

Step 3: Identify the nature of the transformations needed to tie the raster data down to the model space coordinate system:

Case 1: The model-location of a raster point (x,y) is known, but not the scale or orientations:

Use the ModelTiepointTag to define the (X,Y,Z) coordinates of the known raster point.

Case 2: The location of three non-collinear raster points are known exactly, but the linearity of the transformation is not known.

Use the ModelTiepointTag to define the (X,Y,Z) coordinates of all three known raster points. Do not compute or define the ModelPixelScale or ModelTransformation tag.

Case 3: The position and scale of the data is known exactly, and no rotation or shearing is needed to fit into the model space.

Use the ModelTiepointTag to define the (X,Y,Z) coordinates of the known raster point, and the ModelPixelScaleTag to specify the scale.

Case 4: The raster data requires rotation and/or lateral shearing to fit into the defined model space:


31/95

Use the ModelTransformation matrix to define the transformation.

Case 5: The raster data cannot be fit into the model space with a simple affine transformation (rubber-sheeting required).

Use only the ModelTiepoint tag, and specify as many tiepoints as your application requires. Note, however, that this is not a Baseline GeoTIFF implementation, and should not be used for interchange; it is recommended that the image be geometrically rectified first, and put into a standard projected coordinate system.

Step 4: Install the defined tag values in the TIFF file and close it.

+----------------------------------+

2.7 Geocoding Raster Data+----------------------------------+

2.7.1 General ApproachA geocoded image is a georeferenced image as described in section 2.6,which also specifies a model space coordinate system (CS) between themodel space M (to which the raster space has been tied) and the earth.The relationship can be diagrammed, including the associated TIFF tags,as follows:

ModelPixelScaleTag ModelTiepointTag GeoKeyDirectoryTag CS R -------- OR ---------------> M --------- AND -----------> Earth ModelTransformationTag GeoDoubleParamsTag GeoAsciiParamsTag

The geocoding coordinate system is defined by the GeoKeyDirectoryTag,while the Georeferencing information (T) is defined by theModelTiepointTag and the ModelPixelScale, or ModelTransformationTag.Since these two systems are independent of each other, the tags used tostore the parameters are separated from each other in the GeoTIFF fileto emphasize the orthogonality.

+----------------------------------+

2.7.2 GeoTIFF GeoKeys for GeocodingAs mentioned above, all information regarding the Model Coordinate

System used in the raster data is referenced from theGeoKeyDirectoryTag, which stores all of the GeoKey entries. In theAppendix, section 6.2 summarizes all of the GeoKeys defined forbaseline GeoTIFF, and their corresponding codes are documented insection 6.3. Only the Keys themselves are documented here.

+----------------------------------+


32/95

Common Features+----------------------------------+

Public and Private Key and Code Ranges

GeoTIFF GeoKey ID's may take any value between 0 and 65535. FollowingTIFF general approach, the GeoKey ID's from 32768 and above areavailable for private implementations. However, no registry will beestablished for these keys or codes, so developers are warned to usethem at their own risk.

The Key ID's from 0 to 32767 are reserved for use by the officialGeoTIFF spec, and are broken down into the following sub-domains:

[ 0, 1023] Reserved [ 1024, 2047] GeoTIFF Configuration Keys [ 2048, 3071] Geographic/Geocentric CS Parameter Keys [ 3072, 4095] Projected CS Parameter Keys [ 4096, 5119] Vertical CS Parameter Keys [ 5120, 32767] Reserved [32768, 65535] Private use

GeoKey codes, like keys and tags, also range from 0 to 65535. Followingthe TIFF approach, all codes from 32768 and above are available forprivate user implementation. There will be no registry for these codes,however, and so developers must be sure that these tags will only beused internally. Use private codes at your own risk.

The codes from 0 to 32767 for all public GeoKeys are reserved by thisGeoTIFF specification.

Common Public Code Values

For consistency, several key codes have the same meaning in allimplemented GeoKeys possessing a SHORT numerical coding system:

0 = undefined 32767 = user-defined

The "undefined" code means that this parameter is intentionallyomitted, for whatever reason. For example, the datum used for a givenmap may be unknown, or the accuracy of a aerial photo is so low that tospecify a particular datum would imply a higher accuracy than is in thedata.


33/95


34/95

This establishes the Raster Space coordinate system used; there arecurrently only two, namely RasterPixelIsPoint and RasterPixelIsArea. Nouser-defined raster spaces are currently supported. For variance inimaging display parameters, such as pixel aspect-ratios, use thestandard TIFF 6.0 device-space tags instead.

+---------------------------------------------------------------------+

GTCitationGeoKeyKey ID = 1026Type = ASCII

As with all the "Citation" GeoKeys, this is provided to give an ASCIIreference to published documentation on the overall configuration ofthis GeoTIFF file.

+---------------------------------------------------------------------++----------------------------------+

Geographic CS Parameter GeoKeys+----------------------------------+

+---------------------------------------------------------------------+

In general, the geographic coordinate system used will be implied bythe projected coordinate system code. If however, this is a user-defined PCS, or the ModelType was chosen to be Geographic, then thesystem must be explicitly defined here, using the Horizontal datumcode.

+---------------------------------------------------------------------+

GeographicTypeGeoKeyKey ID = 2048Type = SHORT (code)Values = Section 6.3.2.1 Codes

This key may be used to specify the code for the geographic coordinatesystem used to map lat-long to a specific ellipsoid over the earth.

GeoKey Requirements for User-Defined geographic CS:

GeogCitationGeoKey GeogGeodeticDatumGeoKey

GeogAngularUnitsGeoKey (if not degrees)GeogPrimeMeridianGeoKey (if not Greenwich)

+---------------------------------------------------------------------+

GeogCitationGeoKeyKey ID = 2049Type = ASCIIValues = text


35/95


36/95

Allows the definition of user-defined linear geocentric units, asmeasured in meters.

+---------------------------------------------------------------------+

GeogAngularUnitsGeoKeyKey ID = 2054Type = SHORT (code)Values = Section 6.3.1.4 Codes

Allows the definition of geocentric CS Linear units for user-definedGCS and for ellipsoids.

GeoKey Requirements for "user-defined" units: GeogCitationGeoKey GeogAngularUnitSizeGeoKey+---------------------------------------------------------------------+

GeogAngularUnitSizeGeoKeyKey ID = 2055Type = DOUBLEUnits: radians

Allows the definition of user-defined angular geographic units, asmeasured in radians.

+---------------------------------------------------------------------+

GeogEllipsoidGeoKeyKey ID = 2056Type = SHORT (code)Values = Section 6.3.2.3 Codes

This key may be used to specify the coded ellipsoid used in thegeodetic datum of the Geographic Coordinate System.

GeoKey Requirements for User-Defined Ellipsoid:

GeogCitationGeoKey [GeogSemiMajorAxisGeoKey, [GeogSemiMinorAxisGeoKey | GeogInvFlatteningGeoKey] ]

+---------------------------------------------------------------------+

GeogSemiMajorAxisGeoKey

Key ID = 2057Type = DOUBLEUnits: Geocentric CS Linear Units

Allows the specification of user-defined Ellipsoid Semi-Major Axis (a).

+---------------------------------------------------------------------+


37/95

GeogSemiMinorAxisGeoKeyKey ID = 2058Type = DOUBLEUnits: Geocentric CS Linear Units

Allows the specification of user-defined Ellipsoid Semi-Minor Axis (b).

+---------------------------------------------------------------------+

GeogInvFlatteningGeoKeyKey ID = 2059Type = DOUBLEUnits: none.

Allows the specification of the inverse of user-defined Ellipsoid'sflattening parameter (f). The eccentricity-squared e^2 of the ellipsoidis related to the non-inverted f by:

e^2 = 2*f - f^2

Note: if the ellipsoid is spherical the inverse-flattening becomes infinite; use the GeogSemiMinorAxisGeoKey instead, and set it equal to the semi-major axis length.

+---------------------------------------------------------------------+

GeogAzimuthUnitsGeoKeyKey ID = 2060Type = SHORT (code)Values = Section 6.3.1.4 Codes

This key may be used to specify the angular units of measurement usedto defining azimuths, in geographic coordinate systems. These may beused for defining azimuthal parameters for some projection algorithms,and may not necessarily be the same angular units used for lat-long.

+---------------------------------------------------------------------+

+----------------------------------+

Projected CS Parameter GeoKeys

+----------------------------------+

The PCS range of GeoKeys includes the projection and coordinatetransformation keys as well. The projection keys are included in thisblock since they can only be used to define projected coordinatesystems.

+---------------------------------------------------------------------+


38/95

ProjectedCSTypeGeoKeyKey ID = 3072Type = SHORT (codes)Values: Section 6.3.3.1 codes

This code is provided to specify the projected coordinate system.

GeoKey requirements for "user-defined" PCS families: PCSCitationGeoKey ProjectionGeoKey GeographicTypeGeoKey

+---------------------------------------------------------------------+

PCSCitationGeoKeyKey ID = 3073Type = ASCII

As with all the "Citation" GeoKeys, this is provided to give an ASCIIreference to published documentation on the Projected CoordinateSystem particularly if this is a "user-defined" PCS.

+---------------------------------------------------------------------+

+----------------------------------+

Projection Definition GeoKeys+----------------------------------+

+---------------------------------------------------------------------+

With the exception of the first two keys, these are mostly projection-specific parameters, and only a few will be required for any particularprojection type. Projected coordinate systems automatically imply aspecific projection type, as well as specific parameters for thatprojection, and so the keys below will only be necessary for user-defined projected coordinate systems.

+---------------------------------------------------------------------+

ProjectionGeoKeyKey ID = 3074Type = SHORT (code)Values: Section 6.3.3.2 codes

Allows specification of the coordinate transformation method andprojection zone parameters. Note : when associated with an appropriateGeographic Coordinate System, this forms a Projected Coordinate System.

GeoKeys Required for "user-defined" Projections:


39/95

PCSCitationGeoKey ProjCoordTransGeoKey ProjLinearUnitsGeoKey (additional parameters depending on ProjCoordTransGeoKey).

+---------------------------------------------------------------------+

ProjCoordTransGeoKeyKey ID = 3075Type = SHORT (code)Values: Section 6.3.3.3 codes

Allows specification of the coordinate transformation method used.Note: this does not include the definition of the correspondingGeographic Coordinate System to which the projected CS is related; onlythe transformation method is defined here.

GeoKeys Required for "user-defined" Coordinate Transformations:

PCSCitationGeoKey


40/95

Type = DOUBLEUnits: GeogAngularUnit

Latitude of second Standard Parallel.

+---------------------------------------------------------------------+

ProjNatOriginLongGeoKeyKey ID = 3080Type = DOUBLEUnits: GeogAngularUnitAlias: ProjOriginLongGeoKey

Longitude of map-projection Natural origin.

+---------------------------------------------------------------------+

ProjNatOriginLatGeoKeyKey ID = 3081Type = DOUBLEUnits: GeogAngularUnitAlias: ProjOriginLatGeoKey

Latitude of map-projection Natural origin.

+---------------------------------------------------------------------+

ProjFalseEastingGeoKeyKey ID = 3082Type = DOUBLEUnits: ProjLinearUnit

Gives the easting coordinate of the map projection Natural origin.

+---------------------------------------------------------------------+

ProjFalseNorthingGeoKeyKey ID = 3083Type = DOUBLEUnits: ProjLinearUnit

Gives the northing coordinate of the map projection Natural origin.

+---------------------------------------------------------------------+

ProjFalseOriginLongGeoKeyKey ID = 3084Type = DOUBLEUnits: GeogAngularUnit

Gives the longitude of the False origin.

+---------------------------------------------------------------------+

ProjFalseOriginLatGeoKeyKey ID = 3085


41/95

Type = DOUBLEUnits: GeogAngularUnit

Gives the latitude of the False origin.

+---------------------------------------------------------------------+

ProjFalseOriginEastingGeoKeyKey ID = 3086Type = DOUBLEUnits: ProjLinearUnit

Gives the easting coordinate of the false origin. This is NOT the FalseEasting, which is the easting attached to the Natural origin.

+---------------------------------------------------------------------+

ProjFalseOriginNorthingGeoKeyKey ID = 3087

Type = DOUBLEUnits: ProjLinearUnit

Gives the northing coordinate of the False origin. This is NOT theFalse Northing, which is the northing attached to the Natural origin.

+---------------------------------------------------------------------+

ProjCenterLongGeoKeyKey ID = 3088Type = DOUBLEUnits: GeogAngularUnit

Longitude of Center of Projection. Note that this is not necessarilythe origin of the projection.

+---------------------------------------------------------------------+

ProjCenterLatGeoKeyKey ID = 3089Type = DOUBLEUnits: GeogAngularUnit

Latitude of Center of Projection. Note that this is not necessarily theorigin of the projection.

+---------------------------------------------------------------------+

ProjCenterEastingGeoKeyKey ID = 3090Type = DOUBLEUnits: ProjLinearUnit

Gives the easting coordinate of the center. This is NOT the FalseEasting.

+---------------------------------------------------------------------+


42/95

ProjFalseOriginNorthingGeoKeyKey ID = 3091Type = DOUBLEUnits: ProjLinearUnit

Gives the northing coordinate of the center. This is NOT the FalseNorthing.

+---------------------------------------------------------------------+

ProjScaleAtNatOriginGeoKeyKey ID = 3092Type = DOUBLEUnits: noneAlias: ProjScaleAtOriginGeoKey (Rev. 0.2)

Scale at Natural Origin. This is a ratio, so no units are required.

+---------------------------------------------------------------------+

ProjScaleAtCenterGeoKeyKey ID = 3093Type = DOUBLEUnits: none

Scale at Center. This is a ratio, so no units are required.

+---------------------------------------------------------------------+

ProjAzimuthAngleGeoKeyKey ID = 3094Type = DOUBLEUnits: GeogAzimuthUnit

Azimuth angle east of true north of the central line passing throughthe projection center (for elliptical (Hotine) Oblique Mercator). Notethat this is the standard method of measuring azimuth, but is oppositethe usual mathematical convention of positive indicating counter-clockwise.

+---------------------------------------------------------------------+

ProjStraightVertPoleLongGeoKeyKey ID = 3095Type = DOUBLEUnits: GeogAngularUnit

Longitude at Straight Vertical Pole. For polar stereographic.

+---------------------------------------------------------------------+

GeogAzimuthUnitsGeoKeyKey ID = 2060Type = SHORT (code)Values = Section 6.3.1.4 Codes


43/95

This key is actually part of the "Geographic CS Parameter Keys"section, but is mentioned here as it is useful for defining units usedin the azimuthal projection parameters.

+---------------------------------------------------------------------+

+----------------------------------+

Vertical CS Parameter Keys+----------------------------------+

Note: Vertical coordinate systems are not yet implemented. Thesesections are provided for future development, and any verticalcoordinate systems in the current revision must be defined using theVerticalCitationGeoKey.

+---------------------------------------------------------------------+

VerticalCSTypeGeoKeyKey ID = 4096Type = SHORT (code)Values = Section 6.3.4.1 Codes

This key may be used to specify the vertical coordinate system.

+---------------------------------------------------------------------+

VerticalCitationGeoKeyKey ID = 4097Type = ASCIIValues = text

This key may be used to document the vertical coordinate system used,and its parameters.

+---------------------------------------------------------------------+

VerticalDatumGeoKeyKey ID = 4098Type = SHORT (code)Values = Section 6.3.4.2 codes

This key may be used to specify the vertical datum for the verticalcoordinate system.

+---------------------------------------------------------------------+

VerticalUnitsGeoKeyKey ID = 4099Type = SHORT (code)Values = Section 6.3.1.3 Codes

This key may be used to specify the vertical units of measurement usedin the geographic coordinate system, in cases where geographic CS's


44/95

need to reference the vertical coordinate. This, together with theCitation key, comprise the only fully implemented keys in this section,at present.

+----------------------------------+

2.7.3 Cookbook for Geocoding Data

Step 1: Determine the Coordinate system type of the raster data, based on the nature of the data: pixels derived from scanners or other optical devices represent areas, and most commonly will use the RasterPixelIsArea coordinate system. Pixel data such as digital elevation models represent points, and will probably use RasterPixelIsPoint coordinates.

Store in: GTRasterTypeGeoKey

Step 2: Determine which class of model space coordinates are most natural for this dataset:Geographic, Geocentric, or Projected Coordinate System. Usually this will be PCS.

Store in: GTModelTypeGeoKey

Step 3: This step depends on the GTModelType:

case PCS: Determine the PCS projection system. Most of the PCS's used in standard State Plane and national grid systems are defined, so check this list first; the EPSG index in section 6.4 may be useful for this purpose.

Store in: ProjectedCSTypeGeoKey, ProjectedCSTypeGeoKey

If coded, it will not be necessary to specify the Projection datum, etc for this case, since all of those parameters are determined by the ProjectedCSTypeGeoKey code. Skip to step 4 from here.

If none of the coded PCS's match your system, then this is a user-defined PCS. Use the Projection code list to check for standard projection systems.

Store in: ProjectionGeoKey and skip to Geographic CS case.

If none of the Projection codes match your system, then this is a user-defined projection. Use the ProjCoordTransGeoKey to specify the coordinate transformation method (e.g. Transverse Mercator), and all of the associated parameters of that method. Also define the linear units used in the planar coordinate system.

Store in: ProjCoordTransGeoKey, ProjLinearUnitsGeoKey


45/95

Now continue on to define the Geographic CS, below.

case GEOCENTRIC: case GEOGRAPHIC: Check the list of standard GCS's and use the corresponding code. To use a code both the Datum, Prime Meridian, and angular units must match those of the code.

Store in: GeographicTypeGeoKey and skip to Step 4.

If none of the coded GCS's match exactly, then this is a user-defined GCS. Check the list of standard datums, Prime Meridians, and angular units to define your system.

Store in: GeogGeodeticDatumGeoKey, GeogAngularUnitsGeoKey, GeogPrimeMeridianGeoKey and skip to Step 4.

If none of the datums match your system, you have a user-defined datum, which is an odd system, indeed. Use the GeogEllipsoidGeoKey to select the appropriate ellipsoid or use the GeogSemiMajorAxisGeoKey, GeogInvFlatteningGeoKey to define, and give a reference using the GeogCitationGeoKey.

Store in: GeogEllipsoidGeoKey, etc. and go to Step 4.

Step 4: Install the GeoKeys/codes into the GeoKeyDirectoryTag, and the DOUBLE and ASCII key values into the corresponding value-tags.

Step 5: Having completely defined the Raster & Model coordinate system, go to Cookbook section 2.6.2 and use the Georeferencing Tags to tie the raster image down onto the Model space.

+----------------------------------+

3 Examples+----------------------------------+

Here are some examples of how GeoTIFF may be implemented at the Tagand GeoKey level, following the general "Cookbook" approach above.

+----------------------------------+

3.1 Common Examples

+----------------------------------+

3.1.1. UTM Projected Aerial Photo

We have an aerial photo which has been orthorectified and resampled toa UTM grid, zone 60, using WGS84 datum; the coordinates of the upper-left corner of the image is are given in easting/northing, as


46/95

350807.4m, 5316081.3m. The scanned map pixel scale is 100 meters/pixels(the actual dpi scanning ratio is irrelevant).

ModelTiepointTag = (0, 0, 0, 350807.4, 5316081.3, 0.0) ModelPixelScaleTag = (100.0, 100.0, 0.0) GeoKeyDirectoryTag:

GTModelTypeGeoKey = 1 (ModelTypeProjected) GTRasterTypeGeoKey = 1 (RasterPixelIsArea) ProjectedCSTypeGeoKey = 32660 (PCS_WGS84_UTM_zone_60N) PCSCitationGeoKey = "UTM Zone 60 N with WGS84"

Notes:

1) We did not need to specify the GCS lat-long, since the PCS_WGS84_UTM_zone_60N codes implies particular GCS and units already (WGS_84 and meters). The citation was added just for documentation.

2) The "GeoKeyDirectoryTag" is expressed using the "GeoKey"

structure defined above. At the TIFF level the tags look like this:

GeoKeyDirectoryTag=( 1, 0, 2, 4, 1024, 0, 1, 1, 1025, 0, 1, 1, 3072, 0, 1, 32660, 3073, 34737, 25, 0 ) GeoAsciiParamsTag(34737)=("UTM Zone 60 N with WGS84|")

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.

+----------------------------------+

3.1.2. Standard State Plane

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 systemeasting/northing of (949465.0, 3070309.1).

ModelTiepointTag = ( 50, 100, 0, 949465.0, 3070309.1, 0)

ModelPixelScaleTag = (1000, 1000, 0) GeoKeyDirectoryTag: GTModelTypeGeoKey = 1 (ModelTypeProjected) GTRasterTypeGeoKey = 1 (RasterPixelIsArea) ProjectedCSTypeGeoKey = 32139 (PCS_NAD83_Texas_Central)

Notice that in this case, since the PCS is a standard code, we do not need to define the GCS, datum, etc, since those are implied by the PCS code. Also, since this is NAD83, meters are used rather than US Survey feet (as in NAD 27).


47/95

+----------------------------------+

3.1.3. Lambert Conformal Conic Aeronautical Chart

We have a 500 x 500 scanned aeronautical chart of Seattle, WA, usingLambert Conformal Conic projection, correctly oriented. The centralmeridian is at 120 degrees west. The map resolution is 1000meters/pixel, at origin, and uses NAD27 datum. The standard parallelsof the projection are at 41d20m N and 48d40m N. The latitude of theorigin is at 45 degrees North, and occurs in the image at the rastercoordinates (80,100). The origin is given a false easting and northingof 200000m, 1500000m.

ModelTiepointTag = ( 80, 100, 0, 200000, 1500000, 0)

ModelPixelScaleTag = (1000, 1000, 0) GeoKeyDirectoryTag: GTModelTypeGeoKey = 1 (ModelTypeProjected) GTRasterTypeGeoKey = 1 (RasterPixelIsArea) GeographicTypeGeoKey = 4267 (GCS_NAD27) ProjectedCSTypeGeoKey = 32767 (user-defined) ProjectionGeoKey = 32767 (user-defined) ProjLinearUnitsGeoKey = 9001 (Linear_Meter) ProjCoordTransGeoKey = 8(CT_LambertConfConic_2SP) ProjStdParallel1GeoKey = 41.333 ProjStdParallel2GeoKey = 48.666 ProjCenterLongGeoKey =-120.0 ProjNatOriginLatGeoKey = 45.0 ProjFalseEastingGeoKey, = 200000.0 ProjFalseNorthingGeoKey, = 1500000.0

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

+--------------------------------------------------------------------+

3.1.4. DMA ADRG Raster Graphic Map

The U.S. Defense Mapping Agency produces ARC digitized raster graphicsdatasets by scanning maps and geometrically resampling them into anequirectangular projection, so that they may be directly indexed withWGS84 geographic coordinates. The scale for one map is 0.2 degrees perpixel horizontally, 0.1 degrees per pixel vertically. If stored in aGeoTIFF file it contains the following information:

ModelTiepointTag=(0.0, 0.0, 0.0, -120.0, 32.0, 0.0)


48/95

ModelPixelScale = (0.2, 0.1, 0.0) GeoKeyDirectoryTag: GTModelTypeGeoKey = 2 (ModelTypeGeographic) GTRasterTypeGeoKey = 1 (RasterPixelIsArea) GeographicTypeGeoKey = 4326 (GCS_WGS_84)

+----------------------------------+

3.2 Less Common Examples

+----------------------------------+

3.2.1. Unrectified Aerial photo, known tiepoints, in degrees.

We have an aerial photo, and know only the WGS84 GPS location ofseveral points in the scene: the upper left corner is 120 degrees West,32 degrees North, the lower-left corner is at 120 degrees West, 30degrees 20 minutes North, and the lower-right hand corner of the imageis at 116 degrees 40 minutes West, 30 degrees 20 minutes North. Thephoto is not geometrically corrected, however, and the completeprojection is therefore not known.

ModelTiepointTag=( 0.0, 0.0, 0.0, -120.0, 32.0, 0.0, 0.0, 1000.0, 0.0, -120.0, 30.33333, 0.0, 1000.0, 1000.0, 0.0, -116.6666667, 30.33333, 0.0) GeoKeyDirectoryTag: GTModelTypeGeoKey = 1 (ModelTypeGeographic) GTRasterTypeGeoKey = 1 (RasterPixelIsArea) GeographicTypeGeoKey = 4326 (GCS_WGS_84)

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 know to be exact are the ones specified in the tiepoint tag.

+----------------------------------+

3.2.2. Rotated Scanned Map

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

ModelTransformationTag = ( 0, 100.0, 0, 400000.0, 100.0, 0, 0, 500000.0, 0, 0, 0, 0, 0, 0, 0, 1)


49/95

GeoKeyDirectoryTag: GTModelTypeGeoKey = 1 ( ModelTypeProjected) GTRasterTypeGeoKey = 1 (RasterPixelIsArea) ProjectedCSTypeGeoKey = 27700 (PCS_British_National_Grid) PCSCitationGeoKey = "British National Grid, Zone NZ"

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

+----------------------------------+

3.2.3. Digital Elevation ModelThe DMA stores digital elevation models using an equirectangularprojection, so that it may be indexed with WGS84 geographiccoordinates. Since elevation postings are point-values, the pixelsshould not be considered as filling areas, but as point-values at gridvertices. To accommodate the base elevation of the Angeles Crestforest, the pixel value of 0 corresponds to an elevation of 1000 meters

relative to WGS84 reference ellipsoid. The upper left corner is at 120degrees West, 32 degrees North, and has a pixel scale of 0.2degrees/pixel longitude, 0.1 degrees/pixel latitude.

ModelTiepointTag=(0.0, 0.0, 0.0, -120.0, 32.0, 1000.0) ModelPixelScale = (0.2, 0.1, 1.0) GeoKeyDirectoryTag: GTModelTypeGeoKey = 2 (ModelTypeGeographic) GTRasterTypeGeoKey = 2 (RasterPixelIsPoint) GeographicTypeGeoKey = 4326 (GCS_WGS_84) VerticalCSTypeGeoKey = 5030 (VertCS_WGS_84_ellipsoid) VerticalCitationGeoKey = "WGS 84 Ellipsoid" VerticalUnitsGeoKey = 9001 (Linear_Meter)

Remarks: 1) Note the "RasterPixelIsPoint" raster space, indicating that the DEM posting of the first pixel is at the raster point (0,0,0), and therefore corresponds to 120W,32N exactly. 2) The third value of the "PixelScale" is 1.0 to indicate that a single pixel-value unit corresponds to 1 meter, and the last tiepoint value indicates that base value zero indicates 1000m above the reference surface.

+----------------------------------+

4 Extended GeoTIFF+--------------------------------------------------------------------+

This section is for future development TBD.

Possible additional GeoKeys for Revision 2.0:

PerspectHeightGeoKey (General Vertical Nearsided Perspective)


50/95

SOMInclinAngleGeoKey (SOM) SOMAscendLongGeoKey (SOM) SOMRevPeriodGeoKey (SOM) SOMEndOfPathGeoKey (SOM) ? is this needed ? SHORT SOMRatioGeoKey (SOM) SOMPathNumGeoKey (SOM) SHORT SOMSatelliteNumGeoKey (SOM) SHORT OEAShapeMGeoKey (Oblated Equal Area) OEAShapeNGeoKey (Oblated Equal Area) OEARotationAngleGeoKey (Oblated Equal Area)

Other items for consideration:

o Digital Elevation Model information, such as Vertical Datums, SoundingDatums.

o Accuracy Keys for linear, circular, and spherical errors, etc.

o Source information, such as details of an original coordinate system and of transformations between it and the coordinate system in which

data is being exchanged.

+--------------------------------------------------------------------+

5 References+--------------------------------------------------------------------+

1. EPSG/POSC Projection Coding System Tables. Available via FTP to:

ftp://mtritter.jpl.nasa.gov/pub/tiff/geotiff/tables

or its USGS mirror site:

ftp://ftpmcmc.cr.usgs.gov/release/geotiff/jpl-mirror/tables

2. TIFF Revision 6.0 Specification: A PDF formatted version is available via FTP to:

ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PDFfiles/TIFF6.pdf

PostScript formatted text versions available at:.

ftp://sgi.com/graphics/ti ff/TIFF6.ps.Z (compressed)

ftp://sgi.com/graphics/ti ff/TIFF6.ps (uncompressed)

3. LIBGEOTIFF -- Public Domain GeoTIFF library, available via anonymous FTP to:

ftp://mtritter.jpl.nasa.gov/pub/tiff/geotiff/code

or its USGS mirror site:

ftp://ftpmcmc.cr.usgs.gov/release/geotiff/jpl-mirror/code


51/95

4. LIBTIFF -- Public Domain TIFF library, available via anonymous FTP to:

ftp://sgi.com/graphics/tiff/

5. Spatial Data Transfer Standard (SDTS) of the USGS. (Federal Information Processing Standard (FIPS) 173):

ftp://sdts.er.usgs.gov/pub/sdts/

SDTS Task Force U.S. Geological Survey 526 National Center Reston, VA 22092

E-mail: [email protected]

6. Map use: reading, analysis, interpretation. Muehrcke, Phillip C. 1986. Madison, WI: JP Publications.

7. Map projections: a working manual. Snyder, John P. 1987. USGS Professional Paper 1395. Washington, DC: United States Government Printing Office.

8. Notes for GIS and The Geographer's Craft at U. Texas, on the World Wide Web (WWW) (current as of 10 April 1995):

http://wwwhost.cc.utexas.edu/ftp/pub/grg/gcraft/notes/notes.html

9. Digital Geographic Information Exchange Standard (DIGEST). Allied Geographic Publication No 3, Edition 1.2 (AGeoP-3) (NATO Unclassified).

10. POSC Petrotechnical Open Software Corporation Web site:

http://www.posc.org/

+--------------------------------------------------------------------+

6 Appendices+--------------------------------------------------------------------+

+----------------------------------+


52/95

6.1 Tag ID Summary

Here are all of the TIFF tags (and their owners) that are used to storeGeoTIFF information of any type. It is very unlikely that any othertags will be necessary in the future (since most additional informationwill be encoded as a GeoKey).

ModelPixelScaleTag = 33550 (SoftDesk) ModelTransformationTag = 34264 (JPL Carto Group) ModelTiepointTag = 33922 (Intergraph) GeoKeyDirectoryTag = 34735 (SPOT) GeoDoubleParamsTag = 34736 (SPOT) GeoAsciiParamsTag = 34737 (SPOT)

Obsoleted Implementation:

IntergraphMatrixTag = 33920 (Intergraph) -- UseModelTransformationTag.

+----------------------------------+

6.2 Key ID Summary+----------------------------------+

+----------------------------------+

6.2.1 GeoTIFF Configuration Keys

GTModelTypeGeoKey = 1024 /* Section 6.3.1.1 Codes */ GTRasterTypeGeoKey = 1025 /* Section 6.3.1.2 Codes */ GTCitationGeoKey = 1026 /* documentation */

+----------------------------------+

6.2.2 Geographic CS Parameter Keys GeographicTypeGeoKey = 2048 /* Section 6.3.2.1 Codes */ GeogCitationGeoKey = 2049 /* documentation */ GeogGeodeticDatumGeoKey = 2050 /* Section 6.3.2.2 Codes */ GeogPrimeMeridianGeoKey = 2051 /* Section 6.3.2.4 codes */ GeogLinearUnitsGeoKey = 2052 /* Section 6.3.1.3 Codes */ GeogLinearUnitSizeGeoKey = 2053 /* meters */ GeogAngularUnitsGeoKey = 2054 /* Section 6.3.1.4 Codes */

GeogAngularUnitSizeGeoKey = 2055 /* radians */ GeogEllipsoidGeoKey = 2056 /* Section 6.3.2.3 Codes */ GeogSemiMajorAxisGeoKey = 2057 /* GeogLinearUnits */ GeogSemiMinorAxisGeoKey = 2058 /* GeogLinearUnits */ GeogInvFlatteningGeoKey = 2059 /* ratio */ GeogAzimuthUnitsGeoKey = 2060 /* Section 6.3.1.4 Codes */ GeogPrimeMeridianLongGeoKey = 2061 /* GeogAngularUnit */

+----------------------------------+


53/95

6.2.3 Projected CS Parameter Keys

ProjectedCSTypeGeoKey = 3072 /* Section 6.3.3.1 codes */ PCSCitationGeoKey = 3073 /* documentation */ ProjectionGeoKey = 3074 /* Section 6.3.3.2 codes */ ProjCoordTransGeoKey = 3075 /* Section 6.3.3.3 codes */ ProjLinearUnitsGeoKey = 3076 /* Section 6.3.1.3 codes */ ProjLinearUnitSizeGeoKey = 3077 /* meters */ ProjStdParallel1GeoKey = 3078 /* GeogAngularUnit */ ProjStdParallel2GeoKey = 3079 /* GeogAngularUnit */ ProjNatOriginLongGeoKey = 3080 /* GeogAngularUnit */ ProjNatOriginLatGeoKey = 3081 /* GeogAngularUnit */ ProjFalseEastingGeoKey = 3082 /* ProjLinearUnits */ ProjFalseNorthingGeoKey = 3083 /* ProjLinearUnits */ ProjFalseOriginLongGeoKey = 3084 /* GeogAngularUnit */ ProjFalseOriginLatGeoKey = 3085 /* GeogAngularUnit */ ProjFalseOriginEastingGeoKey = 3086 /* ProjLinearUnits */ ProjFalseOriginNorthingGeoKey = 3087 /* ProjLinearUnits */ ProjCenterLongGeoKey = 3088 /* GeogAngularUnit */ ProjCenterLatGeoKey = 3089 /* GeogAngularUnit */ ProjCenterEastingGeoKey = 3090 /* ProjLinearUnits */ ProjCenterNorthingGeoKey = 3091 /* ProjLinearUnits */ ProjScaleAtNatOriginGeoKey = 3092 /* ratio */ ProjScaleAtCenterGeoKey = 3093 /* ratio */ ProjAzimuthAngleGeoKey = 3094 /* GeogAzimuthUnit */ ProjStraightVertPoleLongGeoKey = 3095 /* GeogAngularUnit */

Aliases:

ProjStdParallelGeoKey = ProjStdParallel1GeoKey ProjOriginLongGeoKey = ProjNatOriginLongGeoKey ProjOriginLatGeoKey = ProjNatOriginLatGeoKey ProjScaleAtOriginGeoKey = ProjScaleAtNatOriginGeoKey

+----------------------------------+

6.2.4 Vertical CS Keys

VerticalCSTypeGeoKey = 4096 /* Section 6.3.4.1 codes */ VerticalCitationGeoKey = 4097 /* documentation */ VerticalDatumGeoKey = 4098 /* Section 6.3.4.2 codes */

VerticalUnitsGeoKey = 4099 /* Section 6.3.1.3 codes */

+---------------------------------------------------------------------++----------------------------------+

6.3 Key Code Summary+----------------------------------+


54/95

6.3.1 GeoTIFF General CodesThis section includes the general "Configuration" key codes, as well asgeneral codes which are used by more than one key (e.g. units codes).

+----------------------------------+

6.3.1.1 Model Type Codes

Ranges:

0 = undefined [ 1, 32766] = GeoTIFF Reserved Codes 32767 = user-defined [32768, 65535] = Private User Implementations

GeoTIFF defined CS Model Type Codes:

ModelTypeProjected = 1 /* Projection Coordinate System */ ModelTypeGeographic = 2 /* Geographic latitude-longitude System */

ModelTypeGeocentric = 3 /* Geocentric (X,Y,Z) Coordinate System */

Notes:

1. ModelTypeGeographic and ModelTypeProjected correspond to the FGDC metadata Geographic and Planar-Projected coordinate system types.

+----------------------------------+

6.3.1.2 Raster Type Codes

Ranges:

0 = undefined [ 1, 1023] = Raster Type Codes (GeoTIFF Defined) [1024, 32766] = Reserved 32767 = user-defined [32768, 65535]= Private User Implementations

Values: RasterPixelIsArea = 1 RasterPixelIsPoint = 2

Note: Use of "user-defined" or "undefined" raster codes is notrecommended.

+----------------------------------+

6.3.1.3 Linear Units Codes

There are several different kinds of units that may be used ingeographically related raster data: linear units, angular units, unitsof time (e.g. for radar-return), CCD-voltages, etc. For this reason


55/95

there will be a single, unique range for each kind of unit, broken downinto the following currently defined ranges:

Ranges:

0 = undefined [ 1, 2000] = Obsolete GeoTIFF codes [2001, 8999] = Reserved by GeoTIFF [9000, 9099] = EPSG Linear Units. [9100, 9199] = EPSG Angular Units. 32767 = user-defined unit [32768, 65535]= Private User Implementations

Linear Unit Values (See the ESPG/POSC tables for definition):

Linear_Meter = 9001 Linear_Foot = 9002 Linear_Foot_US_Survey = 9003 Linear_Foot_Modified_American = 9004

Linear_Foot_Clarke = 9005 Linear_Foot_Indian = 9006 Linear_Link = 9007 Linear_Link_Benoit = 9008 Linear_Link_Sears = 9009 Linear_Chain_Benoit = 9010 Linear_Chain_Sears = 9011 Linear_Yard_Sears = 9012 Linear_Yard_Indian = 9013 Linear_Fathom = 9014 Linear_Mile_International_Nautical = 9015

+----------------------------------+

6.3.1.4 Angular Units CodesThese codes shall be used for any key that requires specification of anangular unit of measurement.

Angular Units

Angular_Radian = 9101 Angular_Degree = 9102 Angular_Arc_Minute = 9103 Angular_Arc_Second = 9104

Geotiff Spec

Documents

Transcript of Geotiff Spec