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/.

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

2.2.x

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

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

2.4.x

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

2.5.x

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

Comments

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.