See datanucleus/datanucleus-rdbms#142

Even though I would think changing the return type from void to boolean would be a backwards compatible change Java seems to take offense to it:

Caused by: java.lang.NoSuchMethodError: 'void org.datanucleus.store.types.geospatial.rdbms.adapter.PostGISAdapter.addSQLTypeForJDBCType(org.datanucleus.store.schema.StoreSchemaHandler, org.datanucleus.store.connection.ManagedConnection, short, org.datanucleus.store.rdbms.schema.SQLTypeInfo, boolean)'
	at org.datanucleus.store.types.geospatial.rdbms.adapter.PostGISAdapter.initialiseTypes(PostGISAdapter.java:67) ~[org.datanucleus.store.types.geospatial_5.2.0.release.jar:?]
	at org.datanucleus.store.rdbms.adapter.BaseDatastoreAdapter.initialise(BaseDatastoreAdapter.java:571) ~[org.datanucleus.store.rdbms_5.2.9.jar:?]
	at org.datanucleus.store.rdbms.RDBMSStoreManager.<init>(RDBMSStoreManager.java:301) ~[org.datanucleus.store.rdbms_5.2.9.jar:?]
	... 68 more

The return type was changed in this commit datanucleus/datanucleus-rdbms@3fc4e94 in datanucleus-rdbms. Which breaks Geospatial 5.2.0. I've verified this issue by rebuilding datanucleus-geospatial using DN 5.2.10 as dependency. This fixes the issue.

We currently only allow the static method Spatial.bboxTest(Geometry, Geometry) i.e static invocation. It would make sense to allow

geometry1.bboxTest(geometry2);

In PostGISAdapter we enforce a two step process, as per the docs for PostGIS 1.x ... namely create a normal table, then call AddGeometryColumn on each spatial column to add them. With PostGIS v2.0+ this is apparently not necessary. See http://postgis.net/docs/manual-2.0/using_postgis_dbmanagement.html#Create_Spatial_Table

So we can enable it and mark that as supported.

Also boundary, crosses, relate, isEmpty, isRing, isSimple

MySQL, PostgreSQL (PostGIS), and Oracle each have geospatial methods that should be moved.

To quote the PostGIS docs :

The basis for the PostGIS geometry type is a plane.

This is supported.
It also says

The basis for the PostGIS geography type is a sphere. The shortest path between two points on the sphere is a great circle arc. That means that calculations on geographies (areas, distances, lengths, intersections, etc) must be calculated on the sphere, using more complicated mathematics. For more accurate measurements, the calculations must take the actual spheroidal shape of the world into account.

To implement this, whoever requires it would need to add GeographyColumnMapping in pg2postgis and in jts2postgis (and its subclasses), and then add the requisite entries to the XXXDatastoreAdapter classes.

See https://www.postgis.net/workshops/postgis-intro/geography.html

See http://www.h2gis.org/docs/1.3.1/home/

Currently, while we support all PostGis types via the static methods "Spatial.XXX", we do not support them all via the normal java method invocation. Would be nice to have full coverage.

Maven central has groupId="org.locationtech" with v1.1.5+ available.
See https://projects.eclipse.org/projects/locationtech.jts - an Eclipse project.
Note that they do not currently publish "jts-ora" so impossible to switch as yet.
See locationtech/jts#78 and then the later locationtech/jts#439

We currently provide Spatial.asBinary(Geometry) but should provide the object method also

The helper facilities were only developed for RDBMS (and JDO) and so should only take in that argument type.

A datastore such as MySQL can support multiple geospatial types. The likelihood is that a user will only have some of these types in the CLASSPATH at runtime, based on which ones they want to run. We should avoid trying to load all types up, after a simple check for existence.