ST_Extent when cast to box3d flipflops
|Reported by:||robe||Owned by:||pramsey|
Description (last modified by )
I'm not sure how to explain this, but I see this behavior on my 2.0 and 1.5 (PG 8.4, 9.1) on my windows 7.0 64-bit (32-bit PostGIS). Saw the same behavior on a Windows 7.0 32-bit (running PostGIS 2.0, didn't have 1.5 to test).
However my 8.4 32-bit on windows 2003 server running PostGIS 1.5 does not exhibit this behavior.
SELECT ST_Extent( 'LINESTRING( 1.121333 2.2567,3.3456 4.4567 )'::geometry )::box3d
The issue is that the answer to the above alternates between On my 64-bit 1.5 install on 8.4
-- note the e+180 e+214 BOX3D(1.121333 2.2567 5.21970604560393e+180,3.3456 4.4567 1.9161093301878e+214)
BOX3D(1.121333 2.2567 1.35832574246381e-312,3.3456 4.4567 1.39071360148373e-309)
on my 64-bit windows 7 (running 32-bit PostGIS 2.0 alternates between:
BOX3D(1.121333 2.2567 0,3.3456 4.4567 0)
BOX3D(1.121333 2.2567 1.44721314518794e-312,3.3456 4.4567 3.88199318618405e-080)
Granted the differences are small (except for the e+ cases), but why it changes answer like the wind is a mystery.