Skip to: Site menu | Main content

GeoTools

The Open Source Java GIS Toolkit

Technical Debt Print

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

incomplete.

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
xs:dateTime java.sql.TimeStamp xs:dateTime
xs:date java.sql.Time xs:date
xs:time java.sql.Date xs:time
Data Input Property Binding Data Ouput
  java.util.Date xs:dateTime
  java.util.Calendar xs:datetime

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. 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 org.opengis.feature.style 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

Clean out Catalog Experiment

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

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. We need to review the classes, make sure that they can do the same work than the old implementation, and delete the old ones.
  2. The math transform builders are new classes. They need to be reviewed as well.