GeoTIFF FAQ Version 2.4
Last Updated: February, 2011
Author: Mike Ruth
Editor: Frank Warmerdam
Email: warmerdam@pobox.com
The FAQ is intended to provide an introduction for persons new
to GeoTIFF, as well as pointers to significant resources on the WWW for
further information. Comments concerning this FAQ, and suggestions for
improvement and addition to the FAQ
may be emailed to
warmerdam@pobox.com.
For general WWW information and resources concerning GeoTIFF,
please point your browser to
GeoTIFF
WWW Homepage.
-
What is TIFF format?
-
What is the purpose of GeoTIFF format for satellite data?
-
What is GeoTIFF and how is this different from TIFF?
-
Who owns GeoTIFF Format?
-
Can IP, GIS, CAD, and Desktop Mapping systems all use GeoTIFF?
-
Does GeoTIFF imagery conform to the TIFF specification?
-
Can systems that don't use geography read a GeoTIFF image?
-
Does the Geographic data look transparent to the user?
-
Who is working on definition of GeoTIFF?
-
What's a TIFF tag?
-
What is the relationship between a TIFF tag and the actual image?
-
Are the tags in separate files from the tiff files ...
-
Why is GeoTIFF based only on TIFF format?
-
Is the tagset proprietary?
-
What are the advantages of TIFF format for geographic data?
-
Is GeoTIFF really platform interoperable?
-
What will happen in my GIS if I load a GeoTIFF image?
-
Doesn't anyone else have TIFF tags for geographic information?
-
Is GeoTIFF based on the world reference files that ESRI uses?
-
How do I convert between ESRI world files, and GeoTIFF?
-
How do I preserve GeoTIFF info when editing my image?
-
What are the requirements to make a TIFF image ...
-
Can I make customized geographic projections using GeoTIFF?
-
What is the effect of PixelIsArea vs. PixelIsPoint?
-
What is the Axis Order in GeoTIFF?
-
How should Vertical Datums and Vertical Coordinate Systems be encoded in GeoTIFF?
-
Who are POSC and EPSG and why is GeoTIFF involved with them?
-
What EPSG Version does GeoTIFF Use?
-
Where can I get a copy of the GeoTIFF spec to review?
-
What can I do to support GeoTIFF ...
-
How can I monitor the progress and changes to future GeoTIFF specs?
-
Is the GeoTIFF community still active?
TIFF format is the most popular and versatile raster data format in the world today.
TIFF is a format for storage, transfer, display, and printing
of raster images, such as clipart, logotypes, scanned documents.
Today, TIFF is being used for storage of map information, too.
More information on TIFF can be found at Joris Van Damme's
TIFF
Page.
The TIFF imagery file format can be used to store and transfer
digital satellite imagery, scanned aerial photos, elevation
models, scanned maps or the results of many types of geographic
analysis. Over the past several years many users of such images have
urged geographic data suppliers to provide imagery in TIFF format.
TIFF is the only full-featured format in the public domain,
capable of supporting compression, tiling, and extension to include
geographic metadata. GeoTIFF implements the geographic metadata
formally, using compliant TIFF tags and structures.
"GeoTIFF" refers to TIFF files which have geographic (or
cartographic) data embedded as tags within the TIFF file.
The geographic data can then be used to position the image
in the correct location and geometry on the screen of a
geographic information display.
GeoTIFF is a metadata format, which provides geographic
information to associate with the image data. But the TIFF
file structure allows both the metadata and the image
data to be encoded into the same file.
GeoTIFF makes use of a public tag structure which is platform interoperable between
any and all GeoTIFF-savvy readers. Any GIS, CAD, Image Processing, Desktop Mapping
and any other types of systems using geographic images can read any GeoTIFF files
created on any system to the GeoTIFF specification.
The GeoTIFF format is completely open, public domain, non-proprietary. It
was produced by Dr. Niles Ritter, while at NASA-JPL (Jet Propulsion
Laboratory), and
changes, or additions to the format are proposed through a public review using
email and WWW resources. Two meetings of developers from all areas of the
geographic information processing industry have lead to proposals for revision,
since early 1994.
There is no restriction on licensing, implementation, promulgation, or any
uses of the format. The format is entirely open, and available to all.
The specifications are public, there are abundant free software source libraries,
toolkits, data samples, and technical support through the email forum.
The format is available to any software company, for free with no restrictions on license.
It is the decision of the product managers for each software to include GeoTIFF capability in
the geographic data management products which they sell.
Many systems today can read GeoTIFF files into correct geographic position in a variety
of Geographic Information Systems (GIS), Image Processors (IP) and Computer Aided Design (CAD)
software. You need to check with your system provider to find out if they have written the
software module to read/write GeoTIFF imagery in the software version which you use.
The TIFF spec (Version 6) is be supported by the GeoTIFF format.
That is, the GeoTIFF images conform in every way to the
TIFF formal specifications. The tags used for the "Geo" portion of
the TIFF format conform to the acceptable and customary
use of "private" or "registered" TIFF tagsets. The GeoTIFF tags and definitions are
considered completely "orthogonal" to the baseline and extended
TIFF tag definitions currently supported in TIFF V 6 by Adobe/Aldus.
Many such image "visualization" systems do not use geography as a
basis for placement of their images. These systems are all able
to view a GeoTIFF image just as though there were no geographic
information in the TIFF file. To non-GeoTIFF-savvy readers, the
GeoTIFF image should look and behave like any other TIFF image.
Note, that some systems that don't support the double precision tag
type of TIFF 6.0, or that fail with TIFF files with unexpected private
tags, cannot read GeoTIFF files. It seems that ArcView 2 suffered
from this problem.
Or does the user have to do something with the GeoTIFF
to be able to load and place it ?
This is a software implementation question. But most GeoTIFF-savvy
systems look at the geographic information
and use it without any requirement that the user know the content
of the geographic tags. The GeoTIFF format provides enough
information that the software can automatically place an image
without requirement of any user intervention, such as typing
in coordinates, digitizing points, or other labor intensive
and technical actions. One aim of GeoTIFF is to reduce the
need of users to be geographic experts in order to load a
map-projected image or scanned map.
The original working group included representatives of SPOT Image Corp, and
SPOT Image S.A. (France), Jet Propulsion Laboratory (NASA),
US Geological Survey, Intergraph, ESRI, ERDAS, Trifid, MapInfo,
and Softdesk. In addition, a consortium of over 140 international
subscribers have been monitoring and contributing to the spec's
evolution through an email discussion forum.
In April, 1996, over 40 industry representatives, including several
international participants, members of US DMA (Defence Mapping Agency),
and additional software companies (Bentley, E Systems, and others) and
additional satellite and aerial imaging providers (Space Imaging, Orbital,
Vargis Aerial and others).
A TIFF tag conveys information about the imagery. It is TIFF's
version of metadata (data about data). TIFF Tags are the only
way that a TIFF reading software can obtain fundamental information
about the TIFF image. TIFF reading software all implement TIFF tags
to control the display and printing of TIFF images.
The image is the "product" or the "purpose" of the TIFF format.
The "tags" merely describe the image with information that the
TIFF reader needs to know in order to control the appearance of the
image on the user's display screen or printer.
... or are they built into the tiff file format?
The TIFF tags are built into the TIFF format. They include:
- TIFF Basic Tags (like tags for number of rows, columns, etc).
These are standard and mandatory in all TIFF files.
- TIFF Extended Tags (like tags for certain color systems, rather
more specialized). These are optional in all TIFF files.
- "Private" TIFF tags (like the GeoTIFF tags).
These include tags which are registered to
specific users, in blocks of five tags. The users who register
their tags, may put any information they like on those tags
to support their software community. Then they can write
software to use those tags in whatever way they please.
... instead of, say, GIF or BMP or LAN or IMG or other formats?
TIFF is already used for geographic imagery, using certain proprietary
tag structures. GeoTIFF merely expands this to involve public domain
tags and structures that are interoperable between any GIS.
TIFF is the only format in the public domain which can support
the wide variety of image types already used for geographic
imagery. TIFF can support 8-bit black and white images, up
to 16 and 32 bit elevation models, 24 bit color imagery, and any
other type of image. TIFF also supports the most varieties of
compression and tiling options, to increase the efficiency of
image transfer and utilization. The other data formats possible
are limited in these areas, or are still merely proposals, while
TIFF has been implemented for a decade or so.
It is almost the only format which allows the flexibility
to support tag structures, like the geographic metadata
of GEOTIFF, without causing a conflict with non-geographic uses
of the raster imagery. TIFF is already the most popular image
format in the world, and most GIS platforms can already handle TIFF format today, using
either the TIFF Basic tagset, extended tagset, or various
private tagsets.
The TIFF tags (remember, these are *metadata*) are not proprietary.
The GeoTIFF tags are
completely public and published for anyone to use for any imagery.
So, anyone may create any images which use the same tagset
as SPOT or other users of the GeoTIFF structure.
The user of a GeoTIFF file, and a GeoTIFF-savvy software reader will notice
that the software will let the user load and place the image on a
simplified "point and click" basis. The users should not have to enter
projection strings, control points, cartographic definitions, etc in order
to support the loading of the image.
The TIFF structure is the only image format which is extensible, allows
private implementations and has the flexibility to support geographic
information. For users, GeoTIFF files provide the possibility of
a single image format compatible with all GIS vendor software.
At present, many GIS software do implement the ability to read the
exact same GeoTIFF specification for any compliant image file. This means
that users of different software can now exchange and share raster files
without needing to run translators, assuming they are exchanging between
software that read GeoTIFF format.
The TIFF tag structure is designed to be simple
and platform independent, so any GIS software developer can make
use of the tags in just a few hours of program development. TIFF
files which use the proposed GeoTIFF tagset can be transported from
one display environment to another, provided both system software
support the GeoTIFF spec. For the user, this means greater ease of use of
images, less hassle importing and exporting raster formats, and less
duplication of images in everyone's proprietary format in a single
network of heterogeneous GIS displays.
When users "click on" a TIFF image in a GeoTIFF-savvy reader
and it comes up on their screen the image should be automatically
"georeferenced" to correct position and scale, with respect
to the cartographic parameters of the users "map projection."
Thus the GeoTIFF image should display "in the right position",
compared to other features in the computer display (such as
roads, hydrology, or similar mapped features). In this way, a satellite image
of, say, San Francisco, will position itself in the GIS
in San Francisco, and the roads, streams, and coastlines
in the GIS coverages will overlay on top of the image. This is
useful for any GIS applications where the user wants to see
both the digital map, and a picture of the same area in the same
geometric reference. From this a user can "heads-up" digitize,
interpret features visible on the image, or conduct other
raster/vector processes supported by the GIS.
Both ESRI and Intergraph have been involved in the GeoTIFF definition
since the inception of GeoTIFF and have released software which support
the open GeoTIFF tag structure.
ESRI has a history of using a private tag which Arc/Info uses to
support image placement.
This tag is basically a simple tag implementation of their
WORLD file on a TIFF tag, internal to the TIFF format file.
ESRI prefers to keep this tag private. GeoTIFF tags do
everything ESRI's tag could do and a lot more.
Intergraph also has a tag set which they have used for
several years to support their raster geographic
software. This set is completely private since they reserve
the right to change any of its structure at any time without
review or notification outside of their user base.
There are many many other TIFF private
tagsets, as well as private "IFD's" (image file directories)
which can exist transparently within the TIFF structure.
But only GeoTIFF is known to the public domain
and supports geographic parameters.
ESRI's world file is a separate file with limited metadata content
designed only for use in Arc/Info and other ESRI software, though widely
supported by other software. The world reference file only contains the
coefficients for an affine transformation between raster coordinates, and
world coordinates, but no definition of the coordinate system.
The GeoTIFF structure, by comparison, is rich in content and
packs everything into a single file. The GeoTIFF tag structure
covers more diverse options for projection spaces, datums,
ellipsoids, coordinate types, and related geographic features
than the ESRI tag. And the GeoTIFF structure is intended to
become entirely public domain, unlike tags withheld for
private implementations.
The contents of the worldfile are six numbers (each on their own line):
A
B
C
D
E
F
The georeferenced location of a pixel center can be computed as:
Xgeo = E + Xpixel * A + Ypixel * C
Ygeo = F + Ypixel * D + Xpixel * B
So, a typical (north up) arrangement would be:
pixel width in geounits
0
0
pixel height in geounits (normally negative)
top left X geo location
top left Y geo location
While it is presumably possible to accomplish this with ESRI software, it
is also possible to use the listgeo and geotifcp executables
distributed with libgeotiff to accomplish this. Recent binaries for selected
platforms, and source, can be found at:
ftp://ftp.remotesensing.org/geotiff/libgeotiff/
To convert a TIFF file (abc.tif) and a world file (abc.tfw) into a simple
GeoTIFF file (geo_abc.tif) without a projection definition use the following
command:
% geotifcp -e abc.tfw abc.tif geo_abc.tif
If a geotifcp compatible metadata file defining the coordinates system is
also available (such as produced by listgeo run on a comparible GeoTIFF file),
it can be combined with the georeferencing information of the world file to
produce a fully defined GeoTIFF file using a command like this:
% geotifcp -e abc.tfw -g projdef.txt abc.tif geo_abc.tif
The listgeo executable can be used to produce a geo_abc..tfw file from a
GeoTIFF file (geo_abc.tif) using a command like this:
% listgeo -tfw geo_abc.tif > projdef.txt
When I edit my GeoTIFF image in Photoshop or other applications, and then save
the result the geotiff information is lost. How can I avoid this?
If a given applications does not support the GeoTIFF tags it will generally
discard them when reading a GeoTIFF image and they won't be present after a
save. However, it is possible to save the GeoTIFF metadata and reapply it to
the image later using commandline utilities distributed with libgeotiff.
Given a GeoTIFF file named original.tif, and a modified file (modified.tif) without the GeoTIFF tags, but still the same size and region:
listgeo -no_norm original.tif > original.geo
geotifcp -g original.geo modified.tif modified_geotiff.tif
The listgeo utility is saving a text version of the geotiff tags in the file
original.geo, and then geotifcp is copying the modified image, and in the
process reapplying the GeoTIFF tags to produce a modified GeoTIFF file. This
process only works properly if the modified.tif is the same number of pixels
and lines as the original file, and represents the same region on the earth.
... which is geographically correct for the proposed tagset?
The images should be pre-corrected to a standard map projection,
such as UTM, StatePlane, an international grid coordinate system
(such as "British NationalGrid", or "Nigeria East Belt" or similar).
Geotiff-savvy TIFF readers can then use the geotie tags
to place the image (say a satellite image) into the correct
position in the GIS display. For SPOT's products (called our SPOTView
product line) the images will be accurate within 12 meters
horizontal anywhere in the USA (a looser spec prevails in most
international SPOTViews). Images which are not georeferenced
to a map projection can still be entered into a GeoTIFF format
but with some compromises on precision/accuracy of placement.
The GeoTIFF spec contains fields for definition of projection
variables in 20 different coordinate transformation systems
(such as Lambert Conformal Conic, Albers Equal Area,
Transverse Mercator, etc). The datums and ellipsoids
supported by POSC are all available, as well as limited
support for most custom datums and ellipsoids. The GeoTIFF
format provides rules, fields, and "cookbooks" for defining
customized cartographic spaces if you need them. Since they will be
coded as "User Defined" in some fields, not all GeoTIFF readers will
be able to understand all possibilities.
Setting the GTRasterTypeGeoKey value to RasterPixelIsPoint or RasterPixelIsArea
alters how the raster coordinate space is to be interpreted. This is defined
in section 2.5.2.2 of the GeoTIFF
specification. In the case of PixelIsArea (default) a pixel is treated as an area and
the raster coordinate (0,0) is the top left corner of the top left pixel.
PixelIsPoint treats pixels as point samples with empty space between the
"pixel" samples. In this case raster (0,0) is the location of the top left
raster pixel.
The net effect is a half pixel offset when interpreting PixelIsPoint vs.
PixelIsArea images. There has been some confusion on the interpretation of
this value in the GeoTIFF community for some time and some held the opinion
that this parameter should have no effect on the georeferencing of the image.
While this matter has been settled, the result is that some software packages,
particularly those built on GDAL 1.7.x or older incorrectly interpret the
georeferenced location of PixelIsPoint images - placing them offset by half
a pixel. One way of avoiding compatibility problems is to produce GeoTIFF
files with the default PixelIsArea interpretation.
The axis order of a coordinate system is used to interpret coordinates. For
instance should (-5,45) in EPSG:4326 be interpreted as -5 degrees longitude, and
45 degrees latitude or -5 degrees latitude and 45 degrees longitude?
The GeoTIFF specification does not appear to specifically address axis order.
The EPSG dataset does define axis order for each coordinate system.
Unfortunately for most (all?) geographic coordinate systems it defines a
lat/long order that conflicts with common GIS practice and the examples
and existing practice in GeoTIFF files.
For that reason, it is suggested that geographic coordinate systems in
GeoTIFF be assumed to be with longitude, latitude coordinate ordering in
the GEOTIEPOINTS and related fields.
For projected coordinate system the situation is less clear. Examples are
all easting, northing but then most projected coordinate systems are defined
this way in EPSG. However, a few coordinate system (such as Krovak - EPSG:2065)
actually use other axis orientations. In the case of Krovak the first
coordinate is actually southing, and the second is westing. Note that axis
orientation can also affect the direction of positive (east vs. west, north
vs. south) as well as the order of the coordinates.
While there are few examples of files in these coordinate systems, it is
suggested practice to honour EPSG axis orientation definitions for projected
coordinate systems.
The GeoTIFF specification only lightly addresses vertical coordinate systems.
In support of .LAS format (which uses GeoTIFF tags for coordinate systems)
and for general GeoTIFF use there are some vertical coordinate system best practices being
written up in the wiki.
POSC is the
Petrotechical Open Software Company, a non-profit
corporation dedicated to open data standards and interoperability
in the oil and gas business. They distribute a geodetic model and
encoding system which is international
in scope, hierarchical in structure and inclusive of many
cartographic options and variables. The geodesy system and tables
are created and supported by the OGP, the International Association of
Oil & Gas Producers who have absorbed the work of the
European Petrotechnical Survey Group (EPSG).
The POSC tables (maintained by EPSG) are the most comprehensive and TIFF compatible tables
of cartographic inforamation available in the public domain today.
The GeoTIFF 1.0 Specification references the EPSG 2.1 database. Without
a specification revision this remains the case; however, it is common practice
among vendors producing and consuming GeoTIFF files to support recent
versions of the EPSG database, currently 6.4 or higher. The libgeotiff
reference implementation is distributed with .csv files from a recent release
of the EPSG database (used by normalization code); however, the names
enumerated in the various .inc files have not been kept up to date.
The most current version of the spec is maintained on the
GeoTIFF WWW Homepage. The spec it self is at:
http://www.remotesensing.org/geotiff/spec/geotiffhome.html
The GeoTIFF WWW site is supported by Frank Warmerdam. It contains
pointers to other GeoTIFF and TIFF resources, including software, sample
data sets, email archives, compiled utilities, and more.
... and platform interoperable raster imagery?
TELL your GIS software provider that you need to read
raster imagery which is in GeoTIFF format. Log formal
change requests with your software vendor, especially if
they are not on the current list of GeoTIFF supporters.
Most software companies develop on the basis of logged
formal client change requests. If nobody puts in a change
request, then the software doesn't get developed. You will
be doing yourself, your GIS provider, and your fellow users
a service by making this issue visible to the GIS providers.
You can also participate in a variety of standardization activities
throughout the geographic information processing industry and government.
GeoTIFF has been proposed to the Open GIS Consortium, for example, and other
entities are evaluating whether GeoTIFF should be proposed to international
or other standards groups. Let your opinion be known. "Wreak yourself
upon the world" (Robert Bork).
There is a GeoTIFF email list where the GeoTIFF file format and specification
is discussed. Subscription and mailing list archive information is available
at:
http://lists.maptools.org/mailman/listinfo/geotiff
GeoTIFF standard improvement efforts have been quiet since about early
1997. In early 1998 the original GeoTIFF mailing list stopped working due
to a machine failure at JPL, and a new list wasn't started till the fall
of 1998. Dr. Niles Ritter has left JPL, and has less time to put towards
GeoTIFF efforts. Mike Ruth has left Spot, and is less active in GeoTIFF
efforts.
However, in the meantime most geographically aware software produced that
could utilize TIFF imagery has added some level of support for GeoTIFF
ingest, and/or production. Discussions on mailing lists and between software
vendors has resulted in some refinements to interpretations of some
GeoTIFF tags.
In a sense GeoTIFF has become a large success despite a light hand at the
helm.
However, the quality of GeoTIFF implementations varies greatly, there are
no means to do conformance testing on produced GeoTIFF files.
The GeoTIFF mailing list is still active, and is a good place to
ask questions about GeoTIFF topics. As well, clarifications are developed
there for details about the list of available projections, their parameters,
units issues and so forth. The libgeotiff reference library is also
periodically released with updates to the EPSG .csv tables, and bug fixes.
There have been some efforts to put the GeoTIFF specification into the
care of either NASA or OGC, but those have not been successful. In
2008 libgeotiff joined the OSGeo
MetaCRS Project and to some sense stewardship of the GeoTIFF
specification is also in the care of that project.