Open thomasfr opened 10 years ago
Here is a gist with all necessary steps https://gist.github.com/thomasfr/8103037 I have also added an issue to neo4j directly because i think it is not only related to the spatial plugin: https://github.com/neo4j/neo4j/issues/2048
Any update on this?
The new design for built-in spatial support in Neo4j will do it this way. It is in fact a complete re-write, modelled on the schema indexes introduced in neo4j 2.0. We have not considered adding this capability back into the external library because not only would it be more difficult to achieve, but the preference is to focus on the new approach.
If you're interesting in a sneak peak at the new approach, see the presentation I did a few months ago. https://www.youtube.com/watch?v=Vfz--5hX5qs. Mostly I talk about the old stuff, but at the end I do mention some of the new stuff. The slides can be found at http://www.slideshare.net/craigtaverner/neo4j-spatial-foocafe-september-2015
Built-in support plus complete integration into Cypher, as shown in the video, seems like the right thing to do. I like the spatial lookups like within, overlap, etc, and the inherent types supported bu the use of the functions polygon
, point
, and I guess that also something like path
or linestring
. We are know finishing the integration of the current Spatial plugin, but if there are plans to release the built-in support anytime soon, I would consider switching to that.
The schedule for inclusion of the new spatial support in neo4j is still not clear. I'd recommend going ahead with your current plans, but consider taking direct contact with me to discuss your complete needs so we can see how well they align with the plans.
For example, support of linestring is not scheduled for the first release. Neither is index support for non point types. Hopefully they come out in versions soon after, with a different index.
The built in spatial support is going to have a much narrower feature set than the library, but should also have much better performance, scalability and stability characteristics.
Curiously the point() and distance() functions will already be available in the 3.0M01 release coming out any moment now. But no index support yet, so this is just a preview really. The index will come much, much later. On Nov 22, 2015 12:10 AM, "Javier de la Rosa" notifications@github.com wrote:
Built-in support plus complete integration into Cypher, as shown in the video, seems like the right thing to do. I like the spatial lookups like within, overlap, etc, and the inherent types supported bu the use of the functions polygon, point, and I guess that also something like path or linestring. We are know finishing the integration of the current Spatial plugin, but if there are plans to release the built-in support anytime soon, I would consider switching to that.
— Reply to this email directly or view it on GitHub https://github.com/neo4j-contrib/spatial/issues/125#issuecomment-158689656 .
In that case I guess I will integrate the current spatial plugin. Will be the plugin still compatible with the new additions in 3.0M01? I mean, will we be able to use spatial plugins indices with 3.0 branch?
The new point() and distance() functions are entirely separate work from the spatial library. They should not interact at all. However, once the new work gets its own index, there might be some interaction. The odds are low, but not zero. We'll make sure to document it if it happens.
It would be a big time saver if created nodes with lat and lon properties would get added automatically to the spatial index (maybe optionally). Because it is not clear, if a node gets added via REST and one forgets to add it to the index explicitly, when we later try make a e.g. "withinDistance" query which in turn should return this node, but since the query is correct we assume the result is also correct, but actually isn't. i thought that it maybe is possible when working with the node_auto_index feature? http://docs.neo4j.org/chunked/milestone/rest-api-configurable-auto-indexes.html
But thats a workaround in my opinion because it would also disable the possibility for other auto indexes.