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

[cp]

Paul (or some other expert),

Some of these questions are no doubt going to be stupid:

I don't quite understand why the BOX3D() needs special treatment 
relative to the other types like POINT()? ie. Why is the extra cast to 
box3d required?  Can this cast be removed at some point in the future or 
is there a good reason for it?  It seems inconsistent to me (with my 
admittedly limited knowledge.)

Is using a BOX3D() still the best way to query for a rectangular AOI or 
should I reformulate my queries using POLYGON()?

What does the expand() function do?  I wasn't able to find any 
documentation on this.

Sorry for all the stupid questions.

Thanks for your help,
Corey

Paul Ramsey wrote:

> Actually, this is a slightly user-hostile annoyance I ran across last 
> night while writing the PostGIS workshop for MUM (I hope everyone is 
> coming, I expect to see all 450 of you there (and expect all of you to 
> buy me a beer (the workshop might be a little disjointed))).
>
> Since box3d's cannot hold an SRID, if you ever get a cast into box3d, 
> you lose your SRID, which results in ugly SQL like this:
>
> WHERE the_geom && setsrid(expand(geometryfromtext('POINT(100000 
> 100000)',42102),100),42102)
>
> (I recognize that I can shrink the lenght of it a bit by not initially 
> declaring an SRID, it will get stripped later, after all.) To the user 
> it is not immediately obvious why the more straightforward SQL does 
> not work:
>
> WHERE the_geom && expand(geometryfromtext('POINT(100000 
> 100000)',42102),100)
>
> ERROR:  Operation on two GEOMETRIES with different SRIDs
>
> You make a geometry, and expand it, seems like a nice obvious piece of 
> SQL, but the error message you get says your SRIDs mismatch. But you 
> set an SRID, it's right there in the SQL! Confusion reigns.
>
> On Thursday, June 3, 2004, at 01:36 AM, Mark Cave-Ayland wrote:
>
>>
>> Hmmm..... I can't see why this one doesn't work. All I can think of is
>> that the BOX3D cast causes the SRID not be set or set incorrectly. I'll
>> try and have a look at this in the near future, however I'm not sure
>> exactly when I'll be able to get around to it.
>