[postgis-devel] [PostGIS] #931: [raster] ST_Mean

[PostGIS]

#931: [raster] ST_Mean
----------------------------+-----------------------------------------------
 Reporter:  dustymugs       |       Owner:  dustymugs            
     Type:  task            |      Status:  new                  
 Priority:  medium          |   Milestone:  PostGIS Raster Future
Component:  postgis raster  |     Version:  trunk                
 Keywords:                  |  
----------------------------+-----------------------------------------------

Comment(by dustymugs):

 Good point on the absolutely obscene coverage.  I think your ST_Mean
 prototype would need to be expanded out to encompass all the other summary
 stat functions, ST_SummaryStats, ST_MinMax and ST_StdDev.

 SELECT ST_Mean('myrastercoveragetable', 'myrastercolumn')

 One thing that does concern me about the prototype above is the lack of
 flexibility in filtering the coverage table on the fly.  Maybe something
 like

 {{{
 CREATE TYPE summarystatsarg AS (
         rast raster,
         nband integer,
         hasnodata boolean,
         sample_percent double precision
 );

 CREATE OR REPLACE FUNCTION st_mean(coveragestats[])
         RETURNS int
         AS $$
         DECLARE
         BEGIN
                 -- some code
         END;
         $$ LANGUAGE 'plpgsql';

 SELECT st_mean((
         SELECT
                 array_agg(stats)
         FROM (
                 SELECT
                         ROW(rast, 1, FALSE, 1)::coveragestats AS stats
                 FROM tmax_2011
                 WHERE observation_date = '2011-05-01'
         ) AS t
 ));
 }}}

 The above would give the user the most amount of flexibility and control
 over what is evaluated in the function.

 I took a look at example 7 of st_histogram.sql and have only one
 comment/note...

 In the implementation I'm thinking of, a weighed mean may work better plus
 it goes hand-in-hand with a weighed standard deviation.

 http://en.wikipedia.org/wiki/Weighted_mean

 As I've been looking at the ST_MinMax function and refactoring it for the
 summary stats, I envision that the summary stats will be the base stats
 function call.  The histogram and quantile functions will depend upon the
 base stats as the histogram needs the min/max values to set the bounds for
 the number of bins and the quantile function needs the ordered series of
 values to determine a percentile's value.  The reason I believe this is
 the right way to go is that the summary stats can be computed in one pass.
 Histograms and quantiles usually require a second pass so I'd rather keep
 them as separate functions that are called if needed.

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/931#comment:4>
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.