Geospatial Support for Neo4j.

bob1
Node

We want to preform geospatial calculations using Neo4j. We have some experience using the geospatial library GitHub - neo4j-contrib/spatial: Neo4j Spatial is a library of utilities for Neo4j that faciliates th..., but it looks like that library is not supported in Neo4j version 4.4.2.

How can this functionality be supported in Neo4j version 4.4.2 and beyond?

How difficult is it to port the spatial libraries to Neo4j version 4.4.2?

What native support for geospatial functions exist in Neo4j? It looks like there is support for bounded box and distance.

Is there a better way to implement geospatial functionality outside Neo4j?

1 REPLY 1

craig_taverner
Graph Buddy

There are many solutions to working with geospatial data inside and outside Neo4j, so a lot depends on your actual use case.

The older library you mentioned above is quite a comprehensive set of functions, but was designed for embedded use cases originally, so is not always ideal for today's Neo4j deployments. Having said that, the problem you faced, with lack of Neo4j 4.4 support, is an issue with several spatial libraries, including the OSM library and the 'spatial-algorithms' library. The reason for this is that all of them use, to some degree, internal APIs inside Neo4j which change from release to release, and therefor require some work to migrate them.

I support these libraries in my personal time, so I am often quite behind in updating them. I did start porting the spatial-algorithms library to Neo4j 4.3 last weekend, but was blocked on an internal issue in Neo4j. If I can find a way to work around that, I will, but it does delay and complicate this kind of work.

And finally, the spatial support within Neo4j is, as you noted, limited to points and functions that work with points: point(), distance() and withinBBox().

The spatial-algorithms library tries to expand this to complex polygons modelled as collections of arrays of native point types. The spatial library, being much older, models spatial data usually as WKT (and many other encodings) in node properties.

You ask how difficult it is to port the libraries to newer versions of Neo4j? At best, it is a few lines change (dependencies in the pom files), more often it is a few changes to import lines for internal APIs that have changed, and sometimes it is a big job to fix or work around major changes. The port to Neo4j 4.0, for example, required changing almost every single file, and restructuring the entire way transactions are handled. Right now the port to Neo4j 4.3 is facing a very strange issue in closing relationship cursors deep inside the kernel. That kind of problem is rare, luckily.

If you are interested in doing this kind of work yourself, I'd be more than happy to support you there.