A metadata template for a Feature of arbitrary complexity.
Notes:
- that this documentation should be read in conjunction with the
FeatureAPI.
- the attributes described by this FeatureType and its ancestors define the complete
schema for a Feature
This interface answers the question: How do we represent features within GeoTools? Of course, the
most general answer would be: features can be any Java object. However, this is also the least
useful solution because it means that users of features have essentially no way to find out about
the meaning of features other than using Java introspection/reflection. This is too cumbersome
and is insufficient for the goal of creating a simple framework for manipulating and accessing
generic geographic data. The opposite approach might be to define a very constrained set of
possible attributes (that, for example, mirrored Java primitives and OGC simple geometries) and
only allow features of this type.
This interface takes a different approach: it defines a minimal ontology for representing a
feature and serves as a consistent framework for defining more constrained (and, therefore, often
more meaningful) feature types. A FeatureType
represents features as an object
that contains zero or more attribute objects, one of which will generally be a geometry, but no
geometry and multiple geometries are allowed, according to implementation. Note that instances of
implementations of this class are henceforth referred to as schemas.
With oneexceptions, the type of an attribute is considered to be its cannonical definition by the
FeatureType. For example, an attribute type might be a javax.sound.midi.Sequence
object, which contains a float
public field called PPQ. The fact that this
attribute exists is not known by the FeatureType
itself. If a caller asks this
FeatureType
for all of its attributes, the
FeatureType
will tell
the caller that it has an attribute of type javax.sound.midi.Sequence
, but not
that this attribute has a sub-attribute (field) called PPQ. It is the responsibility of the
callers to understand the objects it is asking for and manipulate them appropriately.
The exceptions is for:
- if the type stored in the
FeatureType
is a
org.geotools.datasource.Feature
type.
In this case, all information about sub-attributes are stored and passed to calling classes upon
request. The style of reference (XPath) is defined in and mediated by FeatureType
implementations.
Question: how does one determine the schema for the attribute defined as a FeatureType? I suspect
that FeatureType may be a valid AttributeType? (One needs this schema information before xpath
can be used to query the Feature value.
It is the responsibility of the implementing class to ensure that the FeatureType
is always in a valid state. This means that each attribute tuple must be fully initialized and
valid. The minimum valid FeatureType
is one with nulls for namespace, type, and
attributes; this is clearly a trivial case, since it is so constrained that it would not allow
for any feature construction. There are a few conventions of which implementers of this interface
must be aware in order to successfully manage a FeatureType
:
- Immutability
FeatureTypes must be implemented as immutable objects! All setting methods have been
removed from this interface, that functionality is now available in the mutable
FeatureTypeFactory
- Default Geometries
Note that the FeatureType contains a special methods for handling geometries. The primary
geometry retrieval methods are in Feature
because they may change over the life of
the feature, while the schema may not. In cases where there are more than one geometries it is up
to the implementor to determine which is the default geometry. getDefaultGeometry
may return null
if there are no geometries in the FeatureType, but if there is one
or more geometry then the method must return one of them, null
is never an
acceptable return value.
- XPath
XPath is the standard used to access all attributes (flat, nested, and multiple), via a single,
unified string. Using XPath to access attributes has the convenient side-benefit of making them
appear to be non-nested and non-multiple to callers with no awareness of XPath. This greatly
simplifies accessing and manipulating data. However, it does put extra burden on the implementers
of FeatureType
to understand and correctly implement XPath pointers. Note that the
Feature
object does not understand XPath at all and relies on implementors of this
interface to interpret XPath references. Fortunately, XPath is quite simple and has a clearly
written specification .
- Feature Creation
FeatureType also must provide methods for the creation of Features, as specified in
FeatureFactory. The creating FeatureType should check to see if the passed in objects validate
against its AttributeTypes, and if it does should return a new Feature.
Redesign Notes (feature-exp2)
The main design goal of this is to have FeatureType extend AttributeType. This allows us to
nesting of features much more nicely. We already are going in this direction, with the
FeatureAttributeType buried in DefaultAttribute. This is just making it explicit, so it works
with the complex objects GML can return a lot more sensible. So much of the work in this class is
figuring out what concepts are the same. Some stuff may need to be rethought a bit, as there are
a few subtle assumptions that we are working with flat files. We will revisit this when we
implement choice and multiplicity.
- got rid of deprecated getNamespace() method that returned a string, replaced it with a URI
return. This has been deprecated for a bit, and was done out of a desire to keep backwards
compatibility with 2.0, but that mission failed, so we're just moving on. This change will break
a few things, but is a good one, people just need to update their client code a bit.
- Deprecated getTypeName() to be getName(). They are the same thing, would be nice to get rid
of getTypeName, but it's used super extensively. Though perhaps we could consider keeping it as a
convenience, a bit more explicit, but it seems like overkill.
- Updated comments of the AttributeType operations that are inhierited to say what they mean
in the context of a FeatureType.
Redesign Notes (factory-hints)
The factory-hints design is finally coming through on the promiss of the great geotools factory
design. This design is actualy placing the factory system under application (rather than
'default') control, as such it is really showing every last place where we did not follow our
architecture.
Use Cases:
- Custom Feature:
Application spedcifies the use of a custom feature implementation. This is used so an application
interface is supported by each and every feature created.
- optiomized coordinate storage
LiteRenderer2 wants Shape2d specific CoordinateSequenceFactory used for all Geometry creation.
The point is to allow only the xy information to be retrieved, and in a format suitable for rapid
reprojection and coversion to a Java2D Shape. Any OpenGL (or Java3D) based renderer would also
run into this need.
The second use case is interesting in that LiteRenderer2 will be using the Datastore at the same
time as other threads that want the normal coordinate sequence. So this is a per Query hint.
Consequence: Since FeatureType is immutable, and CoordianteSequence is specified by the
GeometryFactory of the DefaultGeometryAttribute this implys that we have a per Query SchemaType.
It strikes me that this is a bad separation of concerns the "schema" should be exactly the same,
it is just the GeometryFactory that controls construction that is in the wrong spot. It should be
a hint, not attached to GeomtryAttributeType.