Hi Adam,
Your work is very appreciated, a proper rtree index is essential! :)
I haven't used rtree yet, unfortunately, so I apologise if the questions are slightly off-topic:
- One of the key strenghts of Boost.Geometry, imho, is the ability to adapt legacy interfaces, that can not be canged, and use them directly. Please consider this when deciding on the interface (although I'm sure you already are)
- Will it be possible to use rtree queries on external (indexable) objects? For example, if I have a rtree-indexed boundary, and a set of not-indexed objects, and want to check if the objects intersect with my boundary. Essentially a kind of prepared query like the PreparedGeometry in GEOS.
Regards,
Mats Taraldsvik
Hi,
For those interested in the spatial index subject, I'd like to share some news about the rtree.
We've relaxed rtree value_type requirements and simplified the interface.
- It's allowed to store values without default ctor.
- There is only one query() method/function and queried() adaptor. Nearest query is performed when nearest() predicate is passed to the query(). Predicates may be connected by &&. It looks like this:
using namespace boost::geometry::index;
tree.query(box, out_it);
tree.query(intersects(box1) && !within(box2), out_it);
tree.query(nearest(pt, k) && intersects(box), out_it);
tree.query(nearest(to_centroid(pt), k) && intersects(box), out_it);
Removed features:
- nearest query returning one value.
- distance predicates (i.e. bounded(), min_bounded(), max_bounded()), we'd like to design better alternative in the future.
What do you think about the changes?
Regards,
Adam
_______________________________________________
Geometry mailing list
Geometry@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/geometry