Skip to end of metadata
Go to start of metadata

This page serves as a central point of contact to collect all relevant information pertaining to the implementation of ISO 19123 coverage types within GeoTools. A record of our motivation for doing so may be found here: Multidimensional Georegistered Grid. Information about the Coverage module of the current release of GeoTools may be found here: Coverage Module.


Welcome to Coverage Implementation Central. This page is a touchstone for all things related to the Coverage development effort in GeoAPI and GeoTools. You may use this page as a means of keeping track of the coverage development effort, or you may use it to prepare yourself to jump in and help.

The implementation is being broken down into small work units which occupy separate Jira tasks. Generally there will be parallel Implementation Work Unit Groups (IWUGs) in GeoAPI and GeoTools space. Also generally, the GeoTools IWUG will depend on the corresponding GeoAPI IWUG. If you are interested in keeping up with the latest developments in coverage land and you have enough time available to complete an IWUG, feel free to assign the issue to yourself in Jira.

I am currently generating Coverage IWUGs, as the implementation phase is just beginning (timestamp=March 3, 2006). My own involvement will be limited to the generation of IWUGs until all the IWUGs are generated. Then I'll switch gears to implementation mode and start taking issues myself. The moral of this story is: I know there's only one IWUG now. Keep checking this page for new and interesting things to do! (smile)

Reference Guide

There is a single design and implementation master document which is being written in sections. The master document contains some administrative information, such as the overall package layout and the intended scope of the implementation effort. Each section is contained in a separate document and tackles a logically related subset of the coverage classes. The master document contains links to the component documents. Therefore, to see the entire document, you must download all of the source documents into the same folder, open the master document (*.odm), and respond "yes" when it asks you to update links. If there's problems with this procedure, email me.

The intent of this document is to describe the design in enough detail that implementors can use it to write code. Later on, it is hoped that this same document will serve as a users reference guide.

In the course of implementation, some changes may have to be made to the design in order to reflect reality. Do not be shy about making these changes. However, I do ask that you propagate your changes back up into the design/implementation document so that it is accurate.

Structure of the Reference Guide

Each section of the document follows a pattern.

  1. GeoAPI Interfaces are presented.
  2. A GeoTools design is presented.
  3. A detailed description of the design is presented. (Because this simultaneously describes the GeoAPI interfaces and the GeoTools implementation, a method of a class will occassionally be described even though its implementation is deferred to a child class.
  4. A section of modeling pre-work is provided (you are meant to fill this in.) This is concerned with the Ecore model you will be generating. More detailed instructions are found in Use of EMF.

The implementation documents and many supporting documents are written in OpenDocument Format (ODF) using (2.0). An updated list of applications which support ODF may be found here. I will occasionally convert the entire document to PDF, but the PDF version tends to be large. You can ensure that all sections contain the most current information by downloading all of the component documents. The following table associates the document sections with the corresponding GeoAPI and GeoTools Jira tasks.

Download the Reference Guide

Document Name



GeoTools JIRA





Coverage Core




Basic Grid Elements




Specialized Domain Objects




Specialized Value Objects




Poseidon Model

During the course of this implementation effort, a Poseidon UML model is gradually going to be built up. This model contains the GeoAPI interfaces and the GeoTools implementation classes. This model is responsible for the creation of all the figures in the reference guide. The community edition of Poseidon seems to have an effective upper limit to the size of the model you can use. There's no error message, it's just that the program gets slower as the model gets bigger. Hence, the possibility exists that the model will have to be broken into two or more pieces.

This model, for the moment, can be found distributed among the GeoTools Jira issues. Each model concerns only the Implementation Work Unit Group (IWUG) to which it is attached.

GeoAPI Effort

The coverage effort in GeoTools depends in large part on the development of ISO 19123 interfaces in the GeoAPI project. For each IWUG, there exists a corresponding GeoAPI and GeoTools Jira task. For the most part, ISO 19123 interfaces in GeoAPI's pending directory just need to be moved to the final package and modified to match the UML diagram. Martin has done an extensive commenting job which should be preserved as much as possible. However, at the time these interfaces were generated, "Record" and "RecordType" did not exist, nor did any of the NameSpace infrastructure. As such, finalizing the GeoAPI interfaces is largely a matter of updating the existing classes to match the UML diagram.

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it. Macro params are invalid

GeoTools Effort

Implementation of the Coverage classes in GeoTools should be aided greatly by the Reference Guide. However, the process of implementation is not a copy and paste operation. The Poseidon models and the UML diagrams included as "GeoTools Design" figures in the reference guide don't even include all the methods required to implement the interfaces. The diagrams are constructed to be as clear as possible about what items refer to GeoAPI interfaces and what refers to the implementation classes.

The implementation effort employs the Eclipse Modeling Framework (EMF). By doing so, we hope to realize some time savings without sacrificing robustness. Details on how to employ EMF are provided in the draft of Use of EMF.

The GeoTools implementation is taking place in the coverage_branch branch. This split off from trunk as a development branch last October. It is synchronized regularly with trunk to ease the eventual merging back into the main code base. The precise GeoTools version number at the time of this future merging is unknown. I am hesitant to venture a guess because the schedule has already slipped beyond what I was hoping for. (I got distracted by shiny Feature Models and didn't realize I'd have to implement things like Record and NameSpace along the way.)

com.atlassian.confluence.macro.MacroExecutionException: JIRA project does not exist or you do not have permission to view it. Macro params are invalid

Errata, Typos, and other Comments

Standards bodies aren't perfect. Published standards can be expected to contain some errors. They will never get fixed unless people implementing the standards serve as editors. This document is a table containing observations made during the implementation of ISO 19123. I don't exactly know what to do with it when I'm done, but I'll burn that bridge when I come to it. Feel free to review, comment on, or add to the list I've made. I do expect this list to slowly accrete elements as the implementation effort goes forward.

Document Name


19123 Comment Table



A number of documents have already been produced in the course of this effort. These are collected here for easy reference.

Document Name


ISO 19123 Primer


Use of EMF


Early, Monolithic Implementation Document


Use Cases Document


Applications which support ODF

  • No labels