GeoTIFF/GDAL OPeNDAP Server Design

Introduction

This document is a design for a GDAL based OPeNDAP server primariliy aimed at serving GeoTIFF files such as those available from the UMD Global Land Cover Facility. However, an effort is made to try and handle the broadest set of geospatial raster products possible using GDAL and to capture as much supporting information as possible.

GeoTIFF Data Model

GeoTIFF is a flexible raster format with geospatial extensions.

TIFF Imaging Model

A TIFF file may contain a series of image directories. Each image directory describes a raster image which may have one or more samples (bands) along with a variety of auxilary information describing the color model, compression mechanisms, and other descriptive information. Each directory has the following core image properties: In theory different samples in an image can have different bitspersample but in practice this is extremely uncommon, and unsupported by GDAL or libtiff so we will ignore this issue.

As mentioned, a TIFF file can have multiple image directories. Each image directory (IFD) describes one image. When a file contains multiple images, each image can be independent with size, data type and photometric interpretation unrelated to others in the same file. It is also common that each directory represent a page in documented oriented files, or that some directories are reduced resolution forms of other directories.

The full TIFF 6 Specification is found on the Adobe web site.

GeoTIFF Georeferencing

The GeoTIFF specification is an extention to the TIFF format, adding tags to describe how pixel locations can be related to some geospatial coordinate system and describing that geospatial coordinate system. That is it allows you to determine where the image lies in the real world.

The GeoTIFF specification and additional information can be found on the GeoTIFF page.

Georeferencing Transformation

The georeferencing transformation is how pixel/line locations on the image are related to some geospatial coordinate system. There are three approaches to defining this relationship in GeoTIFF:

  1. Tiepoint + PixelScale: A location for one point on the image (a tiepoint) is provided, along with a dimension of a pixel in the x and y dimensions in that coordinate system. This is suitable for defining images that have a regular unrotated sampling in the coordinate system in question.

  2. GeoTransMatrix: This is a matrix defining an affine transformation between image spaces and georeferenced space. In 2D is it equivelent to the ESRI world file often used for simple georeferencing. Once again, the image must have already been sampled regularly in the coordinate system in question, but the image may be rotated and sheared.

  3. Multiple Tiepoints: In the most general case, the GeoTIFF file just contains a series of tiepoint. That is a list of locations on the image with associated geospatial coordinate system positions. When this method is used, there is no explicit assumption of how the location of other pixels can be computed though various means such as best-bit polynomials are often used. This method is appropriate for images that are not regularly sampled in the target coordinate system or those that might have no analytical relationship with the target coordinate system (such as raw satellite images without terrain or other corrections).

Most GeoTIFF files in use used the first georeferencing form though it is not uncommon for "raw" GeoTIFF files to be provided in the 3rd form with only approximate tiepoints at image corners.

Coordinate System Descriptions

The description of the coordinate system is loosely based on the EPSG coordinate system data model. EPSG maintains catalogs of published geographic and projected coordinate system descriptions with associated code numbers. For instance, the common geographic coordinate system "WGS84" has the EPSG id 4326. The projected coordinate system "UTM zone 11 North / WGS84" has EPSG id 32611.

The GeoTIFF file can store the whole coordinate system definition by reference to a particular GCS (geographic coordinate system) or PCS (projected coordinate system) code from EPSG, or it can contain a set of parameters defining a user provided coordinate system.

GDAL Data Model

The GDAL data model is fairly closely related to the GeoTIFF data model, and is more completely described in the GDAL Data Model document. Here we will point out some key differences between the GeoTIFF data model, and the GDAL data model that will have implications for our design.

For the most part the GDAL data model is a superset of the GeoTIFF data model.

DDS Model Design

The core decision is to model each GDALRasterBand (of TIFF "sample") as a Grid 2D object. The maps will be used to associate georeferencing information with the grid. A simple 512x512 1 band 8bit image might have a DDS that looks like this:

Dataset {
    Grid {
     ARRAY:
        Byte band_1[easting = 512][northing = 512];
     MAPS:
        Float64 easting[easting = 512];
        Float64 northing[northing = 512];
    } band_1;
} utm.tif;
An RGBA file would have a grid for each band, and might look like this: 
Dataset {
    Grid {
     ARRAY:
        Byte band_1[easting = 256][northing = 200];
     MAPS:
        Float64 easting[easting = 256];
        Float64 northing[northing = 200];
    } band_1;
    Grid {
     ARRAY:
        Byte band_2[easting = 256][northing = 200];
     MAPS:
        Float64 easting[easting = 256];
        Float64 northing[northing = 200];
    } band_2;
    Grid {
     ARRAY:
        Byte band_3[easting = 256][northing = 200];
     MAPS:
        Float64 easting[easting = 256];
        Float64 northing[northing = 200];
    } band_3;
    Grid {
     ARRAY:
        Byte band_4[easting = 256][northing = 200];
     MAPS:
        Float64 easting[easting = 256];
        Float64 northing[northing = 200];
    } band_4;
} rgba.tif;
Some points worth noting:

Outstanding Issues:

DAS Model Design

A variety of information will be transported via the DAS describing the dataset. 

Attributes {

    GLOBAL { 
        Float64 Northernmost_Northing 71.1722;
	Float64 Southernmost_Northing  4.8278;
	Float64	Easternmost_Easting  -27.8897;
	Float64	Westernmost_Easting -112.11;
        Float64 GeoTransform "71.1722 0.001 0.0 -112.11 0.0 -0.001";
	String spatial_ref "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.257223563]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",0.0174532925199433]]";
        Metadata { 
          String TIFFTAG_XRESOLUTION "400";
          String TIFFTAG_YRESOLUTION "400";
          String TIFFTAG_RESOLUTIONUNIT "2 (pixels/inch)";
        }
    }

    band_1 {
        String Description "...";
        String 
    }
}

Dataset

There will be an object in the DAS named GLOBAL containing attributes of the dataset as a whole.

It will have the following subitems:

Note that the edge northing and easting values can be computed based on the grid size and the geotransform. They are included primarily as extra documentation that is easier to interprete by a user than the GeoTransform.

Band

There will be an object in the DAS named after each band containing attribute of the specific band.

It will have the following subitems:

An effort has been made to adhere to netCDF COORDS and/or CF conventions where the appear to be applicable. Some further review in this area is still called for. For instance, the CF convention includes (in appendix F) naming conventions for describing projected coordinate systems that are not currently being used.

Implementation Notes