[GRASS5] r.series: was [glynn.clements@virgin.net: [GRASSLIST:4665] Re: sum in r.mapcalc]

[Helena Mitasova]

Glynn,

this sounds quite exciting - we have lots of time series both from models and
from monitoring -
I can put them on the web if you would like to use them for testing. We can
do some testing here too.

Helena

Markus Neteler wrote:

> Hi,
>
> an interesting posting from grasslist at baylor.edu.
> (some of the developers are not on that list)
>
> Markus
>
>   ------------------------------------------------------------------------
>
> Subject: [GRASSLIST:4665] Re: sum in r.mapcalc
> Date: Mon, 7 Oct 2002 01:37:55 +0100
> From: Glynn Clements <glynn.clements at virgin.net>
> To: Martin Wegmann <m.wegmann at web.de>
> CC: GRASSLIST(eng.) <GRASSLIST at baylor.edu>
>
> Martin Wegmann wrote:
>
> > In respond to Glynn's suggestion of further functions for r.mapcalc,
> > it would be great if there would be more possibilities to analyse time
> > series (each single cell of each raster in the series).
> >
> > An equivalent of r.neighbors (all functions for core and surrounding
> > pixel) could be very useful for (my) time series analysis.
> >
> > Would it also be possible to add a linear regression model to
> > r.mapcalc for time series, to analyse the tendency of each pixel over
> > time (if the value is in- or decreasing)?
>
> Well, r.mapcalc probably isn't the right tool for the job. The main
> problem is that an expression has a fixed number of inputs. r.mapcalc
> doesn't support lists/arrays or loops, which would be necessary for
> constructing expressions which operate on a variable number of maps.
>
> I have recently committed to CVS a basic time series tool, which
> supports the same set of aggregates as r.neighbors (except
> interspersion, which doesn't seem applicable to time series).
>
> However:
>
> 1. I haven't had chance to test it yet; I need to either find or
> generate some test data.
>
> 2. I'm still not sure of a couple of the architectural issues.
>
> Currently, null (no data) cells are automatically excluded, although
> it might be better to pass them to the aggregate functions (this means
> slightly more code in each function, and is of no use to the existing
> functions, but it would allow for future aggregates which might make
> use of it).
>
> Also, I'm wondering if it would be worthwhile to deal with the actual
> timestamps (again, this wouldn't be of any use for the existing
> aggregates, but might for future extensions, e.g. linear regression).
>
> --
> Glynn Clements <glynn.clements at virgin.net>