GeoTools 2.6.0 released

We are pleased to announce the long awaited release of GeoTools 2.6.0.

New features and improvements since GeoTools 2.5.x

Much of the effort in developing GeoTools 2.6 has been focussed on quality and performance but there are also a number of new features including :

• The gt-process module now makes it possible to integrate external libraries such as Sextante into GeoTools applications. It also now provides vector to raster conversion.
• The new gt-swing module with a basic collection of GUI components, many of which can be seen in use in our Quickstart and example applications.
• A cleaner set of modules with a number of previously unmaintained and redundant modules being removed.

Getting this release

You can download the binary, source and javadoc distributions as zip files from SourceForge.

The source code can be downloaded using your favourite Subversion client from: http://svn.osgeo.org/geotools/tags/2.6.0

Those of you using Maven as your build tool can simply change the version for GeoTools artifacts to 2.6.0 in your pom.xml.

Finally, you can browse the javadocs for this release online.

Enjoy !

GeoTools 2.5.8 Released

It's been a big week for GeoTools releases, with both 2.6-RC1 and 2.5.8 hitting the streets.

GeoTools 2.5.8 has seen a number of changes including:

• Improvements Shapefile locking
• Various fixes to ImageMosaic stability
• Support for JDBC aggregate functions

To try out the latest release, head on over to the downloads page.

GeoTools 2.6 has finally reached release candidacy, with the resolution
of a few key issues, including:

• Solving a crash when reading ECW files
• Updated the WCS 1.1 EMP model
• Resolved a reader exception caused by FastBBox filters
• The long-awaited return of the Javadoc build

For more information look to the 2.6.x branch page of the GeoTools wiki.

Cold cat kills Java 5

I have just upgraded to Snow Leopard - a few little visual tweaks is nothing to write home about; sounds like most of the effort is focused making the different parts of the operating system 64 bit. The original Leopard came with Java 6 but it was not the default ... for command line applications and applets (does anyone use those?) Java 5 was in use. You could hunt down Java 6 on your hard drive and configure tomcat or eclipse to use it if you liked.

But the upgrade also removed my copy of Java 5! These days even Sun wants to charge extra for any kind of Java 5 support; this is an issue for many Java Enterprise Edition users who are not in a position to upgrade due to corporate policy, version of websphere used etc...

This was my first time building GeoTools on mac with Java 6 - and it did not work (running out of memory during the build). Changing between 32 and 64 bit Java just changed what module the build process failed in. Pointing to a problem with the build tool call Maven; upgrading to 2.2.1 and giving it a lot more memory seems to have done the trick - but I am not really convinced.

If you would like to switch between Java versions:

1. Use spotlight to find the Java Preferences
   
   
2. Shuffle which version of Java is used
   
   

Interestingly I could *see* the older versions of Java on my hard drive - turns out they were all symbolic links to the same Java 6. The path /System/Library/Frameworks/JavaVM.framework/Versions contains a list of what is available.

Other than this only a few of my usual tools required upgrading:

• An update to Skitch (used to take the above screen snaps)


• Maven 2.2.1

GeoTools 2.5.7

I am pleased to announce the release of GeoTools 2.5.7, which is now available for download. While there are a number of new features included in this release, such as ArcSDE versioning and non-spatial table support and improvements to the performance and stability of filters and the next-generation JDBC datastores, there is more exciting news for this release. At least, it is for me.

This release marks LISAsoft's first official foray into the release processes of GeoTools. Assisted by veteran release managers Jody Garnett and Justin Deoliveira, and some very clear and well documented build processes, I only ran into a few troubles. For those of you that are familiar with the release process of these projects, you'll know where those troubles live; the cite testing for GeoServer. But patience prevailed and the release was put out late last week.

New Look

We are pleased to announce a new look for the GeoTools website hosted by OSGeo.

Thanks to Justin for setting up sphinx templates used to generate the website; this will allow fold source code examples into our documentation.

Justin was also kind enough to arrange a new GeoTools logo:

JDBC Next Generation

In recent weeks the GeoTools developers have been working hard on moving a new set of data stores code named "JDBC Next Generation" to the supported part of the GeoTools library. And we are happy to announce that the work is complete!

The new JDBC data stores provide support for a variety of database back ends such as PostGIS, Oracle, DB2, and H2. MySQL and SQL Server are also supported but still lack a bit of functionality in terms of support for spatial indexing. So if you are a developer who would like to see first class support for these databases, please join us as volunteers, new contributors are always welcome. A data store for Spatialite is currently in the works as well.

The new data stores come with a number of benefits. One is support for prepared statements, which while improving security against SQL injection attacks, also improves performance in some cases such as Oracle. Prepared statements also provide better date/time handling. Another improvement is support for JNDI connections which allows data stores to use database connections defined by the environment, such as a Tomcat web container or an Oracle application server.

There are also plenty of benefits for the developer as well. The new architecture promotes much more code reuse via the use of "dialects", an idea taken from the Hibernate architecture. The upshot of which is that implementing support for new databases is much simpler and involves implementing a much smaller set of classes. Test coverage with the new data stores is also much increased with a built in test framework that makes it easy to add new tests.

Some projects like GeoServer have already started shipping the new data stores as extensions. Which means they have already received some good testing. The uDig developers are also planning to integrate the new data stores at their up and coming code sprint.

Look for the new data stores in the next GeoTools release!

Thanks Martin

Martin Desruisseaux has recently stepped down, after devoting many years of service to the GeoTools community. Martin has been the long time module maintainer of our referencing module.

Martin joined GeoTools as part of a collaboration between his project (SeaGIS) and our founder James Macgill's applet based GeoTools 1.0 project. It was the collaboration between these two individuals that really kick started the GeoTools 2 project. Martin brought a rigorous scientific perspective to the project. He was also instrumental in GeoTools adopting OGC standards which initially served as as way to reduce the documentation burden of the library. The community gradually came to appreciate the value of the standards in providing common names and concepts, indeed a common reference point, for development work.

The Dynamic Desruisseaux-Macgill Duo's second experiment was the GeoAPI project, prompted by the need to come to grips with large XML based standards for Java developers and as an out reach to other libraries of the time such as Deegree and GeOxygen. GeoAPI has since taken on a life as its own: first being aligned with "GO-1" and then, through Martin's involvement, becoming a distinct GeoAPI working group.

We would like to sincerely thank Martin for his many, major contributions to GeoTools and we look forward to future collaborations as they arise.