Mateusz Loskot wrote:

Then it would look like this:

// return values covered by g1 and those which have got g2 within
rt.query(covered_by(g1) && ~within(g2), ...);

// return values which haven't got g within
rt.query(!~within(g), ...);
// probably the same as
rt.query(~!within(g), ...);

Are you ok with this operator? Or maybe some function would be better?

I like the expressivness of that, but I'm worried that
mixing native operator! and customised overloaded operator~
with slightly bent semantic would cause confusions.

all operators used in the predicates expression, i.e. && and ! are overloaded.

About operator~, do you mean it reverse order of application of predicate(s) or
something more sophisticated like generate some kind of 'complement' of the set
of given predicates? The latter sounds more aligned to bitwise NOT, doesn't it?
Or, have I lost the discussion track?

I don't know what TONGARI had in mind using the word 'reverse'.

I thought about reversing the relation between returned value and passed geometry in boolean operation checks. Or in the other words, about switching boolean operation's parameters.

Predicates expression would be most expressive if this predicate was generated by some operator, not by e.g. a function. I've choosen operator~ as an example because I don't see any better but I'm open to suggestion.

I also think about using Boost.Range pipe operator like this:

rt.query(intersects(g1) && !within(g) | xxx, ...);

where xxx is e.g. reversed. However, I don't know it wouldn't be even more confusing since the user may think that it's somehow related to the output range. Furthermore mixing those styles doesn't feel right.

Function?

rt.query(intersects(g1) && !reversed(within(g)), ...);

maybe.

I begin to think that the best solution would be to not implement reversing. We might provide 2 additional predicates - reversed versions of within() and covered_by() because only those two predicates actually need reversing. Plus maybe BG boolean operations with the same names. OGC don't define covered_by() am I right? If yes, then just one additional - contains() as TONGARI mentioned. This is probably the best option.

Alternative maybe the placeholder syntax:

within(pt, _target)

where _target is the placeholder.

But I don't think this could be implemented in a really generic way for Spatial Index, so I think a 'contains' (and 'covers'?) addition would just be fine.