[postgis-devel] [PostGIS] #1334: ST_Extent when cast to box3d flipflops

PostGIS trac at osgeo.org
Mon Nov 28 16:54:41 PST 2011


#1334: ST_Extent when cast to box3d flipflops
---------------------+------------------------------------------------------
 Reporter:  robe     |       Owner:  pramsey      
     Type:  defect   |      Status:  new          
 Priority:  medium   |   Milestone:  PostGIS 1.5.4
Component:  postgis  |     Version:  1.5.X        
 Keywords:           |  
---------------------+------------------------------------------------------
Description changed by robe:

Old 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.

New 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 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.

--

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/1334#comment:1>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-devel mailing list