The SimplePointLayer and the GeoPipeline have methods for this, but they do make some assumptions. See SimplePointLayer.findClosestPointsTo(Coordinate,int) and GeoPipeline.startNeiarestNeighborLatLonSearch(Layer,Coordinate,int). The former just calls the latter. The int passed is the number of geometries to return. This actually internally reverts back to the approach of passing in an envelope region to search, but it calculates that region using the average density of points in your layer. So if you have evenly distributed points, then this approach is quite reliable. But if you have very unevenly distributed points, then if your search location is in a low-density area, the envelope will be underestimated and fewer points will be returned.
The envlope estimation is done in SpatialTopologyUtils.createEnvelopeForGeometryDensityEstimate(layer, point, numberOfItemsToFind). You could make your own version of that with different assumptions if you want. However, to really answer your question with high reliability and performance would require replacing the RTree with a different index. The RTree is optimal for envelope searches. But a quad-tree or some other index that does not allow overlapping index leaves, would allow for a local search by traversing backwards up the index, and therefor we could start at the point of interest and search outwards from there, stopping once we have found as many results as we want. This logic is not possible in an RTree, which must be searched from the index root. To swap in a different index is a non-trivial task, but something we hope to do at some point. So in summary, these are your options: - Use the geometry density envelope assumption (either through the SimplePointLayer or the GeoPipeline methods above) - Write your own envelope assumption code (simple, but only as reliable as your assumption matches your data) - Write a quad-tree index and a reverse traversal search (much less trivial, obviously). Something entirely different to think about, but definitely suiting Neo4j, would be to make closeness part of your domain model. In other words connect close geometries with 'is_close_to' relationships. The calculation of this closeness could be done at various points, during load, or on demand when querying, whatever suites your use case. On Thu, Oct 9, 2014 at 5:27 PM, Alireza Rezaei Mahdiraji < alireza...@gmail.com> wrote: > > Hi Craig, > > Any idea how to implement the knn in efficient way? We need to specify an > initial distance and if we do not find k neighbours > within that distance we need to increase it, which does not seem like very > efficient approach. > > > Thanks, > Alireza > > On Tuesday, September 23, 2014 8:17:04 PM UTC+2, Craig Taverner wrote: >> >> I did not answer everything. But the JTS distance method will work for >> all geometries, so that answers most of your questions. >> >> The GeoPipeline methods also provide ways to find objects within >> distances of other objects (using the rtree for optimized searches). And it >> provides sorting too, so you can, for example, search for everything within >> some maximum bounds, sort by distance and pick the closest 'k' elements. >> >> On Tue, Sep 23, 2014 at 8:14 PM, Craig Taverner <cr...@amanzi.com> wrote: >> >>> The distance is calculated best using JTS. For example: >>> double distance = pointA.distance(pointB) >>> >>> See http://tsusiatsoftware.net/jts/javadoc/com/vividsolutions/jts/geom/ >>> Geometry.html#distance(com.vividsolutions.jts.geom.Geometry) >>> >>> On Tue, Sep 23, 2014 at 3:26 PM, Alireza Rezaei Mahdiraji < >>> alire...@gmail.com> wrote: >>> >>>> >>>> Hi All, >>>> >>>> Given two geometries how do compute the distance between >>>> them in neo4j spatial? For instance given two points stored in two >>>> nodes? >>>> >>>> What other kind of distance are defined? For instance, is it possible >>>> to find >>>> distance between a point and a linestring/polygon or distance between >>>> two polygons? >>>> >>>> Related to the concept of distance, it is possible to find objects >>>> within a given distance of a >>>> given object. But what about computing knn, i.e., finding k elements >>>> which are closets to the >>>> given object? Shall we compute all distances and then pick top k or >>>> there is implemented >>>> and optimized way to do this? >>>> >>>> Thanks, >>>> Best, >>>> Alireza >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Neo4j" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to neo4j+un...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to neo4j+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
