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

[Paul Ramsey]

Well, the old semantic has been there since 2.0, which is a very long time.
A further question for it would be: what do the next functions do? What does a distance calculation between a 2d and 3d object return? does it also respect that semantic? 

P

-- 
Paul Ramsey
http://cleverelephant.ca
http://postgis.net

On February 24, 2015 at 7:44:23 AM, Sandro Santilli (strk at keybit.net) wrote:

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  
> > >  
> >  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150224/adceebc5/attachment.html>