I have had enough of generics being used in the core experience of new users; it makes the code complicated.

Description

The DataAccess super class for DataStore had a couple of options for introducing geoapi feature into the codebase; and chose to do so with the minimal number of clasess. To accomplish this the use of generics was used to allow those classes to be specific.

The Mess

Current relationship:

public interface DataAccess<T,F> {
  ...
  FeatureSource<T,F> getFeatureSource(Name)
  T getSchema(Name);
}
public interface DataStore extends DataAccess<SimpleFeatureType, SimpleFeature> {
  ...
}

Win? Well DataStore is "clean" and did not require more detail, but ... the basic example for geotools now looks like this:

It get's worse when you add FeatureCollection<SimpleFeatureType,SimpleFeature> into the mix...

Introduce SimpleFeatureSource

The other option for DataAccess super class for DataStore was to introduce super classes for FeatureSource and use type narrowing rather then generics:

That is water under the bridge (we cannot change now without breaking client code) - but the approach still needs to be used.

This does not represent any new methods; SimpleFeatureSource simply extends FeatureSource<SimpleFeatureType,SimpleFeature>; it represents the same API and does not break any client code. Some of the implementation code does have to change; but if they are extending geotools implementations the above patch takes care of it.

There is small patch for just the change up to this point: http://jira.codehaus.org/browse/GEOT-3051 patch simplefeaturesource.patch

Introduce SimpleFeatureCollection

The other half of the mess is all the generics around the use of FeatureCollection.

The approach is the same:

• introduce SimpleFeatureCollection extends FeatureCollection<SimpleFeatureType,SimpleFeature>
• Modify SimpleFeatureSource to return SimpleFeatureCollection
• Update the GeoTools implementations to refer to the new user interface (literally search and replace)

This is represented as simplefeaturecollection.patch - the creation of the patch went smoothly; in the few cases where a feature collection was actually generic I created a copy rather then take away a class usable by App schema.

• MaxFeaturesFeatureCollection copied to MaxSimpleFeatureCollection
• ...

Branch:

• contains both of the above patches
• based on email discussion SimpleFeatureIterator was added into the mix

Status

This proposal is made on April 25th, given the nature of the patch I would like to move quickly on it.

To facilitate review a branch is created here:

• http://svn.osgeo.org/geotools/branches/simple-features/

Voting has started:

• Andrea Aime +0 (concerned about schedule)
• Ben Caradoc-Davies +1
• Christian Mueller +0
• Ian Turton +1
• Justin Deoliveira +1
• Jody Garnett +1
• Michael Bedward +1
• Simone Giannecchini +0

Tasks

1. Introduce SimpleFeatureSource, SimpleFeatureCollection, SimpleFeatureIterator to trunk
   • SimpleFeatureStore may wish to have modifyFeature methods that take a String rather then AttributeDescriptor or Name
2. Update documentation examples/workbooks