Spatial 0.27.0-neo4j-4.0.3

Since this library was originally written in 2010 when Neo4j was still releasing early 1.x versions,
it made use of internal Java API's that were deprecated over the years, some as early as Neo4j 2.x.
When Neo4j 4.0 was released, it entirely removed a number of deprecated API's, and completely changed
the Transaction API.
This meant that the spatial library needed a major refactoring to work with Neo4j 4.x:

• The library previously depended on outer and inner transactions, so code that was called
  within a transaction (like procedures) could be common with code that was not (Java API).
  The removal of this support required that all internal API's needed to include parameters
  for the current transaction, and only the specific surface designed for embedded use not.
• The library made use of Lucene based explicit indexes in many places.
  The removal of support for explicit indexes required new solutions in sevaral places:
  • The OSMImporter used instead normal Neo4j schema indexes (introduced in 2.0), but these
    can only be created in separate index transactions. Due to the new transaction model this
    required stopping the import transaction, starting an index transaction, and then restarting
    the import transaction. All of this is incompatible with procedures, which already have
    an incoming, non-stoppable transaction. The solution was to run the actual import in another
    thread, retaining the original batch-processing capabilities, but requiring modifying the
    security model of the procedure context.
  • The ExplicitIndexBackedPointIndex needed to be modified to instead use a schema index.
    This required similar tricks as employed in the OSMImporter.
• Neo4j 4.0 runs only in Java 11, and GeoTools only supported up to Java 1.8 until recently.
  This required an upgrade to the GeoTools and JTS libraries to version 24.2.
  This in turn required a re-write of the Neo4jDataStore interface since the older API had
  long been deprecated, and was entirely unavailable in newer versions.

Consequences of this port:

• The large number of changes mean that the 0.27.0 version should be considered very alpha.
• Many API's have changed and client code might need to be adapted to take the changes into account.
• The new GeoServer API is entirely untested, besides the existing unit and integration tests.
• The need to manage threads and create schema indexes results in the procedures requiring
  unrestricted access to internal API's of Neo4j.

This last point means that you need to set the following in your neo4j.conf file:

dbms.security.procedures.unrestricted=spatial.*

Spatial 0.26.2-neo4j-3.5.2

A small release including support for spatial.removeNode and spatial.removeNodes procedures for removing nodes from layers (and their underlying indexes). These procedures do not delete the nodes.

Spatial 0.26.2-neo4j-3.4.12

A small release including support for spatial.removeNode and spatial.removeNodes procedures for removing nodes from layers (and their underlying indexes). These procedures do not delete the nodes.

Spatial 0.26.1-neo4j-3.5.2

This release supports Neo4j 3.5. In addition, the primary change introduced in the 0.26.x branch of releases is the addition of a new GeomertyEncoder for point data, called the NativePointEncoder. This can be used as a replacement for the SimplePointEncoder. The SimplePointEncoder encodes points as two double properties on a node, usually 'x' and 'y' or 'longitude' and 'latitude'. The NativePointEncoder works on Neo4j 3.4 and later with the built-in support for Point data types.

All procedures that supported the SimplePointEncoder now have versions for the NativePointEncoder. For example:

CALL spatial.addLayerWithEncoder('geom','NativePointEncoder','pos:mbr')

And then

CREATE (n {pos:point(latitude:13.2,longitude:56.7)}) CALL spatial.addNode('geom',n)

Or perhaps:

CALL spatial.addNativePointLayerGeohash('points')

And then:

CREATE (n {location:point(latitude:13.2,longitude:56.7)}) CALL spatial.addNode('points',n)

Spatial 0.26.1-neo4j-3.4.9

The primary change in the release is the addition of a new GeomertyEncoder for point data, called the NativePointEncoder. This can be used as a replacement for the SimplePointEncoder. The SimplePointEncoder encodes points as two double properties on a node, usually 'x' and 'y' or 'longitude' and 'latitude'. The NativePointEncoder works on Neo4j 3.4 and later with the built-in support for Point data types.

All procedures that supported the SimplePointEncoder now have versions for the NativePointEncoder. For example:

CALL spatial.addLayerWithEncoder('geom','NativePointEncoder','pos:mbr')

And then

CREATE (n {pos:point(latitude:13.2,longitude:56.7)}) CALL spatial.addNode('geom',n)

Or perhaps:

CALL spatial.addNativePointLayerGeohash('points')

And then:

CREATE (n {location:point(latitude:13.2,longitude:56.7)}) CALL spatial.addNode('points',n)

Spatial 0.25.7-neo4j-3.4.9

This fixes a few things, but in some cases it makes small API changes, so take care when upgrading if you use these API's:

• Changed some procedures to functions (spatial.decodeGeometry and spatial.asGeometry)
  • Support returning Points in 3.4
  • Support returning non-Points as maps
• Orthdromic distance for non-points looks for nearest points distance
• Fix for bug reported by community (withinDistance), based on orthodromic distance filter

Spatial 0.25.6-neo4j-3.4.5

Patch release to the 0.25.x series with a bugfix to the OSM importer for cases when the XML does not contain changeset fields. This bug was only relevant to the case where the XML has ways that reference missing nodes, and we request to index all point nodes of each way, not only the ways themselves. So we have made two changes:

• The procedure calls for importing OSM files now default to not indexing all nodes
• If you do index all nodes (for example using the command-line tool instead), then the missing nodes will generate warning messages and not a NPE.

Spatial 0.25.5-neo4j-3.4.1

A patch to the 0.25.x series which includes two bug-fixes:

• a bug-fix to cases when the same node is added to both RTree based layers, as well as lucene index based layers (like geohash, zorder or hilbert). This fix also includes a behaviour change in that deleting layers will no longer default to deleting the geometry nodes. The requirement for that behaviour is long obsolete.
• a bug-fix for OSM importing where the OSM file does not contain changeset fields on the nodes

It should be noted that Neo4j 3.4.0 has included more enhanced support for native Point types inside the database itself. This library can understand those types, as it did with the earlier 3.0 Point type, but does not make any special use of the built-in Neo4j spatial features, except that the space filling curve algorithm is now the one included in Neo4j itself.

Spatial 0.25.5-neo4j-3.3.5

A patch to the 0.25.x series which includes two bug-fixes:

• a bug-fix to cases when the same node is added to both RTree based layers, as well as lucene index based layers (like geohash, zorder or hilbert). This fix also includes a behaviour change in that deleting layers will no longer default to deleting the geometry nodes. The requirement for that behaviour is long obsolete.
• a bug-fix for OSM importing where the OSM file does not contain changeset fields on the nodes

This was built against the latest Neo4j 3.3.5 release. It is likely to work with earlier 3.3.x versions too, but that has not been tested explicitly.

Spatial 0.25.4-neo4j-3.2.8

A patch to the 0.25.x series which includes a bug-fix to cases when the same node is added to both RTree based layers, as well as lucene index based layers (like geohash, zorder or hilbert). This fix also includes a behaviour change in that deleting layers will no longer default to deleting the geometry nodes. The requirement for that behaviour is long obsolete.