Here is what I would like to check:
- IP Check, do we have the correct header, is there any IP issue to consider
- Doc Check, does each class have a class javadoc. Check package html to see if it
is up to date.
* Geotools - OpenSource mapping toolkit
* (C) 2002-2006, Geotools Project Managment Committee (PMC)
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation;
* version 2.1 of the License.
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
- 2002-2005 changed to 2002-2006
- Geotools2 changed to GeoTools
The GeoTools project is made up of three parts:
GeoTools is organized around the concept of "module maintainer", where
each module has one or two maintainers that are responsible for keeping
it in shape and ready for release. These IP checks should really
be the domain of each module maintainer, where they have not had time
to take part it will still be there responsibilty to fix (or accept
patches for) any issues found.
- The "Core" GeoTools library, defining a implementations and
a layered architecture around ISO and OGC specifications. Where
approved GeoAPI interfaces are available they are used, however we do
provide some of our own interfaces. The library on its own provides no
functionality, simply definining a framework for plugins to work
together. GeoTools is often deployed with own a few of the layers
needed for the task at hand.
- The GeoTools "Plugins" are each individual modules that provide
functionality for the GeoTools library. As an example a plugin exists
for teaching the library about a CRS Authroty, or how to talk to each
- The GeoTools "Extentions" are additional functionality built on
top of the geotools library, often built around non standardized
conepts. You will find examples like an SLD "color brewer" for creating
approriate styles, or a graph module supporting limitied topology
The following modules define the scope of the library,
additaional interfaces not yet available through GeoAPI, test data etc::
The following modules contain default implementations and structure the library into plugins:
- api - interfaces based on specifications, for which no GeoAPI interface is available
- coverage - focus on the converage specifications
- sample-data - sample data used by testcases through out the library
- referencing - captures implementations for CRS and referencing
- main - defines default implementations
- main - data - implementations for datastore
- main - jdbc - implementations for jdbc datastores
- main - xml - implementations for several XML parsers
Provides a catalog capable of managing resources and their associated connections.
This code started out as part of the uDig project (LGPL) and has been ported for GeoTools
2.2.x, we hope to eventually back port the "adaptive renderer" which is built on the
idea of resource handles captured here.
There is lots of great work to be done in this package, here are just a few ideas:
- Allow the file handle to resolve to an ISO Metadata class (rather then just GeoResourceInfo - which is based on dublin core).
- Allow the use of Filter to query against GeoResourceInfo
- Support the capture of additional information such as associations from OWS Catalog 2 specification
Catalog - updated header
CatalogInfo- updated header
GeoResource- updated header
GeoResourceInfo- updated header
Resolve- updated header
ResolveChangeEvent- updated header
ResolveChangeListener- updated header
ResolveDelta- updated header
ResolveDeltaVisitor- updated header
Service- updated header
ServiceFactory- updated header
ServiceFinder- updated header
SerivceInfo- updated header
Each file included a class javadoc, a package package html was added
Data access api providing a common interface to several file formats and data sources.
This code was revised for the GeoServer 1.2 release as part of GeoTools 2.0, design documentation and research for this effort
is avaiable at http://vwfs.refractions.net/.
There are several areas in which the data module can be improved:
- support for "joins" has been attempted several times, most
recently on the "complex-features" branch, a standards compatible way
of defining joins can be seen as part of the Catalog 2 specification in
which a Query may hold several filters against different metadata.
Starting at the other end of the problem
- the "community schema" effort concentrates on mapping the joins needed to fufill a predefined XML schema.
- The exact mechaism for Locking can be improved based on the
workflow documented in GeoAPI currently (in which LockResults are
returned at the end of a Commit)
- Repository can either be subsumed by Catalog, or can remain as a
front end for cross datastore opperations (such as client side joins
and unlocks). It would make sense to have Repository serve as the
creator of both Transaction and Locks.
- Coverage support should be accessable in a manner similar to DataStore.
- All files required their header updated
- Each file does indeed have a class javadoc
- package html provided as part of module mail
Defines additional API for handling resource based iterators (ie they
must be closed). The idea is from the hibernate framework, although it
was just mentioned in IRC meetings, no API was copied directly.
Used to define interfaces for an EMF Style event model (as oppsed to
java beans). This style of event model is much better equiped for
handling tree structures such as a SLD. Originally based on uDig
codebase, same source as that used for Catalog events. Chances are we
can reduce this to one set of event classes.
Defines the interfaces for the GeoTools 2 feature model.
No package html.
Responsible for representing the Filter 1.1 filter and sortBy syntax. Right
now these interfaces implement the GeoAPI interfaces, and they will be
removed next major release.
Responsible for representing the Filter 1.1 expression syntax.
Right now these interfaces implement the GeoAPI interfaces, and they
will be removed next major release.
No package html.
Module main - data
Module main - jdbc
Module main - xml