[GRASSLIST:4667] Re: sum in r.mapcalc

[Martin Wegmann]

the time series tool sounds great, if I can contribute to it perhaps with test data, sorry no programming skills yet, please let me know.

I also wonder if there already exists or if not if it would be possible or useful to implement in a forthcoming version of your time series tool a function for invariant target 
analysis. This analysis would allow to compare actual pixelvalues of different images (different location or time). 
It is a correction of all bands of each images to a reference image. It is basically a regression analysis of all bands on base of invariant targets (deep water, beach sand, 
etc.). 
A timestamp wouldn't be necessary for this type of analysis but of course it would be really useful for further time series analysis.









7/10/2002 10:07:55 AM, Glynn Clements <glynn.clements at virgin.net> wrote:

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













-------------------------------

Martin Wegmann
Tropical Ecosystem Research Center
PMB 44 Winnellie / Darwin
NT 0821
Australia

.......

priv.
4 Carpentier Cres.
Wagaman / Darwin
NT 0810
Autralia
0061 8 8927 1241