On 6 December 2017 at 07:59, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
Hi,
So here is how the MongoDB geospatial support looks like currently:
https://github.com/hibernate/hibernate-ogm/tree/master/mongodb/src/main/j...
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.
Fair enough; let's not do it then for now - if users want to use
something else they might tell us.
Sanne