A friend of mine asked me if it would be possible to do a Fourier
analysis on a raster time series with Grass (or any other tool). Since
I'm no expert in Fourier or time series the first thing that came to
my mind was to send the grass rasters to R and do the processing
there. But then I remember the r.series command. Is ti possible to add
this type o analysis in the method list? Is it correct (mathematically
I mean) to apply the fourier analysis in a raster time series? Has
anyone done this?
Thanks
Daniel
PS - If this works I'll have a good chance at promoting Grass in a
very high level Brazilian research company
2008/6/12 Daniel Victoria <daniel.victoria@gmail.com>:
this type o analysis in the method list? Is it correct (mathematically
I mean) to apply the fourier analysis in a raster time series? Has
anyone done this?
Daniel,
If I understood right, well,
It is possible/ correct to apply fourier decomposition to any series,
regardless of domain (time or otherwise)
Would you mind to tell the name of the company?
--
Paulo Marcondes = PU1/PU2PIX
-22.915 -42.224 = GG86jc
A friend of mine asked me if it would be possible to do a Fourier
analysis on a raster time series with Grass (or any other tool). Since
I'm no expert in Fourier or time series the first thing that came to
my mind was to send the grass rasters to R and do the processing
there. But then I remember the r.series command. Is ti possible to add
this type o analysis in the method list? Is it correct (mathematically
I mean) to apply the fourier analysis in a raster time series? Has
anyone done this?
The main issue is that all of the existing r.series methods take a
series of input maps and produce a single output map.
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.
[Such a feature would also be useful for quantiles, rather than being
limited to median (50%), quart1 (25%), quart3 (75%) and perc90 (90%).]
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.
For inclusion into the existing r.series, the main issue is resisting
the temptation to add a bunch of other enhancements at the same time
(e.g. being able to generate multiple outputs in one run, arbitrary
quantiles, etc).
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
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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
