Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »



The Problem:

Actually, in the GeoSpatial context, a wide range of raster data format exists. However, GeoTools may successfully handle only a very reduced set of them (GeoTiff, ArcGrid, WorldImage, Image Mosaicks, Image Pyramid, Gtopo30).

The proposal:

The purpose of the proposed module is to extend the raster data access capabilities of the GeoTools library and, consequently, the GeoServer capabilities too.
This task could be achieved by leveraging on the ImageI/O-Ext project which uses the powerful and world widely adopted Geospatial Data Abstraction Library (GDAL) by means of a set of Java native libraries generated by the Simplified Wrapper and Interface Generator (SWIG).
Basically, ImageI/O-Ext provides a set of ImageI/O plugins to access different raster data formats. The list of actually supported formats is available at:

Further details on ImageI/O-Ext project are available at:
Further details on GDAL are available at:
Further details on SWIG are available at:

To let things work, you should build GDAL (In case you need support for some special formats which leverages on external lib, you need to properly configure this), then generate Java bindings. Detailed step-by-step instructions about such a procedure are contained in the ImageI/O-Ext setup guide, available at (openOffice) or (PDF) doc.
If you are not registered to, specify "guest" as userID without PASSWORD when asked for login to download the documentation.

In order to avoid the manual/long build process of GDAL and JNIs, the ImageI/O-ext provides a self-deployment module which allows to deploy ready-to-use native libs in the proper location. Detailed instructions about this are contained in the previous document (Basically, all you need is specifying the -Ddeploylibs property when building ImageI/O-Ext with maven). Actually, libraries are available for Windows and Linux. Future developments plan for a Mac build.

The proposed module is composed of a main abstract BaseGDALGridCoverage2DReader (extending AbstractGridCoverage2DReader) which leverages on the core of the ImageI/O-EXT project: the gdalframework module. Since, the hard work of data access and management is performed by the GdalFramework, the Geotools reader simply needs to query it to obtain all the needed information (such as CRS, Envelope, raster properties) and delegate the read to the ImageI/O-Ext.
The GDAL Data model allows to represents any datasource (of any format) with a basic Dataset object. ImageI/O-Ext wraps all the properties of this object within a GDALCommonIIOImageMetadata object extending the ImageIO IIOMetadata class. The default implementation of the BaseGDALGridCoverage2DReader will query an instance of this object obtained by the framework to setup Envelope, CRS, GeoTransformation and GridRange. Some formats allows to specify/handle an additional set of metadata. In such a context, an extended implementation of the geotools GDAL reader will leverages on a proper GDAL metadata subclass.

The GDAL based plugin allows to customize the data access by means of a set of read parameters.
First of all, it leverages on the AbstractGridFormat USE_JAI_IMAGEREAD parameter/Hint which allows to specify if the underlying ImageIO plugin should use a JAI ImageRead operation (Which leverages on the Deferred Execution model, Tile caching/scheduling,...) or a more simple direct call to the read method of the ImageReader.
Note that when performing a JAI ImageRead operation, the internal computations get access to any involved tile using an ImageReader read operatin. In case some raster data are striped (where tiles are in the form Nx1 pixels) the tiles read process may be time consuming. To improve this, the parameter SUGGESTED_TILE_SIZE allows to specify a different layout to be used by JAI ImageRead operation when consuming tiles. Values to be specified are in the form "W,H" where W represent the suggested tile width and H represents the suggested tile height.
Moreover, ImageIO-Ext introduces a very useful JAI operation: ImageReadMT. This allows to perform multithreaded JAI ImageRead operations.
To tell the geotools reader to use multithreading, you simply need to specify the USE_MULTITHREADING parameter (Set as TRUE).
These parameters are declared within a BaseGDALGridFormat extending the AbstractGridFormat.

Beside of this main structure, several format specific packages exist to setup the format related information.

Supported Formats

Actually supported formats on the gt2-imageio-ext-gdal module are:
Erdas Imagine
JPEG2000 (Kakadu)

Note that extending the raster data access capabilities with add for additional formats is a simple task due to the GDAL power capabilities integration in the ImageI/O-Ext.
Usually, writing a new ImageI/O-Ext plugin for a "not too much complex" format requires 10-15 minutes of work (you only need to setup a XXXImageReader as well as a XXXImageReaderSpi). The same (or minor time) is requested to setup the related GeoTools plugin in the gt2-imageio-ext-gdal module (You only need to setup a XXXFormat, a XXXFormatFactory and a XXXReader), where XXX is usually the name of the new format to be supported. With further developments it would be nice to extend GeoTools raster data access capabilities to support any format supported by GDAL (See:

Licensing Issues:

- actually the ECW SDK license agreement prohibits the SDK use on a server (So, for the moment, we can't distribute ECW support with GeoServer). Maybe, when future versions of ECW SDK will be released by ErMapper, the license of the older and slower one may change.
- Due to licensing issues, you should have your KAKADU license to use the JPEG2000 (Kakadu based) geotools plugin.

Some notes on old unsupported modules:

Actually, in the unsupported section, there are an ECW and a MrSID modules. Since some GeoTools/Udig/GeoServer people use these modules, they wouldn't be removed until the GDAL based Geotools plugin will ready and fully tested.

  • No labels