Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

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.

...

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.

...

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.