[GRASS-user] r.series and Fourier

[Daniel Victoria]

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
analysis.

Also, it would not mess with the established r.series...

Daniel

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
> http://lists.osgeo.org/mailman/listinfo/grass-user
>