|
Geometry : |
Subject: [ggl] rtree query interface
From: Barend Gehrels (barend)
Date: 2011-08-29 00:05:47
Hi,
On 9-8-2011 15:57, feverzsj wrote:
> hi:
>
> 1. IIRC, ggl still miss functor interfaces for predicates to use with
> boost.range.
> something like:
>
> template<class G1>
> struct Predicator
> {
> G1 const& g1;
>
> Predicator(G1 const& g) : g1(g) {}
>
> template<class G2>
> bool operator()(G2 const& g2) const
> {
> return predicate(g1, g2);
> }
> };
>
> such functor may be used with both boost.range and rtee;
Yes, that is right. They are not yet there. We've now defined most part
of the interface in the form of free functions, which which this can be
built but it is not there.
>
>
> 2. rtree may be consider as either an index structure or a boost.range:
> while using with some predicates(e.g.
> equals/intersects/overlaps/within), rtree works faster as an index
> structure;
> while using with other predicates, rtree may be just taken as a
> boost.range.
> so: "t | index::filtered(within(g))" and "t | filtered(within(g))"
> give the same result but the previous one could be much more faster.
>
> as for chained case,
> t | pred1() | pred2()| ... | predN()
>
> Will it return a new rtree for index::filtered()?
> Well, I think this could be less efficient for most use case, and not
> work well with those predicates that rtree not good at.
> I'd prefer simply return a sequential range at the first place.
> so :
> only the first "t | index::filtered(pred(g))" makes use of index
> facility. The followed adaptors will just deal with normal sequential
> range;
I agree with this.
Regards, Barend
Geometry list run by mateusz at loskot.net