[GRASS-user] Aggregating daily maps in relative strds per month

[Nikos Alexandris]

* Veronica Andreo <veroandreo at gmail.com> [2015-05-18 06:07:24 -0300]:

> Ciao Nikos, again :)
> 
> In case of relative time the temporal unit of the input space time raster
> dataset is used. The granularity must be specified with an integer value.
> 
> > If the data in fact represent daily data, why don't you register it as
> > > absolute time?? In that way, you would just loop over strds...

I have to decide for which year. And, with global irradiation, I am not
sure it makes sense.  An expert opinion would help here.



> > It is output from r.sun.daily.  Below, looping over monthly Linke
> > Turbidity values.
> >
> > --%<---
> > for LINE in `cat monthly_linke_map_start_day_end_day.csv`
> > do
> >
> >     set -- $(echo ${LINE} |tr "|" " ")
> >
> >     r.sun.daily elevation=srtm4 at PERMANENT aspect_value=0 slope_value=0.0 \
> >     albedo=albedo at albedo linke=$1 at linke start_day=$2 end_day=$3 \
> >     glob_rad_basename=global_rad_zero insol_time_basename=insol_time \
> >     beam_rad_basename=beam_rad_zero diff_rad_basename=diff_rad_zero --o
> >
> > done
> > --->%--
> >
> > The script creates automatically
> > an "relative" strds, and for a good reason I guess.  I can't think which
> > of the input's, for r.sun.daily, would fit for an absolute timestamping.
> >
> > For sure it's not going to be the elevation model.  Linke Turbidity and
> > albeo also not.  Any help is highly appreciated if there is something
> > for which an absolute timestamping can be justified.
> >
> 
> Never used this add-on but I see now it creates a strds with relative time.
> it seems you cannot change that, yo can't specify anywhere an absolute
> time, that's right.

Well, I can.  In fact I have added missing options (and will update the
add-on once I have done tests and someone else confirms it's ok). But, I
think it doesn't make sense.



> But as then you don't have a constant granularity to
> aggregate data, cos in fact you want to aggregate it as monthly absolute
> data (otherwise you'd just use an integer number, i.e.: 10, 20, 30,
> whatever)... I would take maps in the output of r.sun daily and register
> them in another strds (with absolute time) and then aggregate monthly...
> 
> for STRDS in global_rad_zero beam_rad_zero diff_rad_zero insol_time
> 
> t.create type=strds temporaltype=absolute output=${STRDS} title="bla"
> description="bla" --o
> 
> t.register -i type=rast input=${STRDS} maps=`g.list rast pat=${STRDS}*
> sep=,` start="2003-01-01" increment="1 day"
> # or whatever pattern you use, or a list of ordered maps

Right, this "start" is the "missing" key.



> # then the aggregation
> t.rast.aggregate input=${STRDS} output=${STRDS}_monthly_average
> basename=${STRDS}_average granularity="1 month" method=average
> 
> done
> 
> just an idea...
> or use your script as it was :)

Right.  Thanks for your tutorial in the Wiki. It got me going in
no-time.  Amazing work.


 
> > for STRDS in global_rad_zero beam_rad_zero diff_rad_zero insol_time
> > > do
> > > t.rast.aggregate input=${STRDS} output=${STRDS}_monthly_average
> > > basename=${STRDS}_average granularity="1 month" method=average
> > > done
> >
> > So, the above won't work :-(.  I don't know how bad the idea of having
> > preset months (start and end days for such cases) to operate on relative
> > s-t data sets.
> >
> 
> dunno... thing is, in relative time, how do you know for every possible
> case at which point does a month start... i mean, for that, you have
> absolute time, right? Maybe, r.sun.daily could output an absolute time
> strds... don't know if it's feasible though

Correct.  I'll just keep on working manually for the time being.



> > Plus, an idea I already expressed elsewhere in the list:  will it be
> > useful to have support for multiple LinkeT maps?  Not sure how the
> > implementation should look like yet.
> >
> > > Cheers,
> > > Vero
> >
> > Thanks for caring, Nikos
> >
> 
> Niente! Not so useful though :)
> Cheers,
> Vero

The discussion forces me to clear my understanding. So, very useful
actually.

Ciao-ciao!