Roadmap + geometry model switch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Roadmap + geometry model switch

Karel Maesen
Administrator
Hello List,

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.

Development on Geolatte-geom version 1.0 is currently nearing completion. It can be found at: https://github.com/GeoLatte/geolatte-geom

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.

Regards,

Karel Maesen        
_______________________________________________
hibernatespatial-users mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-users
Reply | Threaded
Open this post in threaded view
|

Re: [Hibernatespatial-dev] Roadmap + geometry model switch

Juan Marín Otero
Karel,

First of all, thank you very much for sharing the roadmap with the users of HS, I appreciate the information and it is good to know what's coming.
I have used HS 1.0 and 1.1 in several projects in production, currently I am leading the development of a major API that includes geospatial capabilities with HS 1.1. For me using JTS is important, I am aware of its shortcomings but coupled with Geotools or other geospatial library I have not missed any functionality. The options that you describe are nice though, and I would welcome change if it adds value which it sounds it does. If you can still provide interoperability with JTS that would make me feel more at ease. While these libraries offer different functionality they are many times used together, it is nice to use HS to handle storage and query of geometry predicates but JTS can then take from there if you need geospatial algorithms in your application (which I have needed on several occasions). I'll take a look at Geolatte-geom as I had not heard about it, sounds interesting.

Above all, keep up the good work, and congratulations on making this a core module for Hibernate, I think it will make it even more successful.


--
Juan Marín Otero
GIS Consultant

-------Visita mi blog en---------------------
http://guachintoneando.blogspot.com
---------------------------------------------------



On Mon, Sep 5, 2011 at 6:09 PM, Karel Maesen <[hidden email]> wrote:
Hello List,

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.

Development on Geolatte-geom version 1.0 is currently nearing completion. It can be found at: https://github.com/GeoLatte/geolatte-geom

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.

Regards,

Karel Maesen
_______________________________________________
Hibernatespatial-dev mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-dev





_______________________________________________
hibernatespatial-users mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-users
Reply | Threaded
Open this post in threaded view
|

Re: Roadmap + geometry model switch

Samuel Gendler
In reply to this post by Karel Maesen

On Mon, Sep 5, 2011 at 3:09 PM, Karel Maesen <[hidden email]> wrote:

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.

With some reasonable degree of interoperability between the two libraries, even if it requires a bit of engineering to accommodate, I'm not put out by your proposal at all.  I do use some JTS algorithms, but based on your commentary, it doesn't appear that I'd be losing access to them and I can live with code changes in order to access them. I'm taking you at your word regarding library compatibility, though, since i I have no knowledge of geolatte.  My only concern would be code maturity with geolatte - 1.0 has very different meanings in different projects and I often find that  projects with such low version numbers turn out to be lacking in essential functionality that then becomes a significant degree of work to implement myself, especially since sometimes those missing features may not fit terribly well into the architecture.  It's the nature of open-source, of course, and not necessarily a problem, but it certainly can increase the difficulty of using a product. That said, I'm generally in favour of anything that is likely to result in improved functionality over the long term (HS already meets my current needs, so as long as I don't lose functionality, I'm happy - at least until my needs expand in the 1st quarter of next year).

Just my $0.02.  I'm not a heavy user of HS, but I am dependent upon it at the moment.

--sam

 

Regards,

Karel Maesen
_______________________________________________
hibernatespatial-users mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-users


_______________________________________________
hibernatespatial-users mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-users
Reply | Threaded
Open this post in threaded view
|

Re: [Hibernatespatial-announce] Roadmap + geometry model switch

Tom Acree
In reply to this post by Karel Maesen
We use JTS for in-memory spatial operations and hibernate spatial for persistence.  We do rely on the underlying topological functionality of JTS to validate our digitizing and so on.  We also make use of the linear referencing support that is integrated only into hibernate-spatial.  I think as long as your approach is as a drop in replacement (an API over JTS I assume) then it shouldn't have much impact.  Also, moving the geometry libraries such as MLineString out of the hibernate-spatial project definitely makes sense.  I have seen you post to the JTS forum about supporting measure geometries and Martin didn't seem to have much interest at the time, so I think your idea is a good one.  

Tom

On Mon, Sep 5, 2011 at 6:09 PM, Karel Maesen <[hidden email]> wrote:
Hello List,

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.

Development on Geolatte-geom version 1.0 is currently nearing completion. It can be found at: https://github.com/GeoLatte/geolatte-geom

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.

Regards,

Karel Maesen
_______________________________________________
Hibernatespatial-announce mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-announce


_______________________________________________
hibernatespatial-users mailing list
[hidden email]
http://www.hibernatespatial.org/cgi-bin/mailman/listinfo/hibernatespatial-users