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