Package org.geotools.gce.geotiff Description

A grid coverage exchange to manage the GeoTIFF Revision 1.0 format.

This package is going to be "evolutionary", rather than
"revolutionary". As functionality is added to the package,
this page will be updated. This page should be considered a current
synopsis of the capabilities of the module.

Revision Date

May 31, 2005

Requirements

This package requires that the runtime environment have access to
Java Advanced Imaging (JAI) and the JAI Image I/O extensions available
from Sun. Specifically, the
GeoTiffFormatFactorySpi
will report itself unavailable if any of the following are unavailable:

javax.media.jai.JAI

com.sun.media.jai.operator.ImageReadDescriptor

com.sun.media.imageio.plugins.tiff.GeoTIFFTagSet

Other classes are of course necessary to successfully read in the GeoTIFF
image. As they typically come bundled with one or more of the above,
they are assumed to be present if all of the above are present.

CRS Information

The ability of the GeoTiff module to interpret and accurately
express the geographic information encoded in the GeoTIFF file
relies strongly on it's ability to use the Geotools framework to
construct a meaningful coordinate reference system (CRS) object. Geotools
has a number of Authority Factories which take care of constructing
CRS information given the code assigned to that CRS.

The central problem is that a complete CRS is composed of many smaller
pieces (coordinate systems (CS), datums, and coordinate operations.) Each
of these smaller peices is assigned a code for berevity. So when a
GeoTIFF file is written, the coordinate information can either be a
single code representing the entire CRS (if you're lucky), or a combination
of each of the component codes. Reading a GeoTIFF involves the reverse
process: looking up either a single code or a collection of the
component codes and building up a CRS object from these components.

Geotools supports the looking up of EPSG codes in plugins. Therefore it
is critical that the environment inside which the GeoTIFF plugin is
running contain the appropriate epsg authority factory plugins.
Unfortunately, the definition of "appropriate" varies according
to the type of GeoTIFF file you are trying to read. If you know that
your GeoTIFF file contains only codes for complete CRSes, then you
can use an EPSG plugin which only looks up complete CRSes (e.g.,
epsg-wkt, the property file based EPSG authority factory.) If, however,
you want to be able to handle more types of GeoTIFF files (perhaps you
do not know where your GeoTIFF files are coming from), you must choose
an EPSG authority factory which can lookup components of a CRS
(e.g., epsg-access, the MS Access backed authority factory.)

In short, the exact means by which EPSG codes are turned into
actual Java Objects is left up to the application writer. Ensure that
the capabilities you have configured match the requirements imposed by
the data you are trying to read.

Current Functionality

The current iteration of the GeoTIFF plugin will read GeoTIFF files with the
following restrictions:

The coordinate system must be either projected or geographic
(geodetic coordinate systems not supported.)

The EPSG authority factory plugin chosen by the application writer
must successfully construct everything necessary to represent the
scene coordinates.

The Raster to Model transformation must be a simple translation.

This plugin does not use the "Hints" mechanism as of yet.
I don't know how to have the user specify the EPSG factories they
wish to use.

When constructing a user defined projected CRS, the Cartesian CS
associated with the system always has easting as the
first axis and northing as the second axis, and the units are
always the length units defined in the GeoTIFF file. I do not
know if it is possible to have a different combination.

The GeoTIFF plugin currently does not write GeoTIFF files. The
current obstacles to writing a GeoTIFF file are: