Changing tracks on the GeoTools release train

The GeoTools release train has been burning through the stations and setting a rapid pace.

• Jan 21: GeoTools 11-beta released
• Feb 21: GeoTools 11-RC1 Released
• Feb 27: GeoTools 10.5 Released
• March 3: GeoTools 11-RC2 Scheduled
• March 18: GeoTools 11.0 Scheduled

This activity marks a great deal of research and development, and a track record of consistent planned delivery. The turn around time for stable releases is also an important measure for getting fixes out to developers. Everything thing looks great right?

Holding on for the Ride

There is a downside to this rapid pace. In February I had a chance to do a roll call of LocationTech projects using GeoTools. Here is what I found:

- GeoGit uses GeoTools 9.0

- GeoMesa uses GeoTools 9.5

- GeoScript python uses GeoTools 9.0

- GeoScript Java Script uses GeoTools 9.0

- GeoScript Scala uses GeoTools 9.3

- GeoScript Groovy uses GeoTools 11-SNAPSHOT

- GeoTrellis uses GeoTools 9.5

- uDig uses GeoTools 9.0-M1

Not only were these projects not using the latest they were back on GeoTools 9 series (which had reached its "End-of-Life" in August 2013).

The release train was proving too exciting and many projects had simply fallen off.

Switching Gears

In discussions on the developer email list it gradually came out that there was a tension between having access prompt access to a release (wonderful when you are waiting for a fix) and the testing burden associated with upgrading (falling off the ride).

From an RnD standpoint the 6 month cycle is working out well. GeoTools needed a way to hold on to stable releases longer without over taxing the developer community.

Here is the resulting change proposal: Extended Release Schedule

1. Drop back to releasing every other month
2. Extend the release schedule with a 6 month maintenance phase

This proposal has now been accepted. Both the GeoTools and GeoServer release schedule will be effected.

Planning GeoTools 11

GeoTools 11 is scheduled for release in March, and will see a release every second month as we alternate between stable and maintenance branches.

• GeoTools 11.0: March 2014 (Stable)
• GeoTools 11.1: May 2014
• GeoTools 11.2: July 2014
• GeoTools 11.3: October 2014 (Maintenance)
• GeoTools 11.4: December 2014
• GeoTools 11.5: February 2015

Additional point releases may of course be added at the bequest of a development team. If you fall in a gap between releases don't be afraid to speak up.

Planning GeoTools 10

GeoTools 10 will no longer be retired in March, and is now extended with additional 6 months of life as a "maintenance" branch.

• GeoTools 10.5: Feb 2014 (Stable)
• GeoTools 10.6: April 2014 (Maintenance)
• GeoTools 10.7: June 2014
• GeoTools 10.8: August 2014

FeatureCollection cleanup

The FeatureCollection cleanup proposal is now complete. The first batch of work went into the GeoTools 8.0 release, this second phase removes several methods from FeatureCollection. These methods were not widely implemented, and as a result not adopted by client code.
Upgrade instructions are available:

• Upgrade - GeoTools 9.0-SNAPSHOT User Guide

As part of this work Andrea provided an extensive review of the existing FeatureCollection implementations and a number of utility methods have been introduced to make working with features easier:

• DataUtilities.visit( FeatureCollection, FeatureVisitor, ProgerssListener )
• DataUtilities.bounds( FeatureCollection ) // Already existed
• DataUtilities.bounds( FeatureIterator )
• DataUtilities.count( FeatureCollection )
• DataUtilities.count( FeatureIterator )
• DataUtilities.close( Iterator )
• DataUtilities.first( SimpleFeatureCollection ): SimpleFeature
• DataUtilities.first( FeatureCollection ): F
• DataUtilities.list( FeatureCollection ): List  // Already existed 
• DataUtilities.list( FeatureCollection, int ): List
• DataUtilities.iterator( FeatureIterator ): Iterator // also Closable 
• DataUtilities.collectionCast( FeatureCollection ): Collection

For additional information, and an overview of the FeatureCollection implementations please review the detailed change proposal.
If you cannot make the transition today:

• A milestone 9.0-M0 release has been deployed to maven. 
• To switch your maven pom.xml over to 9.0-M0:

  <properties>
     <geotools.version>9.0-M0</geotools.version>
  </properties>
  ...
  <dependency>
    <groupId>org.geotools</groupId>
    <artifactId>gt-main</artifactId>
    <version>${geotools.version}</version>
  </dependency>
  

• You can use this milestone release as a rest area until you have time to upgrade.

One of the joys of working on a large stable project such as GeoTools is the gradual change of pace, and the careful planning that goes into keeping projects working together:

• The initial GeoTools 2.0 rewrite provided a clear FeatureResults API acting in a fashion similar to a JDBC ResultSet.
• GeoTools 2.1 introduced FeatureCollection as a superclass of FeatureResults, bringing in the java.util.Collection methods being removed today. This was motivated by an amusing Bring Back FeatureCollection rant from our founder James MacGill - well we tried James and it was a bad idea.
• The transition to Java 5 forced us to remove direct use of the java.util.Collection interface, however we kept the methods for backwards compatibility. It was too easy to introduce a resource leak with the Java 5 for-each syntax:

for( Feature feature : featureCollection ){

    System.out.println( feature.getID() );

}

• With todays change GeoTools programs are ready for the Java 7 try-with-resource syntax as shown below:

try( FeatureIterator iter=featureCollection.features() ){

   while( iter.hasNext() ){

        Feature feature = iter.next();

        System.out.println( feature.getID() );

   }

}

Reference:

• FeatureCollection cleanup (Change Proposal)
• GitHub Pull Request #44
• Issue Tracker GEOT-4181 

GeoTools 8

GeoTools is changing the version numbering system used setting the next release target as GeoTools 8.

This change "drops the 2" and brings GeoTools releases in line with traditional major.minor.patch  release numbering.

Dropping the 2

This also marks the final step towards calling the project "GeoTools" (rather than "GeoTools 2"). The GeoTools 1 project was started in 1996, and the GeoTools 2 project started up in 2002 as a ground up rewrite. By changing version numbers today we are committing to users of the GeoTools library that we can avoid a ground up rewrite in the future. The development team has been able to successfully grow the library and take on an amazing range of functionality in an incremental manner. We have every confidence in our development team, user community (and the polices we use to keep things running smoothly).

Details

For details on what has been done and the motivations behind it the change proposal is here:

• Skip GeoTools 3

For more information on the version numbers and what they mean the effected pages of the developers guide are:

• Versioning
• How to cut a release

Finally thanks to Jan De Moerloose from the Geomajas project who's questions on the user list lead to this change in policy.

8-SNAPSHOT

The maven snapshot repository is already hosting 8-SNAPSHOT as the result of nightly builds, and we should be in position to release a 8.0-M0 milestone release shortly.

If you were previously using 2.8-SNAPSHOT you can update your maven dependencies with the following:

    <properties>
        <geotools.version>8-SNAPSHOT</geotools.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.geotools</groupId>
            <artifactId>gt-main</artifactId>
            <version>${geotools.version}</version>
        </dependency>
        <dependency>
            <groupId>org.geotools</groupId>
            <artifactId>gt-epsg-hsql</artifactId>
            <version>${geotools.version}</version>
        </dependency>
    </dependencies>

End of GeoAPI involvement

The upcoming release of GeoTools represents a turning point for the GeoTools project - we are no longer taking part in GeoAPI.

Back in the dawn of time (well 2003) the GeoTools project started an experiment, and outreach program in the form of the GeoAPI project. Specifically this was an effort to collaborate with the deegree library (makes sense as both projects are LGPL and are working in the same domain).

Although not successful in its original goals of collaboration the GeoAPI project served as a great line of communication to the standards community. We would like to thank many of the amazing individuals who contributed their time, effort and expertise and extend an invitation for direct collaboration in the future.

A few things to keep in mind:

• We must emphasis that this decision does not break any client code
• The org.opengis interfaces will remain in the GeoTools library as part of the gt-opengis module
• As part of this change a lot of "deprecations" have already been cleaned up (representing areas of GeoAPI where the standard had passed out of fashion)
• GeoTools is committed to providing a stable API for your next (or current) Java project

The GeoAPI project is survived as an OGC Working group.

A faster, better GeoTools 2.7

GeoTools 2.7.x is current development branch (or "trunk"). Consider this a sneak peak of some of the ideas that are taking shape for the future.

First up we have speed. One of the common use-cases we have on the geotools-gt2-users email list is displaying a Map in a Java Swing application. Still it is nice to see something; especially when learning. With this in mind we have recast our initial introduction tutorials to be a bit more visual.

Out of the box GeoTools focus on providing a standard compliant SLD rendering engine. This engine is not specific to display - and actually never loads data into memory (it simply streams it off disk onto the screen).

In the interest of performance Andrea has donated a wrapper that will cache data in memory (storing it in a JTS spatial index).

File file = JFileDataStoreChooser.showOpenFile("shp", null);

FileDataStore store = FileDataStoreFinder.getDataStore(file);

FeatureSource featureSource = store.getFeatureSource();

CachingFeatureSource cache = new CachingFeatureSource(featureSource);

MapContext map = new DefaultMapContext();

map.setTitle("Using cached features");

map.addLayer(cache, null);

JMapFrame.showMap(map);

For more details please see the updated (and aptly named) Quickstart. This functionality has been back ported to 2.6.x and we are soliciting feedback (and test cases) from users.

Returning to 2.7 we have two great usability improvements:

• For the longest time we have had a Query interface and a DefaultQuery implementation. These have been combined making code examples just that much readable.
• We introduced the use of Generics to support application schema work. While we now have a happy team working on application schema; it did impact readably.
  Specifically FeatureCollection < SimpleFeatureType, SimpleFeature > gets tiring.
  Introducing SimpleFeatureCollection to the rescue.

With this in mind a couple of recent proposals have allowed us to write the following:

SimpleFeatureSource source = dataStore.getFeatureSource( typeName );

Query query = new Query( typeName, filter, attributes );

SimpleFeatureCollection features = source.getFeatures(query);

It is all good!

If you are using maven switch to 2.7-SNAPSHOT to try out these improvements today; we will issue a milestone release laster this month.