GeoTools : Data Module

Module Maintainer:

Jody Garnett, Justin Deoliveira


(star) (star)

Email Help:


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

Ideas from this module were included in GeoAPI 2.0, this module is currently being revised in conjuction with GeoAPI 2.1 as part of the FM branch (see below).

Data Module Status


For the 2.2.x branch the data module remainted stable:

  • Implementation updated for ResourceCollection
  • Implementation provided for FeatureList (a random access api)


Broken out into a seperate module.

Feature Model

On the FM branch the following has occured:

  • seperated out into a distinct module
  • transition to GeoAPI feature model


Introduced DataAccess super class for DataStore and parametrized the FeatureSource/Collection/Reader/Writer interfaces to handle GeoAPI Feature as the general case, and SimpleFeature as a specialization.

Module Status

The data module is in flux as we transition to the FM branch, to protect yourself please
use the Query API (and Filter) rather then making direct use of FeatureReader. If you must
use FeatureReader

Outstanding Issues

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


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
    server as the creator of both Transaction and Locks.
  • Coverage support should be accessable in a manner similar to DataStore.