Geometry Boost List: [geometry] [index] nearest query point relations

Subject: [geometry] [index] nearest query point relations
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-05-03 16:35:20

Hi,

Quick reminder:

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 
like this:

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 
nearest() calculating:
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 
interfere.

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?

Regards,
Adam