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

Subject: Re: [geometry] [Spatial Index] bug & question
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-06-19 05:02:19

On 18 June 2013 16:56, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
> 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.

I was confused assuming !within(g) would be just negation of boolean
return value.

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

I'm still unclear about the reversing thing.
If we're speaking of two values: boolean returned value by predicate
and passed geometry, what kind of reversing this example taken from
code below means:

reversed(within(g))

I sense, it means
"all indexed values that g fits completely inside them"
but not
"give indexed values that fit completely inside g",
doesn't it?

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

I agree, mixing wouldn't be a good idea.

> Function?
>
> rt.query(intersects(g1) && !reversed(within(g)), ...);
>
> maybe.

This may be similar dilemma as in std library, overload operators
vs named predicates and adaptors like  std::not[12], std::logical_not,
std::plus, etc.

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

If reverse() adaptor is not feasible, then rwithin, rcovered_by? ;)

> OGC don't define covered_by() am I right?

You are right.
Current verssion of the pair of OGC/SQL 1.2.1 and ISO SQL/MM standards
list the following

Equals
Disjoint
Touches
Within
Overlaps
Crosses
Intersects
Contains
Relate

This is a good reading about subtle differences between OGC within/contains
and covered_by/CoveredBy non-standard extension avaialble popular geospatial
implementations:
http://lin-ear-th-inking.blogspot.co.uk/2007/06/subtleties-of-ogc-covers-spatial.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net