Opened 12 years ago

Closed 11 years ago

#1334 closed defect (fixed)

ST_Extent when cast to box3d flipflops

Reported by: robe Owned by: pramsey
Priority: medium Milestone: PostGIS 1.5.4
Component: postgis Version: 1.5.X
Keywords: Cc:

Description (last modified by 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)


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.

Change History (7)

comment:1 by robe, 12 years ago

Description: modified (diff)

comment:2 by robe, 12 years ago

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.

comment:3 by strk, 12 years ago

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.

comment:4 by strk, 12 years ago

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

comment:5 by pramsey, 11 years ago

Does r9674 make it go away?

comment:6 by robe, 11 years ago

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.

comment:7 by pramsey, 11 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.