[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