Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

In a library as old as GeoTools we have managed to accumulate some technical debt over time; this is often work that was undone or


Children Display

For all of these the developers involve feel pretty bad; chances are they were out of time (or were on a branch with little feedback). So be kind and concentrate on the fixing.

Date Time handling

Problem: Mapping to Java Date is not specific enough
Solution: Map to java.sql classes
Scope: Update DataStore implementations; SQL DataStores should be easy

Data Input

Property Binding

Data Ouput










Data Input

Property Binding

Data Ouput







As you can see this fix still allows the use of Date and calendar; even though they are to vague to be useful in many situations. This fix simply
adds the option of the java.sql classes in order to let people be more specific. java.util.Date and java.util.Calendar are accepted as inputs
into the datastores, but when the feature type is datastore generated, a specific java.sql type should be used.

Please note that converstions should be defined between:

  • java.util.Date and java.sql.Time, java.sql.Date, java.sql.TimeStamp
  • java.util.Calendar and java.sql.Time, java.sql.Date, java.sql.TimeStamp

The use of converstions will let existing client code work with java.util.Date.

Upgrade Style to SLD 1.1

  1. (tick) Deprecate (or just remove) the Style event notification code; it is broken unused and a bad idea
  2. Upgrade GeoTools style classes to match SE 1.1 in place via a proposal
  3. Rename org.opengis.sld to org.opengis.stlye and update with the interfaces matching GeoTools definitions (ie SE 1.1)
    • Go over SE 1.1 specification updating javadocs and methods as needed
  4. Throw out GeoAPI package (it was working on graphic and is no longer needed)
  5. Release a milestone GeoAPI jar
  6. Change the GeoTools interfaces to extend the GeoAPI interfaces via a proposal (this is now possible with type narrowing!)

Remove Assumption of org.geotools.filter.Filter

  1. Remove assumption of style from
    • Style Implementation
    • SAX Parser
    • DOM Parser
    • XDO Parser
    • XMS-XSD Bindings
  2. Copy existing Filter Implementations, and remove AbstractFilter superclass
  3. Package up as a FilterFactoryImpl
  4. Use a hint to try out existing test cases with FilterFactoryImpl
  5. When encountering geotools FilterVisitor; rewrite as a geoapi FilterVisitor (use DuplicatingFilterVisitor as an example)
    • For PrePostFilterVisitorSQLGeneratorMagicSuperClassThing a new super class is already available FilterToSQL
  6. When encoutering a geotools Filter or Expression follow the update instructions to search and replace the GeoAPI counterpart
  7. Move org.geotools.filter interfaces to "legacy" module


Table of Contents

(tick) Clean out Catalog Experiment

  1. (tick) Create a new unsupported/catalog plugin with compile and test dependencies on data plugins
  2. (tick) Copy the catalog specific code from main and the data plugins into unsupported/catalog
  3. (error) Find the GeoServer configuration experiment splice it in as a replacement; be sure to keep the test cases
  4. (error) Force uDig trunk to use it


This issue is closed; the experiment is out of the way.

ISO Geometry Integration

Check out the bottom of ISO Geometry Research for the details ...

  1. Add a converter from ISO Geometry classes to Java Shape
    (and then stand back and watch renderer do its magic)
  2. Review the spatial function code and make sure it delegates to the ISO Geometry class as needed
  3. Set up a GeometryFactory interface
    • JTSGeometryFactory will produce JTS Geometry objects
    • ISOGeometryFactory will produce ISO Geometry objects
  4. (Note specific datastores may wrap the provided GeometryFactory in order to make good on their restrictions; letting client code know
    the GeometryFactory that works for the DataStore is a similar problem to adverising FilterCapabilities)

Hide Function Implementations

Many Function implementation classes are public; causing confusion when users go to look for how to do things.

  1. Change function implementations to be package visible; so test cases and factory instances can still work with them
  2. Any function that requires interaction is probably broken; many of the collection functions are broken in this manner

Review referencing factories and transform builders

  1. The old EPSG factories design (thread-safe through blocking synchronized statements) has been replaced by concurrent EPSG factories, thanks to Refraction work. However the old implementations have not yet been deleted.
  2. We need to review the classes, make sure that they can do the same work than the old implementation
  3. Delete the old ones.
  4. The math transform builders are new classes. They need to be reviewed as well.

This technical debt (ie waiting for martin to reveiwed has stalled out). As such we can probably just proceed to make the transition.

Document Rendering

The rendering system is not currently documented in the User Guide. I have gotten stuck based on the amount of functionality overloading of the MapLayer class. I would like to see ...

  1. Break MapLayer into parts (WMSMapLayer, FeatureMapLayer, RasterMapLayer) each with their own constructor
  2. Document the above with code examples
  3. The documentation does not explain the extent of creativity available with the SLD specification - as such the documentation should provide:
    • Java Code
    • XML Fragment
    • Picture of the result

Currently the best place to start is with the two "Lab" tutorials in the welcome section (ShapeLab and ImageLab).