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
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.
On the FM branch the following has occured:
- seperated out into a distinct module
- transition to GeoAPI feature model
Introduced FeatureAccess 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.
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
Outstanding Issuescom.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.