[GRASS-user] r.series and Fourier
daniel.victoria at gmail.com
Fri Jun 13 08:57:52 EDT 2008
By the looks of it, a separate module would be more reasonable since
it would not add a new dependency, as not everyone needs this type of
Also, it would not mess with the established r.series...
On Fri, Jun 13, 2008 at 9:40 AM, Paulo Marcondes
<paulomarcondes at gmail.com> wrote:
> This should have gone to the list...
> 2008/6/12 Glynn Clements <glynn at gclements.plus.com>:
>> Daniel Victoria wrote:
>> An FFT would produce a series (or two series - real/imag or arg/abs)
>> of outputs. If you just want a single frequency component, you would
>> need to pass the frequency (or period) as an argument, and r.series
>> doesn't support that yet.
>> A secondary issue is that GRASS' FFT function is optional, and is only
>> available if built with the --with-fftw option.
>> So, it's mostly a question of whether to add Fourier support to the
>> existing r.series module, or to add a separate r.series.fft module
>> (which could be based upon r.series).
>> For a separate module, most of the effort required is in
>> specification; if it's known exactly how the module is meant to
>> behave, implementation would be around an hour's work.
> I see Glynn's points as quite reasonable.
> Besides doing fourier over a time series of maps, I think r.series.fft
> or r.fourier would have to do spectral decomposition: generate several
> maps, one for each specified frequency range. maybe inputing max and
> min freq + step size or simply number of spectral slices to take.
> Well, I'm talking spatial frequencies here, the kind that goes [L]^-1
> I am not sure if these functionalities fit in the same module, but,
> since we are talking fourier, I chimed in =]
> Paulo Marcondes = PU1/PU2PIX
> -22.915 -42.224 = GG86jc
> grass-user mailing list
> grass-user at lists.osgeo.org
More information about the grass-user