[postgis-users] box3d overlap

[Martijn Meijers]

Hi,

I am rather puzzled by the following:

select 'BOX3D(0 0 0, 10 10 10)'::box3d &&& 'BOX3D(0 0 90, 10 10
100)'::box3d;
?column?
----------
t

select st_overlaps('BOX3D(0 0 0, 10 10 10)'::box3d, 'BOX3D(0 0 90, 10 10
100)'::box3d);
st_overlaps
-------------
f

select st_intersects('BOX3D(0 0 0, 10 10 10)'::box3d, 'BOX3D(0 0 90, 10
10 100)'::box3d);
st_intersects
---------------
t
(1 row)


Should these queries not all return false (as the boxes do not share any
space)?
Or is it because these functions do not (yet) support 3D (and operate on
the projected 2D primitives)?
If so, I find the documentation for the &&& operator rather confusing...


Martijn

--
Martijn Meijers

mailto:b.m.m...@tudelft.nl
http://www.gdmc.nl/martijn

GIS-technology
Faculty of Architecture and the Built Environment
Delft University of Technology

P.O. Box 5030 | Jaffalaan 9 (Building 30)
2600 GA Delft | 2628 BX Delft
The Netherlands

tel (+31) 15 2785642
fax (+31) 15 2782745

_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users

[Nicklas Avén]

Hallo Martijn

Here is more than one problem I think.

In the case of ST_Overlaps and ST_Intersects they only work on 2d.

ST_3DIntersects work on 3d or actually 2.5d because the function doesn't understand volumes which a box is. 

I am actually not sure how the box is casted before feeded as a geoemtry to the functions. Someone might answer that.

About the behavior of &&& I am also confused, and maybe suspects something not working as expected.

I thought &&&-operator would work on the box type.

/Nicklas

[Martijn Meijers]

On 06/20/2014 01:17 PM, Nicklas Avén wrote:
>
> About the behavior of &&& I am also confused, and maybe suspects
> something not working as expected.
> I thought &&&-operator would work on the box type.

That is my main concern for now. It seems there is a bug lurking around
(or the documentation should not state that it does 3D things).

For the other two functions I can understand that they might project to
2D, but not for the &&& operator.

[Martijn Meijers]

Ok, to answer my own question: It does indeed project to 2D (when
arguments are both of box3d type, and not when it is a geometry).


gisbase=> select 'LINESTRINGZ(0 0 0, 10 10 10)' &&& 'LINESTRINGZ(0 0 90,
10 10 100)';
?column?
----------
f
(1 row)

gisbase=> select 'LINESTRINGZ(0 0 0, 10 10 10)'::geometry::box3d &&&
'LINESTRINGZ(0 0 90, 10 10 100)';
?column?
----------
f
(1 row)

gisbase=> select 'LINESTRINGZ(0 0 0, 10 10 10)'::geometry::box3d &&&
'LINESTRINGZ(0 0 90, 10 10 100)'::geometry::box3d;
?column?
----------
t
(1 row)


Maybe the documentation should be more specific about this behaviour.

On 06/20/2014 01:17 PM, Nicklas Avén wrote: