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
I was confused assuming !within(g) would be just negation of boolean
>> 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:
I sense, it means
"all indexed values that g fits completely inside them"
"give indexed values that fit completely inside g",
> 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.
> rt.query(intersects(g1) && !reversed(within(g)), ...);
This may be similar dilemma as in std library, overload operators
vs named predicates and adaptors like std::not, std::logical_not,
> 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
This is a good reading about subtle differences between OGC within/contains
and covered_by/CoveredBy non-standard extension avaialble popular geospatial
-- Mateusz Loskot, http://mateusz.loskot.net
Geometry list run by mateusz at loskot.net