[postgis-users] change to box3d()?

[Sean Gillies]

On Sep 17, 2004, at 10:42 AM, strk at refractions.net wrote:

> 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;
>

Great.  Thanks, strk!

Sean