[postgis-devel] assumptions of &&& operator for missing dimensions

[Sandro Santilli]

On Thu, Feb 19, 2015 at 09:04:16AM -0800, Paul Ramsey wrote:
> My preference was always to allow, for example, a 2d query box to extract a 3d column of data from a volume of points, and I would have implemented that way if I could. Now, what i cannot tell you, is why I felt I couldn’t…

So your preference here is for number 2:

    1. Missing dimension is unknown, return NULL
 -> 2. Missing dimension is infinite, contains everything <-
    3. Missing dimension is empty, contains nothing
    4. An impossible comparison was requested, raise exception

That is a 2d query box is infinitely tall and 2d points are found
in 3d boxes at any height. Sounds good to me, as long as documented
as such and consistently enforced.

For example, in the query reported in
http://trac.osgeo.org/postgis/ticket/3045
rows 2,3,4 and 5 should be reported to overlap the query box, right ?

--strk;

> On February 19, 2015 at 8:46:22 AM, Sandro Santilli (strk at keybit.net) wrote:
> > The current &&& operator assumes 0 as the value of dimensions that are
> > missing from one of the operands.
> >  
> > This results in confusing behavior, like this:
> >  
> > select 'POINT(0 0)'::geometry &&& 'POINT(0 0 1)'::geometry; -- false
> > select 'POINT(0 0)'::geometry &&& 'POINT(0 0 0)'::geometry; -- true
> >  
> > I think the above two selects should give the same answer instead.
> > Possibilities are:
> >  
> > 1. Missing dimension is unknown, return NULL
> > 2. Missing dimension is infinite, return true
> > 3. Missing dimension is empty, return false
> > 4. An impossible comparison was requested, raise exception
> >  
> > Which one would you prefer ?
> > And what constraints do we have being the operator used by index scan ?
> >  
> > --strk;
> >  
> > () Free GIS & Flash consultant/developer
> > /\ http://strk.keybit.net/services.html
> >  
>