• Motivation: DataStore allows access to SimpleFeature, we need to access Feature as well

• Contact: Gabriel Roldán, Jody Garnett

• Tracker: https://osgeo-org.atlassian.net/browse/GEOT-1701

• Tagline: Introduce org.opengis.geoapi.Feature

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:

• Data Access Design Goals
• Dry Run at DataAccess Story

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

• Andrea Aime 0
• Ian Turton
• Justin Deoliveira +1
• Jody Garnett +1
• Martin Desruisseaux +1
• Simone Giannecchini +1

This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success

        | :white_check_mark: | :no_entry: | :warning:               | :negative_squared_cross_mark: |

------------|--------------------|------------|-------------------------|-------------------------------| no progress | done | impeded | lack mandate/funds/time | volunteer needed |

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

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.

Class	Diagram
DataStore
FeatureSource
FeatureStore
FeatureLocking

/** @since 2.0 */
interface DataStore{
   void createSchema(SimpleFeatureType featureType);
   SimpleFeatureType getSchema(String typeName) throws IOException;
   FeatureSource getFeatureSource(String typeName);
   ...
}

/** @since 2.5 */
interface DataAccess<T extends FeatureType, F extends Feature>{
    List<Name> getNames();
    void createSchema(T featureType);
    T getSchema(Name name);
    FeatureSource<T,F> getFeatureSource(Name typeName);
    ....
}
/** @since 2.0 */
interface DataStore extends DataAccess<SimpleFeatureType, SimpleFeature>{
   void createSchema(SimpleFeatureType featureType);
   /** @since 2.0 */
   SimpleFeatureType getSchema(String typeName) throws IOException;
   /** @since 2.5 */
   SimpleFeatureType getSchema(Name typeName) throws IOException;
   FeatureSource<SimpleFeatureType,SimpleFeature> getFeatureSource(String typeName);
   ...
}

/** @since 2.0 */
public interface FeatureSource {
   FeatureCollection getFeatures(Query query);
   SimpleFeatureType getSchema();
   DataStore getDataStore();
}

/** @since 2.0 */
public interface FeatureSource<T extends FeatureType, F extends Feature> {
   FeatureCollection<T,F> getFeatures(Query query);
   T getSchema();
   DataAccess<T, F> getDataStore();
}

• Developers Guide will need a section on adding a DataAccess api that has the right feel
• Data Module
• Upgrade to 2.5
• demo/example/
• User Guide