Hi,
an interesting posting from grasslist@baylor.edu.
(some of the developers are not on that list)
Markus
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@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@virgin.net>
To: Martin Wegmann <m.wegmann@web.de>
CC: GRASSLIST(eng.) <GRASSLIST@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@virgin.net>
Helena Mitasova wrote:
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.
OK. The code has been committed to the head as src/raster/r.series.
Regarding test data, the main issue is the size; I don't want to have
to download a large amount of data as reliability testing can be
performed with low-resolution maps just as easily.
It would also be useful to have feedback from people who (unlike me)
actually have practical applications for such a tool.
--
Glynn Clements <glynn.clements@virgin.net>