[GRASS-dev] Re: [GRASS GIS] #1401: r.series for time series

GRASS GIS trac at osgeo.org
Tue Jul 12 06:27:27 EDT 2011


#1401: r.series for time series
---------------------------------+------------------------------------------
 Reporter:  mmetz                |       Owner:  grass-dev@…              
     Type:  enhancement          |      Status:  new                      
 Priority:  normal               |   Milestone:  7.0.0                    
Component:  Raster               |     Version:  svn-trunk                
 Keywords:  raster, time series  |    Platform:  All                      
      Cpu:  All                  |  
---------------------------------+------------------------------------------

Comment(by mmetz):

 Replying to [comment:6 glynn]:
 >
 > Okay, so you're filtering in the time domain, then taking a single
 sample from the middle of the interval?

 I calculate the weighed average for a given point in time from a given
 time interval, same like r.resamp.filter calculates the weighed average
 for a given point in space from a given space interval, e.g.
 r.resamp.filter/main.c:L268,269,276 and w_ave() in lib/stats/c_ave.c.
 r.resamp.filter could just as well use w_ave() for each dimension. In the
 patch, the point in time is in the middle of the interval. Since there is
 no multiple centre option (yet), I guess this is what you mean with taking
 a single sample which is located in the middle of the interval.
 >
 > Even so, I would suggest making the "radius" (i.e. cut-off frequency) a
 parameter, and probably also the centre (although that can be fudged by
 padding with null maps).
 >
 The radius is currently determined by the number of input maps. Additional
 options radius and centre would clearly speed up processing when several
 different outputs are needed for different points in time. The way I
 currently use the patched r.series, an option radius would only make sense
 in combination with a multiple option centre. The number of outputs would
 then be n_methods x n_centres.

 > In general, the cut-off frequency shouldn't depend upon the filtering
 method; the reason the various filters in r.resamp.filter have associated
 radii is so that the cut-off frequency doesn't vary with the filter method
 (i.e. the user-supplied radius value is normalised).

 AFAICT, the patch does the same, the user-supplied radius is normalised.
 It's not clear to me how the term frequency can be applied to a
 gauss/normal distribution, for the sine and cosine-based filters this is
 obvious. The associated radii for gauss and normal are chosen such that
 filter(dx) is nearly 0 for dx = user-radius in order to be comparable with
 lanczos, hermite or cosine-based filters where cos(normalised_dx) = 0 for
 dx = user-radius. IOW, the gauss filter in r.resamp.filter sets the user-
 radius to 1 SD (soft filter), and the gauss filter in the patch for
 r.series sets the user-radius to 4 SD (sharper filter), granted that
 f_gauss() assumes SD = 1 which I am not sure about. It looks more like SD
 = 1/4, and for f_normal(), SD = 1/2 in the exponent and SD = 1 in the
 square root?

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1401#comment:7>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list