[postgis-users] Incorrect results from queries specifying an SRID

cp cplists at yeroc.ca
Tue Jun 1 08:51:12 PDT 2004


[Oops...meant to send this to the list as well]

Mark,

I just tried what you suggested but I'm getting the same result:  0 rows
returned with no error reported.  Is there another fix that needs to be
applied to raise the error condition?

Incidentally although select postgis_version(); reports 0.8 I've
verified that what I have installed is 0.8.1 (is this a bug in the
postgis_version() funtion?)

Thanks for your help,
Corey

Mark Cave-Ayland wrote:

>Hi strk,
>
>Yup you're right :) I didn't notice that we didn't use the old files any
>more - I guess they're there while people test the new postgis.sql build
>process?
>
>So in theory this should be solved in the 0.8.2 release. cp, can you
>test this for us by doing the following in psql, and seeing whether the
>SRID mismatch is caught? Note this is done in a transaction as it
>affects the system catalogs and so we can roll it back if it doesn't
>work.
>
>
>BEGIN;
>
>UPDATE pg_amop SET amopreqcheck = 't' WHERE amopclaid=(SELECT oid FROM
>pg_opclass WHERE opcname = 'gist_geometry_ops');
>
>(this should update only 8 entries)
>
>SELECT * FROM gis
>WHERE geometry && GeometryFromText('BOX3D(325356 6341280,335614 
>6328019)'::box3d, 26712);
>
>
>If this throws an error on SRID mismatch then you can COMMIT the
>transaction to make the behaviour permanent. Otherwise type ABORT and
>the change will be rolled back. Please report back to as to whether this
>solved the problem for you.
>
>
>Many thanks,
>
>Mark.
>  
>
[...]




More information about the postgis-users mailing list