[Hibernatespatial-announce] Roadmap + geometry model switch
A quick update on where we are going with Hibernate Spatial.
As you probably know, I'm moving Hibernate Spatial as a module into Hibernate-core proper. This will mean that spatial data types will (finally) have the same level of support as any other datatype in Hibernate. Some other advantages are:
- simplified configuration
- no longer compatibility issues between Hibernate and HS versions.
The integration is scheduled for the Hibernate 4.1 release. To support Hibernate 4.0, I'll release a final independent version of Hibernate Spatial. This release will resemble very closely the module that will be in Hibernate 4.1. Note that this is a major rewrite from HS 1.x.
The move to Hibernate-core has some other consequences:
- the new version number will jump to 4.0 (to align better with Hibernate version numbering)
- the source code is hosted on Github. For now you can find it at https://github.com/maesenka/hibernate-core (branch HH-6509). This will be merged in the GitHub Hibernate-core repo once it is ready.
- After the H4.1 release the HS website, JIRA and source repositories will only be used for the maintenance of the HS 1.x and 4.0 versions (urgent bug-fixes, documentation).
I think it is also time for a rethink on the role of JTS. The major problems with JTS are:
- it doesn't support measured geometries (already supported by Hibernate Spatial through an extension on JTS)
- it only supports OGC spec version 1.1, and there is no indication that the library will evolve to later versions or to ISO/IEC 13249-3 (SQL/MM Spatial). The later specs also introduce more complicated geometry subtypes.
- JTS Geometries are mutable although geometries are more naturally considered as value types
- it is essentially meant for geometries in 2D Cartesian coordinate spaces. Using it with geodetic data in angular units often creates problems (is e.g. the length property valid? Does getX() return Latitude or Longitude?)
My understanding is that Martin Davis, the lead developer of JTS, sees JTS primarily as a library of geospatial algorithms. His focus is on the implementation of these algorithms, and less on issues like compliance to standards or persisting to databases. But these last aspects are crucial to Hibernate Spatial.
I propose therefore to replace JTS with a new Geometry library: the Geolatte-geom library. GeoLatte is a project that aims to develop a set of geospatial java libraries targeted at enterprise systems or applications that are _not_ traditional GIS. Geolatte-geom is intended as a drop-in replacement for the Java Topology Suite (JTS) geometry model. It is fully interoperable with JTS, and uses JTS behind the covers for many of its operations, but offers the following additional features:
- immutable data structures (Geometries are value objects).
- support for 3D, 2DM and 3DM geometries
- support for several dialects of WKT/WKB (Postgis, Sql Server, SFS 1.21)
- pluggable, extendable Geometry operations
- CRS-awareness (knowledge of coordinate reference system (projected/geodetic, angular units of metres)
- Configurable which accessor (getX() / getY()) corresponds to which coordinate system axis
Geolatte-geom does not duplicate JTS. It aims to marry the strenghts of JTS (geospatial algorithms) to better support for non-2D and/or non-cartesian geometries, and better standards compliance.
Because Geolatte-geom is interoperable with JTS ( == can be easily and efficiently converted to JTS Geometry), it is possible to continue supporting JTS directly. So users can choose between JTS and Geolatte-geom for their domain model.
Any thoughts on these developments? What geometry model would you choose for your application? Do you actually need JTS? Or do you use it because it is what Hibernate Spatial uses (rephrased: you chose Hibernate Spatial because it persists JTS? Or the other way around)? Feedback will be greatly appreciated.