I'm just wondering why this &&& is returning true when I use ST_3DMakeBox?

SELECT ST_MakePoint(0,0,0) &&& ST_3DMakeBox(

When these &&& returns false

SELECT ST_MakePoint(0,0,0) &&& ST_3DMakeBox(

SELECT ST_MakePoint(0,0,0) &&& ST_3DMakeBox(

Going through the X-Y, I can see a non-intersection in those ranges makes the 3d-test return false. However, a non-intersection in Z, even with &&& is still returning true.

 POSTGIS="2.2.2 r14797" GEOS="3.5.1-CAPI-1.9.1 r4246" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 2.1.2, released 2016/10/24" LIBXML="2.9.3" LIBJSON="0.12.1" RASTER
(1 row)

Just an Ubuntu 17.04 stock install.

  • You link to the manual of ST_3DIntersects but you might mean the nd_overlaps: postgis.net/docs/geometry_overlaps_nd.html Do you have GDAL installed? I don't see this happening in my 2.4 build but I also have CGAL installed. – tilt Aug 21 '17 at 12:13
  • @tilt if && is what I want in 2d ,why isn't &&& what I want in 3d? – I Support The Boycott Aug 21 '17 at 15:30
  • @tilt updated with postgis full version – I Support The Boycott Aug 21 '17 at 15:33

You're seeing this behavior because the &&& operator is defined between two geometry arguments, not between two box3d arguments (BOX3D() and ST_3DMakeBox return box3d). In PostGIS 2.2 and earlier, the cast from box3d to geometry dropped the Z ordinate, causing (among other things) the odd behavior you're seeing here. More details in the relevant ticket.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.