# Geometry :

Subject: Re: [geometry] [Spatial Index] bug & question
Date: 2013-06-18 11:56:27

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

> 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.

Regards,