GeoTools : 6 Difference between getSchema and getFeatureType

Q: What is the difference between DataStore.getSchema and Feature.getFeatureType

This question was asked by Davis Ford (thanks!), here is what he is talking about:
* AbstractDataStore.getSchema( String typeName )
* Feature.getFeatureType()

First we have a small warning....

Use of AbstractDataStore

Icon

NOTE: AbstratDataStore is not to be considered as "API", your code should be limited to
those methods available in the DataStore interface. Often we will try something out in
AbstractDataStore to see if people like it. And when people are happy we can move things
over to the DataStore api.

Examples:

  • DataStore.getView( Query ) was prototyped and then adopted.
  • DataStore.getFeatureTypeInfo() was prototyped and then removed

So we can rephrase the question in terms of the difference between:
* DataStore.getSchema( String typeName )
* Feature.getFeatureType()

Mr Ford wrote:

the data store can return more than one schema based on the string input. however, if i implement the feature interface, and there is only a single feature the data store returns -- the implementation for both would seem to be the same.

Which is correct, to recap:

  • if you have a DataStore like a shapefile that only serves up one kind of content these will both be the same (this is "just an accident" because there is only one kind of content).
  • if you have a DataStore like a database, you will need to ask for the list of available stuff by name (aka typeName), and then use getSchema( TypeName )

The features served up will "be of" the expected FeatureType for that typeName; and for AbstractDataStore the FeatureCollection that holds them will be of type AbstractFeatureCollectionType.
This is the second point.

Q: What is the difference between FeatureCollection.getSchema() and FeatureCollection.getFeatureType()

Yes - there are actually two different FeatureTypes involved (even in the most simple case):

  1. The type of the FeatureCollections provided by the features(), aka always something that extends AbstractFeatureCollectionType
  2. The type of the contents of the FeatureCollection, the individual feature members in the collection (aka what getSchema( typeName ) told ya)

This distinction is clear on 2.2, and is improved again in the "Feature Model" work targeted for 2.3 (and used in the community schema branch right now).

  • FeatureCollection.getSchema() - FeatureType of the members
  • FeatureCollection.getFeatureType() - feature type of the collection
  • Feature.getFeatureType() - feature type of the feature

Since a FeatureCollection "is a" Feature you can see that the use of getFeatureType() above is consistent.

Why schema is available at the DataStore level

Mr Davis also asks:

does it seem plausible that the data store should provide the implementation and the feature should get this reference to the constructed FeatureType?

Yes, the schema of "what is available" needs to be known to client code before they even
bother connecting to the actual individual features. Often this is used to process SLD rules
before asking for content, or make a user interface table with the correct headers.

How can this get better?

A problem with the existing datastore api is that FeatureType is the only kind of "metadata"
that you can access "offline" in this manner, we need to provide better support (and we will
as need arises). Using the current API you cannot figure out what the expected
FeatureCollectionType will be without asking for contents.

There is also a limitation with the use of TypeName, when we start to get into interesting content
the use of QName (aka namespace plus typeName) becomes necessary.

These are some of the issues that have been addressed by the community schema work, stay tuned
(or help out) !