[postgis-devel] Box3D
Mark Cave-Ayland
mark.cave-ayland at ilande.co.uk
Mon Aug 13 00:54:01 PDT 2007
On Thu, 2007-07-26 at 08:18 +0200, Vincent Heurteaux wrote:
> Hi,
>
> We are trying to use a PostGIS database with a column of "box3d"
> type. I realize that most PostGIS functions are designed for working
> on geometry objects, but we though that "box3d" was exactly what we
> need (namely, store the envelope of a 3 dimensional raster). However
> we ran over a number of problems:
>
> * It seems to be impossible to create an index for a
> column of type "box3d". Did we missed something?
>
> * It seems impossible to pass a "box3d" object in a JDBC
> PreparedStatement
> using the PostGIS driver. Attempt to pass a org.postgis.PGbox3d
> instance
> to PreparedStatement.setObject(...) results in an exception
> similar to the
> problem described here:
>
> http://www.postgis.org/pipermail/postgis-users/2005-June/008536.html
>
> Attempt to pass a BOX3D as a String did not worked neither
> (PostgreSQL
> said that it don't know any && operation taking my argument, or
> that my
> argument is an invalid geometry). We add to pass the argument as a
> MULTIPOINT rather than BOX3D.
>
>
> Are we missing some simple trick, or are we suppose to avoid "box3d"
> columns when using PostGIS?
>
> Vincent Heurteaux
> http://www.geomatys.fr
Hi Vincent,
BOX3Ds are a leftover from when geometries were converted to BOX3Ds in
order to be inserted into the R-Tree index. This meant that you could
quickly intersect an indexed column by doing BOX3D && column. However,
newer versions of PostGIS use new light-weight index entries which are
no longer BOX3Ds, and the OGC parser was changed to reject them since
they are not OGC compliant geometries. Hence they were never designed to
be used directly as a column type.
HTH,
Mark.
--
ILande - Open Source Consultancy
http://www.ilande.co.uk
More information about the postgis-devel
mailing list