[postgis-users] change to box3d()?

[strk at refractions.net]

On Fri, Sep 17, 2004 at 10:11:32AM -0600, sgillies at frii.com wrote:
> Hi,
> 
> An application of mine has failed after an upgrade from postgis 0.8 to
> 0.8.2.  I've traced the problem to an apparent change in box3d.
> 
> The failed query was something like this (actual numerical values
> are ommitted to save space), two clauses are marked *a and *b
> 
>   SELECT listing_id, the_geom
>   FROM listing
> *a  WHERE the_geom && box3d(transform('SRID=4269;POLYGON((...))', 26913))
>   AND 1=1
> *b  AND within(listing.the_geom, transform('SRID=4269;POLYGON((...))',
> 26913))
> 
> result:
>   ERROR:  Operation on two GEOMETRIES with different SRIDs
> 
> It's the same polygon within the transforms.  Including a 'where bounding
> box overlap' clause, as i understand it, is the way to a faster query.
> This query worked well with postgis 0.8.
> 
> With 0.8.2, omitting clause *a yields the proper results, but slowly.
> I discovered that dropping the box3d() call in clause *a and simply
> comparing geometry bounds gave the quick result i wanted.
> 
> Was this call to box3d() superfluous?  Is my new query without box3d()
> just as optimal as it was with box3d() under postgis 0.8?

yes and yes.
box3d looses SRID info and 0.8 did not check that when using
the index ... 
--strk;

> 
> cheers,
> Sean
> 
> 
> 
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users