Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Module Maintainer:

jive, justin

Status:

in flux due to FM branch

Email Help:

Geotools-gt2-users@lists.sourceforge.net

Volunteer:

geotools-devel@lists.sourceforge.net

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

Stable 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)

Trunk 2.3.x

No significant changes

Feature Model

On the FM branch the following has occured:

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

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.

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.
  • No labels