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

Requirements

• 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:

1. The GeoTiffIIOMetadataAdapter cannot modify the IIOMetadata object (e.g., it's read-only).
2. No mechanism exists to examine the parameters of a coordinate system and produce an EPSG code.

Key features of the package:

1. Has a reasonable level of isolation from the Geotools library ala the GeoAPI interfaces. Areas of best isolation are CRS, and areas of worst isolation are the grid coverage exchange API.
2. Utilizes the JAI ImageI/O tools to perform the actual file I/O.
3. Interprets metadata retrieved as IIOMetadata.
4. Functionality is logically subdivided:
   • Classes required to interface to Geotools.
   • An adapter class to retrieve GeoKeys from the IIOMetadata by symbolic name (GeoTiffIIOMetadataAdapter).
   • An adapter class to interpret the values in the GeoKeys and create a corresponding coordinate system with a factory (GeoTiffCoordinateSystemAdapter).

License Information