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

[GRASS GIS]

#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:9 mmetz]:

 > I was reading up a bit and thinking about it. As I understand it, the
 fundamental difference between r.resamp.filter and the patched r.series is
 that for r.resamp.filter, the window size is a function of the user-given
 radius and the chosen (combination of) filtering window(s), whereas for
 r.series, the radius is a function of the chosen window size (number of
 input maps) and the filtering window.

 A more fundamental difference is that r.resamp.filter performs convolution
 (i.e. a weighted sum is calculated for every cell), while r.series
 calculates a single value. The main reason why r.resamp.filter raises an
 error for an unbounded window is that it's almost certainly a user error.
 A secondary reason is that it's ridiculously slow; if there was a use for
 such cases, an FFT-based implementation would be needed.

 In theory, convolution calculates an unbounded integral (or, in the
 discrete case, an infinite sum). The window size is merely an optimisation
 (there's no point in summing an infinite number of zeros), and shouldn't
 affect the result.

 > The reason for my implementation is a simpler user-interface. Otherwise,
 i.e. with a required option radius, warning/error messages are needed if
 the number of input maps exceeds or is smaller than the window size.

 It's perfectly reasonable for the domain of the filter function to extend
 beyond the set of input maps, particularly for a "wide" filter such as
 lanczos3 or gauss. The correct solution is to simply clip the kernel to
 the window (and calculate the divisor accordingly), not to "squash" the
 kernel to fit the input range.

 > And I wanted an easy way to test various filters with differing
 sharpness (e.g. lanczos1 vs. lanczos3) using the same window size.

 The various Lanczos filters should all have the same sharpness; higher-
 order filters should just be more accurate at the cost of performance.
 That is why the width of the filter's domain and the number of input
 samples shouldn't affect the result.

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