Opened 7 years ago

Closed 7 years ago

#1200 closed defect (fixed)

st_estimated_extent returns bogus values

Reported by: dmiranda Owned by: strk
Priority: high Milestone: PostGIS 2.0.0
Component: postgis Version: trunk
Keywords: Cc:


How to reproduce:

-load the attached dataset (two rectangles) -run vacuum analyze on the table -run

select st_estimated_extent('estimate_extents_fails_on_this','geom');

-a bogus result should ensue, like this one:

"BOX(-1703756553.3167 0,0 0)"

The correct result is: select st_extent(geom) from estimate_extents_fails_on_this; "BOX(-55.8796586329487 -28.9576596206607,-53.0671265720575 -27.1734940596501)"

Tested with postgis 2.0.0, geos 3.2.2 & geos 3.4 SVN select postgis_full_version(); "POSTGIS="2.0.0SVN" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.7.8" USE_STATS" Exact postgis version is R7856 Last Changed Date: 2011-09-15 14:43:57

Attachments (1)

estimate_extents_fails_on_this.sql (1.0 KB) - added by dmiranda 7 years ago.
Simple table for testing st_estimated_extent

Download all attachments as: .zip

Change History (6)

Changed 7 years ago by dmiranda

Simple table for testing st_estimated_extent

comment:1 Changed 7 years ago by strk

Another case of bogus estimated_extent. Download shapefile from Import (without index) vacuum analyze the table.

ST_Estimate_extent returns:

BOX(2.71602850291942e+51 6.91389452604684e-310,2.00096586565705e-321 6.91389266706516e-310)

ST_Extent returns:

BOX(313182.457211229 4879523.84866166,516967.504878363 5145795.4033246)

comment:2 Changed 7 years ago by strk

Ok, I think I've found the culprit. Box in histogram is 4 floats, we're memcpying a GBOX instead, which is also much larger. Must have been the effect of a copy&replace

         * Construct box2dfloat4.
         * Must allocate this in upper executor context
         * to keep it alive after SPI_finish().
        box = SPI_palloc(sizeof(GBOX));

        /* Construct the box */
        memcpy(box, ARR_DATA_PTR(array), sizeof(GBOX));

ARR_DATA_PTR(array) is a pointer to float4 values, we should cast to BOX2DFLOAT4 and then _convert_ to GBOX eventually

comment:3 Changed 7 years ago by strk

Paul, I'm assuming you'll deal with this. I don't know how to deal with GBOX, and BOX2DFLOAT4 is _defined_ to GBOX, and the function should return a box2d which I dunno what it is anymore ... :/

comment:4 Changed 7 years ago by strk

Owner: changed from pramsey to strk
Status: newassigned

Ok, I'll do it...

comment:5 Changed 7 years ago by strk

Resolution: fixed
Status: assignedclosed

With r7868 I'm memcpy'ing into GEOM_STATS, which is of the correct size, and then converting to the box. I also took the chance to set the GBOX's flags, worth double checking. We'd need a constructor for gboxes, someting to initialize them after allocation (C++ corrupted me ;)

Note: See TracTickets for help on using tickets.