Thanks for reporting this. We also recently noticed this issue and made a fix for it, but unfortunately the fix was broader in scope than just the spatial index and as a result will only come out in Neo4j 3.5. This is currently in beta, so you could try and see if it works for your case.
The issue was that the query planner would not plan an index seek if the predicate expression included deeper dependencies, and in the case of the spatial bounding box query this meant it would only plan the index if the max and min expressions were literal point() functions with no dependencies. In your query you are depending on previously defined lower_x etc. This is a reasonable thing to do, of course, and so we have enhanced the planner to deal with this case.
The kinds of queries for which we can now plan the index seek include ones like this one in our acceptance tests: https://github.com/neo4j/neo4j/blob/3.5/enterprise/cypher/acceptance-spec-suite/src/test/scala/org/neo4j/internal/cypher/acceptance/SpatialIndexResultsAcceptanceTest.scala#L706
One curious aspect of this issue is that the index planning for the distance function actually worked a lot better already in Neo4j 3.4. This means that you can still get Cypher to plan the index in Neo4j 3.4 if you model a circle around your bounding box and use the distance function in the predicate instead.
So your options for improving performance are:
- Try Neo4j 3.5 Beta 02 release which should plan your current query with the spatial index
- Change the query to use the
distancefunction instead to get Neo4j 3.4 to use the spatial index
For this second option you could calculate a distance threshold as the maximum of the distances between the centroid and the max and min points, and then use that in a predicate like:
distance(i.volume_centroid, other_volume_centroid) < dist_threshold
Note: The fix was only merged recently, and did not make the Neo4j 3.5 Beta01 release, but should be in the Neo4j 3.5 Beta02 release.