[postgis-users] NOTICE: no non-null/empty features, unable to compute statistics

Paul Ramsey pramsey at cleverelephant.ca
Thu Oct 2 09:58:13 PDT 2014 

OK, with the real test data I can reproduce, and the source of the
problem is pretty "obvious" if not the exact place things are going
wrong yet:

                        st_astext
---------------------------------------------------------
 POINT ZM (-124.22007 41.75967 0 -1.79769313486232e+308)
 POINT ZM (-124.22 41.78017 0 -1.79769313486232e+308)
 POINT ZM (-124.21508 41.76429 0 -1.79769313486232e+308)
 POINT ZM (-124.2146 41.75716 0 -1.79769313486232e+308)
 POINT ZM (-124.21434 41.75974 0 -1.79769313486232e+308)
 POINT ZM (-124.21069 41.7646 0 -1.79769313486232e+308)
 POINT ZM (-124.20893 41.76469 0 -1.79769313486232e+308)
 POINT ZM (-124.20851 41.99467 0 -1.79769313486232e+308)
 POINT ZM (-124.20777 41.76345 0 -1.79769313486232e+308)
 POINT ZM (-124.20648 41.7782 0 -1.79769313486232e+308)
 POINT ZM (-124.2054 41.7605 0 -1.79769313486232e+308)
 POINT ZM (-124.20423 41.96717 0 -1.79769313486232e+308)
 POINT ZM (-124.20311 41.75043 0 -1.79769313486232e+308)
 POINT ZM (-124.20148 41.76732 0 -1.79769313486232e+308)
 POINT ZM (-124.18687 41.8712 0 -1.79769313486232e+308)
 POINT ZM (-124.18596 41.78359 0 -1.79769313486232e+308)
 POINT ZM (-124.1704 41.80397 0 -1.79769313486232e+308)
 POINT ZM (-124.16647 41.79744 0 -1.79769313486232e+308)
 POINT ZM (-124.16574 40.78663 0 -1.79769313486232e+308)
 POINT ZM (-124.1657 41.83595 0 -1.79769313486232e+308)
 POINT ZM (-124.16244 40.78586 0 -1.79769313486232e+308)
 POINT ZM (-124.14799 41.74598 0 -1.79769313486232e+308)
 POINT ZM (-124.14756 41.87017 0 -1.79769313486232e+308)
 POINT ZM (-124.14711 40.79334 0 -1.79769313486232e+308)
 POINT ZM (-124.14597 41.75299 0 -1.79769313486232e+308)

Those are some big-ass "M" values. So the problem is almost certainly
with the higher dimensions. Since you aren't using them, a simple
expedient to fix your problem would be to just alter the type to a 2d
point, and then the stats gathering system will work right. It's worth
doing this, since as the NOTICE says, you aren't currently gathering
any stats.

P.


On Wed, Oct 1, 2014 at 3:26 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> Well, trying to synthetically reproduce your error is not working.
>
> Butterfly:~/Code/postgis-svn/postgis pramsey$ vacuumdb -v -Z -d postgis22 -t pts
>
> INFO:  analyzing "public.pts"
>
> INFO:  "pts": scanned 14286 of 14286 pages, containing 1000000 live
> rows and 0 dead rows; 30000 rows in sample, 1000000 estimated total
> rows
>
> I used a basic random table,
>
> CREATE TABLE pts AS
> WITH rands AS (
>   SELECT generate_series as id, random() AS u1, random() AS u2 FROM
> generate_series(1,1000000)
> )
> SELECT
>   id,
>   ST_SetSRID(ST_MakePoint(
>     50 * sqrt(-2 * ln(u1)) * cos(2*pi()*u2),
>     50 * sqrt(-2 * ln(u1)) * sin(2*pi()*u2),
>     50 * sqrt(-2 * ln(u1)) * sin(2*pi()*u2),
>     50 * sqrt(-2 * ln(u1)) *
> sin(2*pi()*u2)),4326)::Geometry(PointZM,4326) AS geom
> FROM rands;
>
> P
>
> On Tue, Sep 23, 2014 at 3:54 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>> I guess in theory I could reproduce it with some random xyz data...
>>
>> P
>>
>> On Tue, Sep 23, 2014 at 1:47 PM, Jason Mathis
>> <jmathis at redzonesoftware.com> wrote:
>>> So unfortunately I did not get the go ahead to share the data, but I solved
>>> the problem. It was a dataset that was merged from several different
>>> datasets which is why I got the “PointZM” from shp2pgsql. I was given a
>>> shape file to load into the database. Although the data just needed to be
>>> two dimensional. I also had the original coordinates, so I drop the column
>>> and re-added with just “POINT” and updated the geometry from the lat/longs
>>> and viola no “notice” message.
>>>
>>> Is it only an issue with three or four dimensional data?
>>>
>>> Thanks,
>>> jason
>>>
>>> On September 22, 2014 at 5:43:43 PM, Paul Ramsey (pramsey at cleverelephant.ca)
>>> wrote:
>>>
>>> If you can share data, I'm happy to try and reproduce it here.
>>>
>>> P
>>>
>>> On Mon, Sep 22, 2014 at 2:01 PM, Jason Mathis
>>> <jmathis at redzonesoftware.com> wrote:
>>>> I am stumped on it. I think i remember seeing something like this before,
>>>> but can’t quite recall.
>>>>
>>>> Queries both return zero.
>>>>
>>>> 'POSTGIS="2.1.3 r12547" GEOS="3.4.2-CAPI-1.8.2 r3921" PROJ="Rel. 4.8.0, 6
>>>> March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6"
>>>> LIBJSON="UNKNOWN" RASTER'
>>>>
>>>> i even tried putting a bogus null row in there but I still got the
>>>> message.
>>>>
>>>> thanks!
>>>>
>>>>
>>>> On September 22, 2014 at 2:52:00 PM, Paul Ramsey
>>>> (pramsey at cleverelephant.ca)
>>>> wrote:
>>>>
>>>> It means it sampled 30000 rows and didn't find any geometries that
>>>> were non-null or non-empty. I suppose it could mean a bug, though that
>>>> code's been around for a while.
>>>>
>>>> select count(*) from yourtable where geom is null;
>>>> select count(*) from yourtable where st_isempty(geom);
>>>> select postgis_full_version();
>>>>
>>>> P.
>>>>
>>>> On Mon, Sep 22, 2014 at 12:11 PM, Jason Mathis
>>>> <jmathis at redzonesoftware.com> wrote:
>>>>> Does anyone know what this “notice” means? I loaded some new data into a
>>>>> table from a shape file.Visually it looks good and loaded without error.
>>>>> I
>>>>> have a nightly analyze job that runs and since loading the data it spits
>>>>> out
>>>>> this “notice” I don’t know what it means. If I drop the geom column I do
>>>>> not
>>>>> get this message. I have tried drop/create the index, and reloading the
>>>>> data without success.
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>>
>>>>> $ /usr/bin/vacuumdb -v -Z -d redzone -t 'demo.homes'
>>>>> INFO: analyzing "demo.homes"
>>>>> INFO: "homes": scanned 2237 of 2237 pages, containing 101937 live rows
>>>>> and
>>>>> 0 dead rows; 30000 rows in sample, 101937 estimated total rows
>>>>> NOTICE: no non-null/empty features, unable to compute statistics
>>>>> NOTICE: no non-null/empty features, unable to compute statistics
>>>>>
>>>>> CREATE TABLE demo.homes
>>>>> (
>>>>> gid integer NOT NULL DEFAULT nextval('demo.homes_gid_seq'::regclass),
>>>>> geolat numeric,
>>>>> geolong numeric,
>>>>> geolevel text,
>>>>> geonumber integer,
>>>>> geostreet text,
>>>>> geocity text,
>>>>> geocounty text,
>>>>> geostate text,
>>>>> zip text,
>>>>> firstname text,
>>>>> lastname text,
>>>>> tiv integer,
>>>>> geom geometry(PointZM,4326),
>>>>> CONSTRAINT homes_pkey PRIMARY KEY (gid)
>>>>> )
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This transmission contains confidential and privileged information
>>>>> intended
>>>>> solely for the party identified above. If you receive this message in
>>>>> error,
>>>>> you must not use it or convey it to others. Please destroy it immediately
>>>>> and contact the sender at (303) 386-3955 or by return e-mail to the
>>>>> sender.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> postgis-users mailing list
>>>>> postgis-users at lists.osgeo.org
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at lists.osgeo.org
>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>>
>>>>
>>>> This transmission contains confidential and privileged information
>>>> intended
>>>> solely for the party identified above. If you receive this message in
>>>> error,
>>>> you must not use it or convey it to others. Please destroy it immediately
>>>> and contact the sender at (303) 386-3955 or by return e-mail to the
>>>> sender.
>>>
>>>
>>> This transmission contains confidential and privileged information intended
>>> solely for the party identified above. If you receive this message in error,
>>> you must not use it or convey it to others. Please destroy it immediately
>>> and contact the sender at (303) 386-3955 or by return e-mail to the sender.

More information about the postgis-users mailing list