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