A FeatureType describes what information is available in a Feature. I am going to explain this by analogy with something I hope you are already familiar with - Java.

GeoTools provides a simple interface for Feature:

• A Class describes an Object, the fields mentioned in the Class are available with actual values in the object.
• A FeatureType describes a Feature, the attributes mentioned in the FeatureType are available with actual values in the Feature.

Our feature model is pretty straight forward right now, we only support attributes (not methods or references).

Here is what this looks like in interface form:

interface FeatureType {
   URI getNamespace();
   String getTypeName();

   GeometryAttributeType getDefaultGeometry();
   
   int getAttributeCount();
   AttributeType getAttributeType( int index );
   AttributeType getAttributeType( String name );
   AttributeType[] getAttributeTypes();

   int find( AttributeType type);
   int find( String name );

   Feature duplicate( Feature feature);
   Feature create( Object[] values );
   Feature create( Object[] values, String id);

   boolean equals( Object other);
   int hasCode();
   ...
}

A couple of things I really want you to note about the above interface:

• The name for a FeatureType is considered to be both the namespace URI and the type name
• The order of the attribute types is considered significant (otherwise looking them up by index would not work)
• The name of an attribute type is considered significant (otherwise looking them up by index would not work)
• A FeatureType may have more than one geometry, the default geometry is to be considered if the user has not been explicit
• Feature is a Data Object; equals and hascode are defined - so two features with the same content and ID are to be considered the same. This is very important since the content is usually stored outside of Java (often on a disk or external service).

AttributeType

An AttributeType records the same kind of information that a Java field does - it keeps track of a name and the type of value allowed in that slot. In both Java and Features the order of the values is considered significant.

What about ISO 19107 Features

The central difference between the ISO 19107 idea of a Feature and the simple one we outlined above for GeoTools is the concept of attribute order. Two things are incomplete:

• Strictly speaking the order of the data should not matter. As long as the information is there and we can find it by name who cares what order it is in.
• The "name" and the "type" of information should be seperate. It would be good to be able to reuse the definition of an AttributeType (in much the same way as you can have two Date fields in a java class), it would also be nice if we could set up a FeatureType to contain an other FeatureType
• We would like to define operations (like methods) against our features

These ideas are important, we will complete this complete the picture when we move to the GeoAPI Feature interfaces (which are based on ISO 19107).

Here is what we will gain (still using the Java analogy):

• A Class provides methods that can be invoked on an object, a class may extend a super class in order to reuse the definitions of fields and methods. An abstract class may not be instantiated. Classes can be related several other ways, most noticeably is when a Class uses aggregation and has a field defined in terms of another Class. A Class can also enter into other relationships, usually captured as a collection.
• A FeatureType provides operations that can be invoked on a Feature, a FeatureType may extend a super FeatureType in order to reuse the definitions of attributes, associations and operations. An abstract FeatureType may not be instantiated. FeatureTypes can be associated in several other ways, most noticeably when a FeatureType uses aggregation and has a attribute defined in terms of another FeatureType. A FeatureType can also enter into other associations, usually captures as a FeatureCollection.

Why is this so complicated?

The concept of FeatureType, associations, operations and so on - are actually a normal "dynamic type system". In map making cartographers have been using the same tools of classification that we use in computer science (types, subtypes, collections, associations and so on).

The domain for GIS is to be considered rich, and our target audience demands the same kinds of tools to capture the complexity in the world that we are used to using for our object oriented programming languages.

And guess what; they have been doing this since the 1500s.