Hi, So here is how the MongoDB geospatial support looks like currently: https://github.com/hibernate/hibernate-ogm/tree/master/mongodb/src/main/java/org/hibernate/ogm/datastore/mongodb/type
So basically, moving to JTS would have the following benefits and drawbacks: + we can remove these types from OGM + we are consistent with the current spatial support of ORM (note that there is also work on spatial4j which is different from JTS and apparently they are talking about a JTS 2 API that would be different from the current API) + you have the whole JTS API at hand - the JTS API for creating shapes is not very user friendly: you have to define a precision model and a SRID - which are of no use for MongoDB, you have to pass an array of points to create a polygon and things like that - it sure works but it's not very user friendly and looks like a 1990s API - we end up adding a 800 kB jar for something really simple: I don't really think people will use the JTS advanced features in conjunction with MongoDB - we will have to add a helper API for allowing the users to convert easily a shape to a BSON document (currently, it's included in the Geo* classes) - we won't be able to support GeometryCollection as the only thing available in the JTS API is the list of coordinates of the shapes, you can't access the types of the shapes (which are needed for the GeoJSON version of GeometryCollection) - full disclosure: I haven't added GeometryCollection support yet in what I did (I created an issue suitable for new contributors to have an easy task suitable for a potential contributor) So all in all, I'm not convinced it's such a good move. -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev