Subject: [geometry] [index] nearest query point relations
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-05-03 16:35:20
Point relation may be used to define to which point of an indexable
distance is calculated during knn search. Currently they're wrappers
around point to which distance is going to be calculated. They're used
query(nearest(point, 10), ...); // default
query(nearest(to_nearest(point), 10), ...); // to closest point, default
query(nearest(to_centroid(point), 10), ...); // to centroid
query(nearest(to_furthest(point), 10), ...); // to furthest point
To keep it short. I'd like to remove point relations in the current form
from public interface to have more room for change in the future.
Are you ok with that?
Below, expanded explanation.
I'm thinking about ray queries and how they might be implemented. One
possible and powerful solution is to use linestrings instead of rays.
This query would return k _nearest_ values on a _path_ defined by
linestring from the first to the last point. Two most important words
are "path" and "nearest". So this could be called path() query and be
used like this:
query(path(linestring, 10), ...);
But internally this query is quite similar to knn query (nearest), the
distance is just calculated differently. So nearest() predicate could be
used for this one too. There only should be a way to distinguish between
1. distance between linestring and indexable
2. distance from the first point on a path to the indexable.
nearest() probably won't be used, but if it will, point relations might
Furthermore they aren't elegant and consistent with the rest of the
library. Correct me if I'm wrong but shouldn't strategies be used in
this case? Wouldn't this be better:
query(nearest(point, 10, strategy::nearest::to_centroid()), ...);
or something similar.
What do you think?
Geometry list run by mateusz at loskot.net