I’m working on implementing the nearest
geo-query in Dgraph. This will be similar to the near
query with the difference that instead of always passing a distance for the near
query, we pass N
to the nearest query to get the N results nearest to the provided point. The query would look something like this:
{
tourist( nearest("loc", "[-122.4140288, 37.8083504]", "10" ) ) {
name
}
}
with the last parameter being N
. We could maybe include an optional parameter maxD
that could serve as another termination condition.
I’m following the approach taken in this MongoDB post. The logic for the nearest
query would have to wrap around the near
query, and recurse in growing intervals. The current logic for the near
query is a pipeline:
-
processTask
gets tokens fromGetGeoTokens
-
processTask
then gets or creates the posting list -
processTask
then callsFilterGeoUids
-
FilterGeoUids
iterates over the values in the PL, and for each one, checks whether it is contained by the cap (created from the provided point)
The recursive algorithm would need to wrap this whole pipeline in a function that can then be called recursively until some termination condition is met (either have found N
results or traversed maxD
distance). How performant do we need v1 of this query to be? If the answer is very, I think the pipeline will either have to be refactored or partly duplicated into the recursive algorithm. If the answer is not very, then we can just run multiple iterations of the full pipeline and select a big enough initial search radius.
That’s the way I’ve been thinking about it. I’d appreciate any elucidation you can provide on that thought process @mrjn .
I’m working on implementing a recursive algorithm that wraps the whole pipeline and accumulates results (the non-performant version in the dichotomy laid out above). Once I have a working version I’ll update this post.