Opened 12 years ago

Closed 11 years ago

#2370 closed defect (wontfix)

ST_EstimatedExtent bug

Reported by: strk Owned by: pramsey
Priority: blocker Milestone: PostGIS 2.1.0
Component: postgis Version: 2.1.x
Keywords: Cc:

Description

CREATE TABLE public.source (g GEOMETRY);
INSERT INTO public.source VALUES
 ('POINT(0 2047)'),
 ('POINT(0 0)'),
 ('POINT(2047 0)')
 ;
ANALYZE source;
SELECT ST_Extent(g) FROM source;
SELECT ST_Estimated_Extent('public', 'source', 'g');

Real extent: BOX(0 0,2047 2047) Estimated: BOX(-10.2349996566772 -10.2349996566772,2057.23510742188 2057.23510742188)

You can see it's not "just" a precision issue, but the minx and miny are off by 10 !

PostGIS 1.5 and 2.0 are immune.

The bogus one is POSTGIS="2.1.0beta3dev r11564"

Change History (9)

comment:1 by robe, 12 years ago

Owner: changed from pramsey to strk

comment:2 by strk, 12 years ago

Paul, any idea ? I haven't touched the stats code except for hushing compiler warnings…

comment:3 by darkblueb, 12 years ago

confirmed in test with

POSTGIS="2.1.0beta3dev r11494" GEOS="3.3.9dev-CAPI-1.7.9" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.8.0" }}}

comment:4 by darkblueb, 12 years ago

observed in

POSTGIS="2.1.0beta3 r11567" GEOS="3.4.0dev-CAPI-1.8.0 r3823" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.10.0, released 2013/04/13" LIBXML="2.8.0" LIBJSON="UNKNOWN" RASTER

comment:5 by pramsey, 12 years ago

Owner: changed from strk to pramsey

comment:6 by pramsey, 12 years ago

Here's the issue:

http://trac.osgeo.org/postgis/browser/trunk/postgis/gserialized_estimate.c#L1416

The thing is, removing this will open other problems, since this was added precisely because edge cases were being lost. At the end of the day, the "estimated" box is 1% larger than the sampled box, which is *itself* smaller than the *actual* box, since… it's a *sample*! The key word here is "estimated". I incline towards leaving thing as they are.

comment:7 by strk, 12 years ago

I don't think it's important for "estimated" bounding box to be larger than the actual one. It's important that it is "about the same as the actual one", based on a sample. If the sample is the whole set, I'd expect the estimated extent to also be the one of the whole set. That's how it worked up to 2.0. Do you have a case for that 1% enlargement ?

comment:8 by robe, 11 years ago

Can I push this forward? to 2.1.1 or you expecting to do something with this like SOON.

comment:9 by robe, 11 years ago

Resolution: wontfix
Status: newclosed

strk pramsey said he doesn't want to bother. Change back if YOU plan to do something about it. Why is this even marked as a blocker?

Note: See TracTickets for help on using tickets.