Skip to end of metadata
Go to start of metadata


Try out Csv2Shp tutorial with someone new, now try it with someone new to Java


full name




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


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: 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
  • ...


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


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:

Voting has started:



no progress






lack mandate/funds/time


volunteer needed

  1. (tick) 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
  • No labels