Opened 13 years ago
Last modified 13 years ago
#1334 closed defect
ST_Extent when cast to box3d flipflops — at Initial Version
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.5.4 |
Component: | postgis | Version: | 1.5.X |
Keywords: | Cc: |
Description
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 running PostGIS 8.4 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
BOX3D(1.121333 2.2567 5.21970604560393e+180,3.3456 4.4567 1.9161093301878e+214)
and
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, but why it changes answer like the wind is a mystery.
Note:
See TracTickets
for help on using tickets.