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

Sandro Santilli strk at keybit.net
Tue Feb 24 04:44:18 PST 2015


For the record, I've committed code ensuring the stated semantic
(missing dimensions have infinite range).

BUT, I found a document of yours that expects differently-dimensioned
geometries to not overlap:
http://workshops.boundlessgeo.com/postgis-intro/3d.html

Snippet:

  -- Returns false (one 2-D one 3-D)
  SELECT 'POINT Z (1 1 1)'::geometry &&&
         'POLYGON ((0 0, 0 2, 2 2, 2 0, 0 0))'::geometry;

That query returns TRUE now, for the 2-D polygon having an
infinite Z range.

Is that enough exposure to require a mention in the NEWS as a
backward incompatible change ?

REF: http://trac.osgeo.org/postgis/ticket/3045

--strk;

On Thu, Feb 19, 2015 at 06:44:38PM +0100, Sandro Santilli wrote:
> 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
> > >  
> > 



More information about the postgis-devel mailing list