GeoTools : Feature Model FeatureCollection Design

The OGC overview document clearly indicates that Collections are a "derived" Feature from their contents. Without contents a Collection cannot exist. In addition FeatureCollections are actual Features with FeatureTypes in their own right. Because of this we need to be sure that the FeatureType for a FeatureCollection contains a way to describe the FeatureType of the contained Features.

FeatureCollection FeatureType contains a reference to allowable child FeatureType
FeatureCollection FeatureType contains a reference to several allowable FeatureTypes
Children represented as a "normal" attribute (of type features) with multiplicity

There is an attraction to representing child featues as a normal attribute (called "featureMembers"). It allows us to capture all the uses cases, it gives XPath generation a consistent model to work from (all attributes all the time with no special case for featureMembers). It is however impossible to tell the difference between this required featureMembers attribute and any other attribute of type FeatureType with a multiplicity. That may or may not be a good thing?

For now lets go with explicit modeling power at the cost of making XPath a little bit harder.

It is unclear if we need to separately define FeatureCollectionType (that extends FeatureType).

The OGC overview document also defines the FeatureCollection as having references to its children.

Parent references to child features. Often this is done by way of an expression that can generate the references (such as a

Children contain a back pointer to their containing Feature. This limits the modeling ability of a the system, as it prevents a child from being in more then one collection. And begs the question of why attribtues that are features do not have a back reference to their containing Feature (even though it may not be a FeatureCollection).

It should be pointed out that all known implementations have the reference reversed (Features contain a reference to their Parent FeatureCollection). This is probably a convience, but it does limit out modeling power (we cannot model a Feature as being part of more then one collection). Even in GML this is possible by use of references.

Design Decision:

interface FeatureType extends Type {
interface FeatureCollectionType extends FeatureType {
  FeatureType getChildFeatureType(); // featureMember/featureMembers restriction
interface Feature {
  FeatureType getType();
interface FeatureCollection extends Feature {
  FeatureCollectionType getType();
  Iterator<Feature> features(); // featureMember/featureMembers access
  close( Iterator<Feature> );

(warning) I have included the ability to "close" iterators (in case they have OS resouces they need to return), the practice was taken from JDO and is used by GeoTools.

(warning) Note this represents GML "infecting" our modeling system, we are explicitly capturing featureMembers with the features() method. Any XPath system will have to try a search for featureMember/*,featureMembers