ST_Extent when cast to box3d flipflops

[robe]

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)

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 (except for the e+ cases), but why it changes answer like the wind is a mystery.

[robe]

side note: ST_Extent returns a box3d_extent type object. Casting to box2d as far as I can tell seems fine perhaps because all the hanky panky is going on in the 3rd dimension.

[strk]

ST_Extent doesnt return box3d_extent anymore as of r8324. Not sure how to _fix_ a live database to get in sync with what you'd get in a new install. That sync would be needed to recheck this bug.

[strk]

See ticket #1359 for the need to get in sync.

[pramsey]

Does r9674 make it go away?

[robe]

Hmm well I'm testing on my 9.1 PostGIS 32-bit on my 64-bit windows 7 — it still flip flops but between these two

BOX3D(1.121333 2.2567 1.33509062592497e-306,3.3456 4.4567 3.88199318618405e-080)

BOX3D(1.121333 2.2567 1.390671161567e-309,3.3456 4.4567 0)

I don't have a 32-bit OS at the moment to test on, but don't think it was an issue on 32-bit anyway.

[pramsey]

Got it at r9706. It showed up on my win32 build so was able to test myself.