...

So FeatureSource would add the following methods:

• Set getFids() - return set of Feature IDs
• Feature getFeature( fid ) - grab a Feature from the Feature Source
• FeatureResults getFeatures( Envelope bbox ) - convience method for spatial query
• FeatureReader reader( Envelope bbox ) - convience method for spatial query
• Set getFids( Envelope bbox) - convinence, low memory, method for spatial query? (jmacgill)

And FeatureStore would add the following methods:

• void setFeature( fid, Feature ) - may be able to remove
• FeatureWriter writer( Envelope bbox ) - convience method for write access

And an extension to FeatureResults that handles writing .... FeatureSet (peer of result set):

• writer() - grab a writer for the FeatureSet

Expected Benifit

With the above api we can provide optimized implementations based on random file or database result set access while maintaining iterator based implementations.

...

Status Update - December 15th

Research

• RandomAccess
• Learning From Code: Fast Random Access
• Faster List Iterator with RandomAccess Interface

Isolating Resource Maintance

I have set up ResourceCollection and AbstractResourceCollection to be the following:

• iterator() - updated javadocs
• close( iterator ) - return resources used by the provided iterator
• purge() - close all open iterators

Use is as expected:

      Iterator iterator = collection.iterator();
      try {
          while( iterator.hasNext();){
               Feature feature = (Feature) iterator.hasNext();
               System.out.println( feature.getID() );
          }
      }
      finally {
          collection.close( iterator );
      }

...

As it stands I am subclassing AbstractResourceCollection to implement ....

• MemoryFeatureCollection

In addition the following will be set up:

• AbstractResourceList - support for resource based lists
• AbstractFeatureList - implementing FeatureList
• SubFeatureCollection - produced by featureCollection.subCollection( Filter ), chaining expected
• OrderedFeatureList - captures the "Natural" ordering of a FeatureCollection
• SortedFeatureList - produced by featureCollection.sort( SortBy ), chaining expected

I have "gasp" introduced two constants SortBy.NATURAL and SortBy.REVERSE that intended to reveal the "Natural Order" (or reverse it) of the datastore, this is the order that is most likely based on FID or a database Key, and thus most likely to be fast.

...

Aka stuff I won't be able to work on right now - but I would like to adjust FeatureState at a later time to:

• support custom attributes on FeatureCollection
• refer to their contents as "featureMembers" or "featureMember" can't remember which, and return the result as the FeatureList with natural ordering ...
• ensure attribute "boundedBy" is available with the cached value of Bounds
• ensure attribute "name" and "description" are also available and are allowed to be null

This would have consequences for the XML writing code, we have not seen FeatureCollections with attributes thus far, and we reference Feature.getBounds() directly, rather then relying on it to be picked up as an normal Attribtue.

...