GeoTools : Transitioning to FM

2.3.xwill contain a major change to the core of GeoTools - its model of what a Feature is. This will correct many difficulties in previous versions and greatly enhance the functionality of Geotools.

We are looking to fix two important things in geotools 2.3:

  • Q&A: Consistent use of Interface & Factory, geotools has "hard coded" way too much in the background, this gets in the way of a new breed of developers that is expecting our software to "just work" when dropped in a container or a new plugin system. We did the hard work of using a Factory, we need to do some Q&A before our users can reap the benifit.
  • Seperation of Concerns: We are sorting things out into three seperate responsibilities
    • DATA: We are improving the data model so it can go beyond "simple features"
    • QUERY: We are letting Expression work against any kind of data (from Feature to Record to Metadata to ...)
    • FUNCTIONALITY: Your code! Rendering! And anything in the "ext" directory (like graph)

      Expression is your friend

      Icon

      Do not write any code that access Feature directly, if at all possible use Expression.
      --* By using Expression your code is more flexable/powerful/useful to others
      --* By using Expression your code can work agains the new Feature Model in 2.3

Expected Changes

The following changes are to be expected:

  • Filter.getType is deprecated: there are now specific subclasses for AND, OR, NOT, OVERLAPS and so on...
  • Expression.getType is deprecated:
  • Feature has been replaced, for your code you can use SimpleFeature with a minimal of fuss and bother
  • FeatureType has been repalced, for you code you can use SimpleFeatureType with a minimal of fuss and bother

The following GeoAPI specifications are good enough to use:

  • Filter 1.0 specification: Expression / Filter / SortBy
  • ISO Feature specifications: Feature / Attribute / ComplexAttribute ... and SimpleFeature
  • Style 1.1 specification: StyleLayerDescriptor, Style, PointSymbolizer etc...

Any geotools interface left covering the same ground will be there for one of two reasons:

  • we are supporting some extra functionality (like label shields in styling)
  • backwards compatibility, like the deprecated Expression and Filter interfaces

Remember any deprecated code will be removed after one public release cycle!

Developer Notes

At the moment this section is a workspace for those of us poor souls stuck with the task of implementing the new geotools feauture model. It is our hope at some point that this will turn into a full blown transition document when people decide to shift to the new api.

SimpleFeature

The biggest change, is that the notion of a Feature in the new API is captured with the notion of a SimpleFeature in the new API. Feature in the new API is now somwhat more of an abstract concept, one capable of modelling complex content (ie. GML).

The following are restrictions placed on your data model to be able to use the SimpleFeatureInterface.

  1. Flat structure (ie. no attributes which are non-simple or complex). For instance, an attribute that is itself another feature.
  2. Non-qualified names (ie. no attribute name has a namespace prefix)
Naming

In the new model, types, attributes, etc.. are qualified names as opposed to a single string.

Old API:

interface Feature {
   Object getAttribute(String name);
 }

New API:

interface Feature {
   Object getAttribute(AttributeName name);
 }

The AttributeName interface is essentially QName from the Java XML API. It just wraps up a namespace uri and local name into one beasty. For those of us that dont care about qualified names we can construct one of these things as follows:

String name = "someAttribute";
AttributeName newName = new org.geotools.feature.AttributeName(name);