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

Subject: Re: [geometry] [Spatial Index] bug & question
From: TONGARI (tongari95_at_[hidden])
Date: 2013-06-19 02:33:04

2013/6/18 Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]>

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

Regards,