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

GRASS GIS trac at osgeo.org
Wed Jul 13 05:04:59 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 glynn):

 Replying to [comment:7 mmetz]:

 > 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,

 In the case of r.resamp.filter, each output cell is typically calculated
 based upon a small subset of the input cells, not the entire input.

 > The way I currently use the patched r.series, an option radius would
 only make sense in combination with a multiple option centre.

 It would make sense even for a single output, as it controls how rapidly
 the weight falls off with distance from the centre.

 > > 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.

 AFAICT, the code maps the input range to the width of the window function,
 so wider windows will be "sharper" (have a higher cut-off frequency), e.g.
 lanczos3 will be sharper than lanczos2.

 > It's not clear to me how the term frequency can be applied to a
 gauss/normal distribution,

 r.resamp.filter implements FIR (finite impulse response) filtering (you
 get an error if you don't have at least one finite window function). If
 you calculate the DFT of any of the window functions, you'll get its
 frequency response. All of the functions are low-pass filters, as they're
 symmetric.

 See http://en.wikipedia.org/wiki/Window_function for examples of common
 window functions and their frequency responses.

 A piecewise-continuous function defined by sampled data can be considered
 a mixture (sum) of the underlying signal and quantisation noise. The
 intent of a low pass filter is to discard the quantisation noise while
 retaining the signal.

 The cut-off frequency is normally chosen according to the sampling
 frequency, as the quantisation noise is dominated by the sampling
 frequency and its harmonics. In general, the cut-off frequency is
 inversely proportional to the width of the central "lobe" of the window
 function.

 If you run r.resamp.filter with a specific radius, you get a specific cut-
 off frequency regardless of the method chosen. So while lanczos3 uses 3
 times as large a window as lanczos1, the cut-off frequency remains the
 same. This is what I mean when I say that the radius is "normalised".

 OTOH, if you map the range of inputs to the range of the filter, "long-
 tailed" filters with a wider domain (e.g. lanczos3) will have a narrower
 central lobe and thus a higher cut-off frequency.

 The way that Lanczos filters are defined, the number of samples is
 supposed to be proportional to the order ("a" parameter), so lanczos3
 should use 3 times as many samples (at the same sampling frequency, i.e.
 cover 3 times as large a time interval) as lanczos1 in order to get a
 similar frequency response (higher-order filters will fall off faster, but
 the frequency at which the fall-off starts should be the same).

 See http://en.wikipedia.org/wiki/File:Lanczos-kernel.svg for an
 illustration. If both graphs were drawn on the same axes, they would have
 roughly the same shape, but the a=3 window would have a longer tail. By
 scaling the axes to the same width, the a=3 window has a narrower central
 lobe.

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



More information about the grass-dev mailing list