For Review and Comment: Coverage Plugin Use Cases
Design and Implementation: A chart of personnel and a list of major tasks: OpenOffice or PDF


This effort can be defined as an attempt to provide a unified data access API to an n-Dimensional dataset where some subset of the dimensions contain a known spatial and/or temporal definition.

This page should be regarded as a touchstone for the coverage augmentation project. It collects into one location many diverse and detailed elements of design, experimentation and implementation.

Motivation and Scope

This page describes why we are exploring the augmentation of GeoTools' coverage functionality. It also explains that we are limiting ourselves to 4D coverages with bands, and why.

Overall Design Guidelines

Much pondering, many discussions, and some experiments have taken place over the past months. Some of these are captured on the related pages. The result of these activities is a fairly accurate notion of the required functionality and desired characteristics of an nDimensional subsystem. Here is a summary:

  1. To the maximum extent possible, plugins for specific data formats should remain ignorant of spatial or temporal significance of the data they transport. When dealing with gridded data, plugins should deal only with indicies into the grid. When storing or retrieving spatial referencing information, plugins should concentrate on copying descriptive parameters from metadata object to file or from file to metadata object.
  2. Data should be accessible by either it's location in the grid, or by it's spatio-temporal location. The conversion from grid location to spatio-temporal location should be exposed to the interested user.
  3. The index into the gridded data should be unified and symmetric.
  4. In order to leverage the performance and intelligent tile caching of JAI, it is highly desirable to design a system compatible with the J2SE ImageIO framework.
  5. Plugins developed for our nD framework should be accessible and usable outside of GeoTools, and maybe even outside a geospatial framework. (e.g., A good netCDF plugin which can extract data slices might be usable in any 2D imaging program, even without spatial meaning.) If this is not possible, then a minimum set of classes and interfaces should be collected into a module which does not depend on the remainder of GeoTools.

Project Organization and Status

The following people and organizations have expressed interest in or are contributing to this project:


USDA Forest Service / Fire Science Lab.

Our group is developing an air quality forecasting model which takes real time fire detections from MODIS as input. We have co-developed and validated a prototype burn scar algorithm to refine the perimeters generated from hotspots alone. Geotools is used in our processing chain, largely because it's extensible. We have commercial products available to us, but they haven't implemented the functionality we need and we can't add it ourselves.

Having gained some experience programming using Geotools, we adopted Geoserver as our display mechanism. Our philosophy in doing so was that we wanted everything to be capable of being displayed on a single map. As we are integrating satellite imagery, fire perimeters from incidents, existing database sources of MODIS Hotspots (which we also developed), and the output of numerical weather prediction models (WRF), we surmized that existing solutions capable of ingesting all of this data were rare. These were usually in the category of visualization programs which could produce a static output or interactively view the data on a local workstation. We required a web based solution, capable of distributing not only finished map products to the public, but also the underlying data to collaborators and associated modeling centers. Our appraisal was that it was easiest to satisfy all our requirements by adding the missing parts to Geoserver/Geotools.

NURC / Nato Undersea Research Centre.

Our group is comprised of people with various backgrounds, oceanographers, eletronic engineer, telecommunication engineers, software engineers. Our area of interest currently covers various aread including remote sensing applications related to ocean colors products and remote surveillance, sea bottom type classification, tactical decision aid applications and, of course, OGC Web Services implementations in order to support the management of the vaste amount of data we acquire, process and produce during our research activities.

Development of OGC-enabled Web Services using GeoTools and GeoServer came in the path after having evaluated various Open Source products like Minnesota MapServer with GDAL/OGR and Deegree and astime goes by we get more and more confident about this choice!

ITC / International Institute for Geo-Information Science and Earth Observation

The Geo Software Development unit supports research and education at ITC. Since 1985 we developed our own, mainly raster based, GIS/RS software ILWIS. Datasets are becoming larger and larger in number of bands and in time, standards are getting mature, and more non-professional software developers want to develop themselves. Thus we stop the evelopment in C++ and move to Java. To prevent reinventing the wheel and to promote reuse we think it useful to cooperate in GeoApi/GeoTools. With con terra and the university of Muenster we are cooperating in 52°North.






Bryce Nordgren

Very task specific. Available 100% for mission-critical items. Available 0% when occupied with unrelated emergencies.


Alex Petkov

Available approx 50% perpetually for all aspects pertaining to our geospatial infrastructure.


Martin Desruisseaux

Task specific. Available 100% of the time for some issues like ISO 19123, port of legacy implementation, etc. But often distracted by unrelated emergencies.


Wim Koolhoven


Project Tasks and Progress

Alessio does not have a JIRA account that I'm aware of, or more stuff would be assigned to him. Some of the things assigned to Simone in the previous table really belong to Alessio.

Initial Design

Click here to view/download an initial summary of design considerations, implementation components, and a synthetic interaction between a GeoTools client, the GeoTools framework, and a GeoTools grid coverage plugin.

An initial use case document from the perspective of a Coverage Plugins has been prepared. Click here to download the OpenOffice document. Edit and save your changes, then email to I can use the "Compare Documents" function to see what you had to say. Alternatively, you can turn Change Tracking on.

This problem decomposes nicely into two equally important, yet separate topic areas: data and metadata. Each topic is going to have it's own wiki page to collect thoughts and design notes.

Wiki pages for major design components:

Standards under consideration

Interoperability Note

The design of this project is going to occur with commonly available open-source or community-edition (e.g., Free-as-in-lunch) tools. UML diagrams will be generated with Poseidon Community Edition and design documents will be written with OpenOffice 2.0. These tools are sufficiently powerful and available to address our immediate design needs. Where appropriate, important documents will be exported to PDF format and placed on the WIKI. However, the original documents will (eventually) be checked into Subversion for others to edit. (NOTE: This does not constitute an endorsement of these tools by GeoTools, NATO, or the USDA Forest Service.)

Community Discussion thus far

Coverage Augmentation Wiki Space