GeoTools

Monday, March 19, 2018

GeoTools 19.0 released

The GeoTools team is pleased to announce the release of GeoTools 19.0:

This is the first release of the 19.x series, now marked as stable and deemed suitable for production systems, while 18.x switches to maintenance mode and 17.x gets out of support.

This release is made in conjunction with GeoServer 2.13. This release includes a two major changes, both related to Java 9 compatibility, and a significant set of new features and improvements.

FactorRegistry Refactoring

In JDK 9 javax.imageio.spi.ServiceRegistry verifies that it is extended by JDK-classes only. For GeoTools' org.geotools.factory.FactoryRegistry that means that an exception is thrown, thus crashing GeoTools. To fix this, it was necessary to reimplement the ServiceRegistry functionality that is needed by GeoTools in FactoryRegistry.

For most users, this should not require any changes to make your project compatible. However, if you are accessing the FactorRegistry directly, there are some API changes that you will need to handle. For more details, refer to the FactoryRegistry Refactoring for Java 9 Compatibility proposal.

Java 9 Compatibility

More generally, GeoTools as a whole has been updated to be able to run on Java 9.

If your project depends on GeoTools 19.x, and you want to use it with Java 9, you will need to add the following flags to your JVM runtime arguments:

--add-modules=java.xml.bind --add-modules=java.activation

These add-modules runtime arguments enable the JAXB and Activation modules to the Java Runtime. The Java startup system has been changed, splitting the Java Runtime into modules for a smaller foot print. The jaxb and activation modules are no longer turned on by default.

The add-modules runtime argument is only used in Java 9. To allow your application to start in Java 8 or Java 9 include:

-XX:+IgnoreUnrecognizedVMOptions

GeoTools on Java 9 introduces a few functional changes:

XML pretty-print behaviour has changed, so that CDATA tags will now be on their own lines. These changes are only cosmetic - there are no functional changes to the XML.
Certain math functions are more precise on Java 9. This can result differences in the last digit of double values between Java 8 and Java 9. In particular, this has been observed when dealing with reprojected coordinates.
Small changes in horizontal offset have been observed in labels following lines.

GeoPackage performance improvements

GeoPackage reading and rendering performance improved significantly, up to two times faster on large datasets full extractions and 50% faster on small bounding box searches, bringing GeoPackage on par with PostGIS. We also have a Google spreadsheet with more details.

Shapefile remains king of full dataset extractions and the fastest data source for pure spatial driven queries.

Support for more PostGIS data types

The PostGIS data store now has simple support for HStore and JSON columns. HStore is returned as a Map, while JSON is read as a String. In both cases no special query support has been added for those types (but we'd be very happy if someone would work, or sponsor, that functionality too).

Better label position control in map rendering

When setting maxDisplacement on point/polygons the renderer used to search in a circular area around the designated label point. The new displacementMode vendor option allows to control the positioning by specifying the preferred cardinal positions, as a comma separated list.

Shapefile now supporting all Java object types on write

Shapefile used to throw exceptions if unrecognized object types were fed to it (basically, anything but geometries, strings, numbers and dates). From now on it will write unrecognized objects as strings instead.

Assorted improvements

A single bug fix was applied since 19-beta, fixing an issue with NetCDF data reading. See release notes for this and previous 19.x releases for more details (19.0 19-RC1 19-beta).