GeoTools : 2007 Q2

2007 Q1

2007 Q2

2007 Q3

This report is written in the second quarter of 2007, and outlines community development and research goals.

Users Community

GeoTools has kept up the the production of monthly milestone releases. The publication of milestone releases makes progress visible and accessible to the user community. We have not been sending announcements out beyond the user list, as milestone releases are strictly for "early access".


We are nearing the end game plan for GeoTools 2.4.0. To make the cut a module will need to be brought up to supported status (with associated test coverage, module matrix page, and user documentation). Please check the Module Matrix page (and development policies) to see if the modules you are interested in are ready for release.

Modules that are not included in the official GeoTools 2.4.0 release will still be available; but please treat them with due caution. If one of the modules you require is not going to be ready this release, please consider talking to the module maintainer - options range from volunteering your own time to setting up formal support.

User Guide

The User Guide continues to pick up content, including a nice overview of the core library. New this release are "you are here" maps as you navigate between chapters. Thanks to everyone for all the feedback.


We are pleased that Martin's report to the OGC working group is ready; we will hear back from the OGC working group this quarter and the results will dictate the specific contents of GeoAPI 2.1.0 and GeoAPI 3.0.0.

This quarter we are playing host to a range of Summer of Code 2007 students under the direction of the OSGeo foundation. We are pleased to welcome an additional project this quarter - TOPP has undertaken to bring ISO Feature support into uDig.

Ongoing work related to ISO metadata, ISO Geometry is proceeding apace.

The above diagram is color coded based on project and developer activity (the amount of colour indicates the rate of change).

Development Policies

Our development policy changes have started to take root, our GeoTools change proposal, Supporting your module policies are having a real effect on how we operate. The greatest immediate benefit is the generation of user documentation, and the visibility afforded by the module matrix page.

There is one planned development policy change:

  • When a contributor agreement is available (after negotiations with OSGeo) we will require each developer to sign something.

Accepted Change Proposals

The following change proposals have been accepted:

Research Goals

The [Summer of Code} students reflect our research priorities now; the core GeoTools community seems to be working on making good on our existing ambitions.

Research Policies

The GeoTools project has a single policy on starting up research topics, Creating your own Module. The procedure covers the process used to create a new "unsupported" module. The use of "unsupported" as a community space is a vast improvement on our earlier policy of allowing branches, and creating throw away spikes.

Known Deadlines

In the above diagram the following known deadlines are underlined.

Here are the dates as near as have been made public:

  • June 11th: GeoAPI Working Group Report
  • July 9th: GeoAPI Working Group Meeting
  • July: ISO Feature to start landing on trunk

Outstanding Problems

The following problems are listed as design problems that should be addressed. Often these problems are holding up existing paid work, but due to the amount of collaboration involved lack specific funding.

  • OSGeo Incubation process is stalled pending legal feedback (it is in progress but it has not yet completed)
  • We missed reviewing several critical GeoAPI concepts: TypeName vs Generic Name and their relationship with Schema, Record and RecordType
  • GeoTools FilterCapabilities - We have switch over to use GeoAPI Filter interfaces. The interface "Function" does not list the number of required parameters; instead that information is captured as part of the FilterCapabilities information (which we currently do not use).
  • MapContext is an API provided by the rendering module; this abstraction is starting to fragment. The best example is WMSMapLayer being created in a demo module (we should define a formal interface and stick to it)
  • Communication with other projects such as OpenJUMP, DeeGree and gvSig is poor, often we are falling over licensing restrictions and the usual lack of time.


planning.png (image/png)