Skip to end of metadata
Go to start of metadata

Motivation:

DataStore allows access to SimpleFeature, we need to access Feature as well

Contact:

Gabriel Roldán, Jody Garnett

Tracker:

http://jira.codehaus.org/browse/GEOT-1701

Tagline:

(green star) introduce org.opengis.geoapi.Feature

This page represents the current plan; for discussion please check the tracker link above.

Description

This proposal:

  • introduces DataAccess as a super class of DataStore
  • traditional DataStore methods are maintained; often type narrowing a method in DataAccess
  • client code can be written against DataAccess for the general case; DataStore offers more specific that can make use of the SimpleFeature assumption
  • this proposal covers a naming convention / design stratagy that can be used for GridAccess as well

Additional information:

Status

Voting took place at today's IRC meeting over the approach #1(Generics + DataStore superclass), see Dry Run at DataAccess+Story for a summary.

Tasks

 

no progress

(tick)

done

(error)

impeded

(warning)

lack mandate/funds/time

(question)

volunteer needed

  1. (tick) Introduce DataAccess level classes
  2. (tick) Allow DataStore level classes to extend; patching up implementations as needed
  3. (tick) Update and test GeoServer
  4. (tick) Update and test uDig (and axios community edit tools)
  5. (tick) Update the user guide

API Changes

The API changes needed are minimal and respect the current interfaces and behaviour. The general strategy is to pull up the common methods from DataStore to a superclass and parametrize as per the Feature and FeatureType flavor they use.

BEFORE

AFTER

BEFORE

AFTER

Documentation Changes

  • No labels