<div dir="ltr">Ciao Nikos, again :)<div><br></div><div>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.<br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> If the data in fact represent daily data, why don't you register it as<br>
> absolute time?? In that way, you would just loop over strds...<br>
<br>
</span>It is output from r.sun.daily. Below, looping over monthly Linke<br>
Turbidity values.<br>
<br>
--%<---<br>
for LINE in `cat monthly_linke_map_start_day_end_day.csv`<br>
do<br>
<span><br>
set -- $(echo ${LINE} |tr "|" " ")<br>
<br>
</span> r.sun.daily elevation=srtm4@PERMANENT aspect_value=0 slope_value=0.0 \<br>
albedo=albedo@albedo linke=$1@linke start_day=$2 end_day=$3 \<br>
glob_rad_basename=global_rad_zero insol_time_basename=insol_time \<br>
beam_rad_basename=beam_rad_zero diff_rad_basename=diff_rad_zero --o<br>
<br>
done<br>
--->%--<br>
<br>The script creates automatically<br>
an "relative" strds, and for a good reason I guess. I can't think which<br>
of the input's, for r.sun.daily, would fit for an absolute timestamping.<br>
<br>
For sure it's not going to be the elevation model. Linke Turbidity and<br>
albeo also not. Any help is highly appreciated if there is something<br>
for which an absolute timestamping can be justified.<br></blockquote><div><br></div><div>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. 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... </div><div><br></div><div>for STRDS in global_rad_zero beam_rad_zero diff_rad_zero insol_time<br></div><div><br></div><div>t.create type=strds temporaltype=absolute output=${STRDS} title="bla" description="bla" --o</div><div><br></div><div>t.register -i type=rast input=${STRDS} maps=`g.list rast pat=${STRDS}* sep=,` start="2003-01-01" increment="1 day"</div><div># or whatever pattern you use, or a list of ordered maps</div><div><br></div><div># then the aggregation</div><div><div>t.rast.aggregate input=${STRDS} output=${STRDS}_monthly_average basename=${STRDS}_average granularity="1 month" method=average</div></div><div><br></div><div>done</div><div><br></div><div>just an idea...</div><div>or use your script as it was :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>> for STRDS in global_rad_zero beam_rad_zero diff_rad_zero insol_time<br>
> do<br>
> t.rast.aggregate input=${STRDS} output=${STRDS}_monthly_average<br>
> basename=${STRDS}_average granularity="1 month" method=average<br>
> done<br>
<br>
</span>So, the above won't work :-(. I don't know how bad the idea of having<br>
preset months (start and end days for such cases) to operate on relative<br>
s-t data sets.<br></blockquote><div> </div><div>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</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Plus, an idea I already expressed elsewhere in the list: will it be<br>
useful to have support for multiple LinkeT maps? Not sure how the<br>
implementation should look like yet.<br>
<br>> Cheers,<br>
> Vero<br>
<br>
Thanks for caring, Nikos <br></blockquote><div><br></div><div>Niente! Not so useful though :)</div><div>Cheers, </div><div>Vero </div></div></div></div></div>