[hibernate-dev] Geospatial types/queries and OGM

[Sanne Grinovero]

On 6 December 2017 at 07:59, Guillaume Smet <guillaume.smet at 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/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.

Fair enough; let's not do it then for now - if users want to use
something else they might tell us.

Sanne