Geometry Boost List: Re: [geometry] [Spatial Index] bug & question

Subject: Re: [geometry] [Spatial Index] bug & question
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
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 
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.

Regards,
Adam