I might as well give my 2 cents to this discussion as well...
Personally, I don't find this surprising at all. You're comparing the
bounding boxes of two geometries in completely different planar
projections. This is almost like doing:
SELECT 1::integer
UNION
SELECT true::boolean
and expect to get a single row back. This doesn't work - type casting
is clearly called for. Obviously, I'm exaggerating here to make my
point, but I prefer stricter type casting by the user than magically
casting one to the other behind the scenes. As Brent pointed out this
morning, even transforming one geometry to the other results in
coordinate drift and the two bounding boxes won't likely be the same
anyway. If it's left to magically transform the geometries behind the
scenes, it'll be *far* more difficult to track down those application
bugs that make certain assumptions about their geometries only to find
out that = is failing due to precision round off errors via transform.
In my opinion, throwing an ERROR is the better choice.
Cheers,
Kevin
Charlie Savage wrote:
This looks like a related issue:
select 'srid=4326;point(3 3)'::geometry
union
select 'srid=4325;point(3 3)'::geometry
ERROR: Operation on two GEOMETRIES with different SRIDs
I find that surprising, I would expect to get a result table with two
rows.
Charlie
_______________________________________________
postgis-users mailing list
[email protected]
http://postgis.refractions.net/mailman/listinfo/postgis-users
