Posts | Veronica Andreo

Outcomes of an online GRASS GIS course

Mon, 24 May 2021 00:00:00 +0000

In March 2021, I taught a GRASS GIS online workshop as part of the distance learning offer of Gulich Institute (CONAE - UNC) in Argentina. We had a total of 65 students from different countries in South America.

During the workshop, we studied different topics within GRASS ecosystem, but we mostly covered remote sensing, Object Based Image Analysis (OBIA) and time series analysis, making use of GRASS GIS extensions to obtain and process Landsat, Sentinel and MODIS data. All the workshop materials, including presentations, code, and data, are available here (in Spanish).

As final assignment to pass the course and get their certificate, students were given two options:

write a report in Spanish for which they should pick a topic of interest, find relevant data and use GRASS modules to obtain results or,
write a tutorial in English of a topic relevant for them or even something new they wanted to learn, always with GRASS as main tool/focus.

As an incentive, the best reports and tutorials would be given the chance to be presented live through Gulich Institute Youtube channel. Tutorials, because of the extra difficulty of language, would also be highlighted in GRASS GIS website and social media (See the news here).

The topics chosen by the students were diverse and really interesting: from changes in snow cover in southern Argentina, to productivity of high altitude grasslands, wildfire simulations, segmentation to aid digitizing of implanted forests, network analysis, comparison of classification approaches to map urban areas, landscape characterization, urban heat islands, spatial and temporal gap-filling and species identification through OBIA and machine learning.

On May 14, those reports and tutorials that resulted selected were presented live with an audience of almost 90 people. It was really satisfying to witness the student’s learning process and outcome. Many of them overcame installation difficulties, learnt and studied new modules, searched for data, explored different solutions. Some, even moved to Linux and learnt to use Git/GitHub. Have a look 🤓

With this post I would like to encourage others to follow such an approach that resulted rewarding in many aspects. For students to get their work showcased, for their families to see aunt/uncle, mum or dad on the screen (we had some very sweet messages in the online chat 😃), and also for us as teachers/trainers. Furthermore, I believe these events bring science, higher education and technology closer to the general public and… we never know who might be inspired by our work! 😍

Working with i.landsat in GRASS GIS

Tue, 05 Jan 2021 00:00:00 +0000

In this tutorial, I’ll exemplify different uses of the freshly created i.landsat toolset and its integration with other GRASS GIS core modules and add-ons for a full workflow to process Landsat data.

First of all, to be able to connect to EarthExplorer you’ll need a user name and password. If you are not yet registered, please see the register page for signing up. Then, create a plain text file with your credentials:

myusername
mypassword

We will work in the landsat mapset within the North Carolina full sample location. We first start GRASS GIS and set the computational region to one of the existent landsat bands there:

# start grass in landsat mapset
grass78 grassdata/nc_spm_08_grass7/landsat/

# list available raster maps
g.list type=raster mapset=.

# set the computational region
g.region -p raster=lsat7_2000_40

# display the RGB
d.mon wx0
d.rgb red=lsat7_2000_30 green=lsat7_2000_20 blue=lsat7_2000_10

Next step is to install the i.landsat toolset via g.extension as shown below

The module i.landsat.download allows to search and download Collection 1 Landsat TM, ETM and OLI data from USGS EarthExplorer through the landsatxplore Python library.

In this example, we will retrieve scenes which footprint intersects the current computational region extent. Note however that the area of interest can be optionally defined by a vector map.

If we have a look at the metadata, the Landsat 7 data already in the sample location is dated March 31, 2000.

r.info map=lsat7_2000_40

Hence, to perform change detection we should search for scenes from the same time of the year, but in this example, for 2010 and 2020. We’ll first use the -l flag to only list available Landsat data.

# 2010 - Landsat TM
i.landsat.download -l settings=credentials.txt \
    dataset=LANDSAT_TM_C1 clouds=5 \
    start='2010-02-01' end='2010-04-30'
# 3 scenes found.
# LT50160352010078PAC01 LT05_L1TP_016035_20100319_20160904_01_T1 2010-03-19 0.00
# LT50150352010119GNC01 LT05_L1TP_015035_20100429_20160901_01_T1 2010-04-29 0.00
# LT50160352010094EDC00 LT05_L1TP_016035_20100404_20160903_01_T1 2010-04-04 4.00

#2020
i.landsat.download -l settings=credentials.txt \
    dataset=LANDSAT_8_C1 clouds=5 \
    start='2020-02-01' end='2020-04-30'
# 1 scenes found.
# LC80160352020058LGN00 LC08_L1TP_016035_20200227_20200313_01_T1 2020-02-27 0.37

We’ll download the scenes from March 19, 2010 and February 27, 2020, which is the only one found with the search criteria we set. To download only the selected scenes, we’ll pass their IDs via the id option.

i.landsat.download settings=credentials.txt \
  id=LT50160352010078PAC01,LC80160352020058LGN00 \
  output=landsat_data

Now that we have downloaded the Landsat scenes, we need to import them into GRASS GIS. For that purpose we use the second module in the toolset: i.landsat.import. By default, it imports all Landsat bands within the scene files found in the input directory. In this case, we’ll keep this option, but since we are only interested in the region defined by the Landsat bands already present in the mapset, we’ll limit the import with extent=region. Furthermore, since Landsat data comes in UTM coordinate reference system, we’ll need to re-project the data. This will be done during import by means of r.import when we set the -r flag. Let’s first have a look at the files that will be imported:

# print all landsat bands to import within the landsat_data folder
i.landsat.import -p input=landsat_data
# /landsat_data/LT05_L1TP_016035_20100319_20160904_01_T1_B7.TIF 0 (EPSG: 32617)
# /landsat_data/LT05_L1TP_016035_20100319_20160904_01_T1_B6.TIF 0 (EPSG: 32617)
# /landsat_data/LT05_L1TP_016035_20100319_20160904_01_T1_B5.TIF 0 (EPSG: 32617)
# /landsat_data/LT05_L1TP_016035_20100319_20160904_01_T1_B4.TIF 0 (EPSG: 32617)
# ...
# /landsat_data/LC08_L1TP_016035_20200227_20200313_01_T1_B7.TIF 0 (EPSG: 32617)
# /landsat_data/LC08_L1TP_016035_20200227_20200313_01_T1_B6.TIF 0 (EPSG: 32617)
# /landsat_data/LC08_L1TP_016035_20200227_20200313_01_T1_B5.TIF 0 (EPSG: 32617)

Now, we actually import the data and check the list of imported maps:

# import all bands, subset to region setting and reproject on the fly
i.landsat.import -r input=landsat_data extent=region

# list raster maps
g.list type=raster mapset=.

Let’s also check the metadata and display the respective RGB combinations.

# check metadata
r.info LT05_L1TP_016035_20100319_20160904_01_T1_B3

First, we set all color tables to grey and perform color enhancing for a better visualization

i.colors.enhance \
  red=LT05_L1TP_016035_20100319_20160904_01_T1_B3 \
  green=LT05_L1TP_016035_20100319_20160904_01_T1_B2 \
  blue=LT05_L1TP_016035_20100319_20160904_01_T1_B1

i.colors.enhance \
  red=LC08_L1TP_016035_20200227_20200313_01_T1_B4 \
  green=LC08_L1TP_016035_20200227_20200313_01_T1_B3 \
  blue=LC08_L1TP_016035_20200227_20200313_01_T1_B2

And then we can use either the main GUI or the interactive monitors called from the terminal as follows:

d.mon wx0
d.rgb red=LT05_L1TP_016035_20100319_20160904_01_T1_B3 \
  green=LT05_L1TP_016035_20100319_20160904_01_T1_B2 \
  blue=LT05_L1TP_016035_20100319_20160904_01_T1_B1

d.mon wx1
d.rgb red=LC08_L1TP_016035_20200227_20200313_01_T1_B4 \
  green=LC08_L1TP_016035_20200227_20200313_01_T1_B3 \
  blue=LC08_L1TP_016035_20200227_20200313_01_T1_B2

Since we are interested in performing change detection among two different dates, we need to perform atmospheric correction first. To that aim, we use the i.landsat.toar module. In this case, we use the simple DOS algorithm but a more sophisticated method is provided in i.atcorr.

i.landsat.toar input=LT05_L1TP_016035_20100319_20160904_01_T1_B \
  output=LT05_L1TP_016035_20100319_toar_B \
  sensor=tm5 \
  metfile=LT05_L1TP_016035_20100319_20160904_01_T1_MTL.txt \
  method=dos1

i.landsat.toar input=LC08_L1TP_016035_20200227_20200313_01_T1_B \
  output=LC08_L1TP_016035_20200227_toar_B \
  sensor=oli8 \
  metfile=LC08_L1TP_016035_20200227_20200313_01_T1_MTL.txt \
  method=dos1

Now, we’ll estimate the tasseled cap transformation with i.tasscap. The tasseled cap transformation is effectively a compression method to reduce multiple spectral data into a few bands. The method was originally developed for understanding important phenomena of crop development in spectral space. It is generally accepted that the first component is brightness, the second greennes and the third one, wetness.

i.tasscap \
  input=LT05_L1TP_016035_20100319_toar_B1,LT05_L1TP_016035_20100319_toar_B2,LT05_L1TP_016035_20100319_toar_B3,LT05_L1TP_016035_20100319_toar_B4,LT05_L1TP_016035_20100319_toar_B5,LT05_L1TP_016035_20100319_toar_B7 \
  output=L5_2010_tasscap \
  sensor=landsat5_tm

i.tasscap \
  input=LC08_L1TP_016035_20200227_toar_B2,LC08_L1TP_016035_20200227_toar_B3,LC08_L1TP_016035_20200227_toar_B4,LC08_L1TP_016035_20200227_toar_B5,LC08_L1TP_016035_20200227_toar_B6,LC08_L1TP_016035_20200227_toar_B7 \
  output=L8_2020_tasscap \
  sensor=landsat8_oli

Finally, we use the change vector analysis (CVA), a common method to perform the change detection analysis, by providing the brightness and greenness features of the tasseled cap transform we just did. As input for CVA, two maps for each date must be given: in general, on the X axis an indicator of overall reflectance and on the Y axis an indicator of vegetation conditions. Hence, our choice for components 1 and 2 of tasseled cap.

i.cva \
  xaraster=L5_2010_tasscap.1 xbraster=L8_2020_tasscap.1 \
  yaraster=L5_2010_tasscap.2 ybraster=L8_2020_tasscap.2 \
  output=CVA_2010_2020 stat_threshold=1

As an output, we obtain 4 maps:

angle: map of the angles of the change vector between the two dates;
angle_class: map of the angles, classified in four quadrants (0-90, 90-180, 180-270, 270-360);
magnitude: map of the magnitudes of the change vector between the two dates;
change: final map of change

The change map is created using the classified angle map and applying a threshold to the magnitude. Pixels that have values higher than the threshold are divided in four categories depending on the quadrant they belong to. In this case, with default options, we detect only one type of change shown in yellow below. Have a look at Karnieli et al. 2014 for a conceptual diagram explaining the different types of changes.

From zero to contributing an add-on for GRASS GIS

Wed, 30 Dec 2020 00:00:00 +0000

Eight years ago, while doing an MSc in Remote Sensing and GIS Applications at the Argentinean Space Agency - CONAE, I was looking for places where to do a 6-months internship in Italy. I wanted to go completely FOSS and I had heard about GRASS GIS, but hadn’t made the time to learn it until then. That was when I recalled a former colleague from university mentioning the keywords GRASS and Markus Neteler. Well, I wrote to him and ended up in Trento by January, 2013 (the pic is not from January of course!).

From the beginning, I was determined to learn the command line way of GRASS-ing. Luckily, during the internship at the former PGIS in FEM, I got a lot of support and had the chance to participate in code sprints, conferences and meet several GRASS GIS core devs and power users. I really loved the software but I got hooked by the community behind it 🤗

Once back in Argentina, the MSc thesis was a great excuse to learn and test the freshly developed temporal framework and some basic bash to write simple scripts. I always received a lot of support from devs and other users in the mailing list. Please take into account that my background is Biology and I had zero coding/programming before this… for me, each step was a huge step!

From everything I worked on for the MSc thesis, I compiled the Temporal Data Processing wiki page and some others that came later. That wiki has been accessed 127,853 times as of today 30/12/2020! Impressive, eh?

With time, I learnt to create diffs which I was sending to other devs so they would merge into the source code. It was mostly documentation, but hey, one must start somewhere, no? Eventually, I became so “bothersome” 😇, that they proposed me as core dev! 🤓 I was given permission to mess up the source code 😱 I didn’t, don’t worry! That same year I was nominated as OSGeo charter member. By then, I had already taught some GRASS GIS workshops and courses here and there and also organized a code sprint at my house!

While preparing material for those workshops and courses, I started learning git. This helped me to be (more or less!) ready when GRASS moved from svn to GitHub. Furthermore, after setting up my own website with Hugo and the Academic theme, I became pretty familiar with such a technology. This lead to a strong involvement in the new GRASS website that we launched by mid 2020 for GRASS birthday.

By November, I thought it was time to challenge myself with writing an add-on for my favorite software. I learnt a little bit of Python and found something that could be useful to have: a toolset to search, download and import Landsat data into GRASS GIS. The availability of similar modules helped a lot, I had examples to learn from. I received a lot of motivation and help from other devs in the process. Finally, some days ago, I decided the toolset was ready to be shared and I committed it to the official add-ons repo 😱 and there it is the i.landsat toolset containing 2 modules: i.landsat.download and i.landsat.import! And my name in a piece of code that everyone can use, review and modify 🤩

This experience has definitely reinforced my feeling of belonging to this great community. And, as if all that was not enough, a week ago I was nominated for the PSC (GRASS GIS Project Steering Committee)! What a nice ride so far! 😅

If I could, I’m sure everyone can!! GRASS GIS will welcome you, come and join!

pymodis, GDAL and GRASS GIS: A FOSS4G example to build time series of MODIS data

Wed, 28 Dec 2016 20:49:34 +0000

Recently, the National Aeronautics and Space Administration (NASA) has re-processed all the MODIS archive and made available the sixth version for all land products. In this post, I share a script that combines different FOSS4G tools to download, mosaic, re-project, subset, import, apply quality assessment flags and build a time series of MODIS LST daily products. First, we use the pymodis tool modis_download to automatically download 4 tiles of the MOD11A1 product for the period 2010-2016. Note that you need to register yourself at https://urs.earthdata.nasa.gov/users/new and enable the applications at https://urs.earthdata.nasa.gov/home to be able to download MODIS land products.

# Download MOD11A1.006 - daily land surface temperature (1km) 
modis_download.py -P your_password -U your_user -s MOLT -p MOD11A1.006 -t h19v04,h19v05,h20v04,h20v05 -f 2010-01-01 -e 2016-12-31 .

Then, we use modis_mosaic to build daily mosaics for LST Day and QC Day bands by means of VRT files.

modis_mosaic.py -v -s "1 1 0 0 0 0 0 0 0 0 0 0" list_of_files.txt

After that, we re-project the mosaics to EPSG 3035 and convert them to GTiff format with modis_convert.

# cut the first part of the filename containing date (year+doy): A2015365 
LIST_DATES=`ls *.vrt | cut -d'_' -f1` 

for DAY in $LIST_DATES ; do 
  # convert to tif and project 
  modis_convert.py -g 1000 -e 3035 -v -s "(1)" -o ${DAY}_LST_Day_1km_mosaic ${DAY}_None_LST_Day_1km.vrt 
done

Once we have the tif files, we perform a spatial subset for our area of interest. For this purpose, we combine the GRASS command g.region and the possibility to use eval command with gdal_translate utility from GDAL/OGR library.

# set region 
g.region -p region=your_study_area 
eval `g.region -g` 

for DAY in $LIST_DATES ; do 
  # spatial subseting 
  gdal_translate -of GTiff -projwin $w $n $e $s ${DAY}_LST_Day_1km_mosaic.tif ${DAY}_LST_Day_1km_subset.tif 
done

Once the subset is done, we import the resulting maps into our GRASS database with r.in.gdal, and we remove all VRT, HDF and TIF files.

for DAY in $LIST_DATES ; do 
  # import into GRASS 
  r.in.gdal input=${DAY}_LST_Day_1km_subset.tif output=${DAY}_LST_Day_1km 
  
  # remove vrt, tiff and hdf files 
  rm -f ${DAY}_None_LST_Day_1km.vrt ${DAY}_None_LST_Day_1km_mosaic.tif ${DAY}_LST_Day_1km_subset.tif 
done

We then use i.modis.qc to get QC flags for LST and apply them as in Metz et al. (2014) to keep the highest quality data.

for map in `g.list type=raster pattern=*_QC_*` ; do 
  i.modis.qc input=${map} output=${map}_mandatory_qa productname=mod11A1 qcname=mandatory_qa_11A1 
  i.modis.qc input=${map} output=${map}_lst_error_qa productname=mod11A1 qcname=lst_error_11A1 
done

list_lst=`g.list rast pat=*LST_Day_1km` 

for m in ${list_lst} ; do 
  # cut common part of filenames 
  i=`echo $m | cut -c 1-23` 
  r.mapcalc --o expression="${m} = if(${i}_mandatory_qa < 2 && ${i}_lst_error_qa == 0, ${m}, null())" 
done

With all the former steps done, we can build a daily time series for LST data…

t.create type=strds temporaltype=absolute \
  output=LST_Day_daily \
  title="LST Day 1km MOD11A1.006" \
  description="Daily LST Day 1km MOD11A1.006, 2010-2016" 

g.list rast pattern=*LST_Day output=filelist_lst.txt 

t.register -i input=LST_${lst}_greece_daily \
  file=filelist_lst.txt \
  start="2010-01-01" \
  increment="1 day"

and you are ready to play! You may, for example, use the GRASS Add-ons r.hants or r.series.lwr to reconstruct/fill the gaps in the time series and then, you have a whole set of temporal modules at your fingertips to perform different tasks. You can check the Temporal Data Processing wiki for several examples.

Extra: The extra beauty of all this, is that it is possible to run all these steps as a script with the new --exec interface of GRASS GIS. For example, if you name your script lst_processing.sh (do not forget to write the shebang in the beginning of the file: #!/bin/bash), then, you can run it in a non-interactive GRASS session as:

grass78 /path/to/grassdata/location/mapset --exec sh lst_processing.sh

Enjoy! :) and Happy New Year!

How to aggregate daily data into MODIS-like 8 day aggregation pattern?

Mon, 25 Jan 2016 15:12:50 +0000

Several MODIS products come in “8-day” compositions. Suppose we have daily data and we want to aggregate it with this MODIS-like granularity. How can we achieve that? First idea would be to use the great t.rast.aggregate module in GRASS GIS with granularity=“8 days”. But this presents a problem. It does not re-start every year, but aggregates the whole series with 8-day granularity, not considering the year. Meanwhile, MODIS 8-day products re-start the aggregation every January 1st. Therefore, second idea could be to use t.rast.aggregate with granularity=“8 days” but looping over years, and then merge the resulting strds with t.merge. However, granularity seems to overrule the where clause. This is evident in the output of t.rast.list (i.e.: last map granularity covers 3 days from the next year) in the following example:

for YEAR in "2003 2004" "2004 2005" "2005 2006" ; do 
  set -- $YEAR ; echo $1 $2 
  t.rast.aggregate -s input=daily_temp \
    output=8day_avg_temp_${1} \
    basename=8day_avg_temp \
    method=average \
    granularity="8 days" \
    where="start_time >= '${1}-01-01' and end_time < '${2}-01-01'" 
done 

# check output maps in time series 
t.rast.list 8day_avg_temp_2003 
name|mapset|start_time|end_time 
8day_avg_temp_2003_01_01|climate|2003-01-01 00:00:00|2003-01-09 00:00:00 
8day_avg_temp_2003_01_09|climate|2003-01-09 00:00:00|2003-01-17 00:00:00 
... 
8day_avg_temp_2003_12_19|climate|2003-12-19 00:00:00|2003-12-27 00:00:00 
8day_avg_temp_2003_12_27|climate|2003-12-27 00:00:00|2004-01-04 00:00:00

So, we need a different solution. If we already have a registered time series of MODIS 8-day products, we can just use it to copy its aggregation pattern with t.rast.aggregate.ds. But what if we don’t? How do we create a MODIS-like 8 day granularity to use it as reference to aggregate our daily data?? One solution could be to create a time series (could be raster or vector) with that particular pattern of aggregation and then, use it to aggregate our daily time series.

In this example, I’ll show you how to create a raster time series, from now on strds, which stands for “spatio-temporal raster dataset”. But, in order to save space in disk we’ll set a region of only one pixel in the center of the current region

eval `g.region -g` 
eval `g.region -cg` 
g.region w=$center_easting s=$center_northing \
  e=`echo "$center_easting + $ewres" | bc` \ 
  n=`echo "$center_northing + $nsres" | bc` -p

Now, we’ll create daily maps and register them as our daily time series, which will be our input time series (see below).

# create daily maps 
for i in `seq -w 1 740` ; do 
  r.mapcalc -s expression="daily_ts_${i} = rand(0.0,40.0)" 
done
 
# create daily ts 
t.create type=strds temporaltype=absolute \
  output=daily_ts \
  title="Daily time series" \
  description="Test STRDS with 1 day granularity"

# register daily maps 
t.register -i type=raster input=daily_ts \
  maps=`g.list type=raster pattern=daily_ts_* separator=comma` \
  start="2000-01-01" increment="1 days"

# check info 
t.info input=daily_ts 
t.rast.list input=daily_ts

And then we create the 8-day MODIS-like maps and register them as time series. This will be our sample strds, the data set from which we’ll copy the aggregation pattern. We use year and DOY (day of year) to name maps. These will then be converted into calendar dates to register maps as a time series with absolute time.

# create maps every 8 days 
for year in `seq 2000 2001` ; do 
  for doy in `seq -w 1 8 365` ; do 
    r.mapcalc -s expression="8day_${year}_${doy} = rand(0.0,40.0)" 
  done 
done

After we created maps, we need to assign timestamps to them representing 8-days intervals for all maps, except for the last map in each year, since the aggregation starts all over again, every January 1st.

# mapnames list 
g.list type=raster pattern=8day_20??_* > names_list

From de name of each map, we take year and doy, and convert it to a YYYY-MM-DD date for start and end (we need time intervals), considering also if the year is a leap year or not.

# create file with mapnames, start date and end date 
for NAME in \`cat names\_list\` ; do 
  
  # Parse 
  YEAR=`echo $NAME | cut -d'_' -f2` 
  DOY=`echo $NAME | cut -d'_' -f3` 
  
  # convert YYYY_DOY to YYYY-MM-DD 
  # BEWARE: leading zeros make bash assume the number 
  # is in base 8 system, not base 10! 
  DOY=`echo "$DOY" | sed 's/^0\*//'` 
  
  # list with mapname and both start and end time 
  doy_end=0 
  if [ $DOY -le "353" ] ; then 
    doy_end=$(( $DOY + 8 )) 
  elif [ $DOY -eq "361" ] ; then 
    if [ $[$YEAR % 4] -eq 0 ] && [ $[$YEAR % 100] -ne 0 ] || [ $[$YEAR % 400] -eq 0 ] ; then 
      doy_end=$(( $DOY + 6 )) 
    else 
      doy_end=$(( $DOY + 5 )) 
    fi 
  fi 

DATE_START=`date -d "${YEAR}-01-01 +$(( ${DOY} - 1 ))days" +%Y-%m-%d` 
DATE_END=`date -d "${YEAR}-01-01 +$(( ${doy_end} -1 ))days" +%Y-%m-%d` 

# text file with mapnames, start date and end date 
echo "$NAME|$DATE_START|$DATE_END" >> list_map_start_end_time.txt 

done

We check the list. Intervals are left open, so end time of one map is the start time of the next. We also check that the last map of each year ends as expected.

cat list_map_start_end_time.txt 
8day_2000_001|2000-01-01|2000-01-09 8day_2000_009|2000-01-09|2000-01-17
... 
8day_2000_353|2000-12-18|2000-12-26 8day_2000_361|2000-12-26|2001-01-01 
8day_2001_001|2001-01-01|2001-01-09 8day_2001_009|2001-01-09|2001-01-17
... 
8day_2001_345|2001-12-11|2001-12-19 8day_2001_353|2001-12-19|2001-12-27 
8day_2001_361|2001-12-27|2002-01-01

We are ready now to create our 8-day MODIS-like strds.

# create strds 
t.create type=strds temporaltype=absolute \
  output=8day_ts \
  title="8 day time series" \
  description="STRDS with MODIS like 8 day aggregation"

# register maps 
t.register type=raster input=8day_ts \ 
file=list_map_start_end_time.txt

# check 
t.info input=8day_ts 
t.rast.list input=8day_ts

Finally, we copy its aggregation to our daily time series.

# copy the aggregation 
t.rast.aggregate.ds -s input=daily_ts sample=8day_ts \
  output=8day_agg basename=8day_agg \
  method=average sampling=contains 

# add metadata 
t.support input=8day_agg \
  title="8 day aggregated ts" \
  description="8 day MODIS-like aggregated dataset" 

# check 
t.info input=8day_agg 
+-------------------- Space Time Raster Dataset -----------------------------+ | 
+-------------------- Basic information -------------------------------------+ | 
Id: ........................ 8day\_agg@pruebas | 
Name: ...................... 8day\_agg | 
Mapset: .................... pruebas | 
Creator: ................... veroandreo | 
Temporal type: ............. absolute | 
Creation time: ............. 2016-01-09 21:44:54.074235 | 
Modification time:.......... 2016-01-10 16:39:06.253565 | 
Semantic type:.............. mean 
+-------------------- Absolute time -----------------------------------------+ | 
Start time:................. 2000-01-01 00:00:00 | 
End time:................... 2002-01-01 00:00:00 | 
Granularity:................ 1 day | 
Temporal type of maps:...... interval 
+-------------------- Spatial extent ----------------------------------------+ | 
North:...................... -33.0 | 
South:...................... -33.5 | 
East:.. .................... -57.0 | 
West:....................... -57.5 | 
Top:........................ 0.0 | 
Bottom:..................... 0.0 
+-------------------- Metadata information ----------------------------------+ | 
Raster register table:...... raster\_map\_register\_115633bc4e0a4195b6cb4fdcab505522 | 
North-South resolution min:. 0.5 | 
North-South resolution max:. 0.5 | 
East-west resolution min:... 0.5 | 
East-west resolution max:... 0.5 | 
Minimum value min:.......... 2.935881 | 
Minimum value max:.......... 28.388835 | 
Maximum value min:.......... 2.935881 | 
Maximum value max:.......... 28.388835 | 
Aggregation type:........... average | 
Number of registered maps:.. 92 | 
| Title: 
| 8 day aggregated ts 
| Description: 
| 8 day MODIS-like aggregated dataset 
| Command history: 
| # 2016-01-09 21:44:54 
| t.rast.aggregate.ds -s input="daily_ts" 
| sample="8day_ts" output="8day_agg" basename="8day_agg" 
| method="average" sampling="contains" 
| # 2016-01-10 16:39:06 
| t.support input="8day_agg" 
| title="8 day aggregated ts" 
| description="8 day MODIS-like aggregated dataset" | 
+----------------------------------------------------------------------------+ 

t.rast.list input=8day_agg name|mapset|start_time|end_time 
8day_agg_2000_01_01|pruebas|2000-01-01 00:00:00|2000-01-09 00:00:00 
8day_agg_2000_01_09|pruebas|2000-01-09 00:00:00|2000-01-17 00:00:00 
8day_agg_2000_01_17|pruebas|2000-01-17 00:00:00|2000-01-25 00:00:00 
... 
8day_agg_2000_12_18|pruebas|2000-12-18 00:00:00|2000-12-26 00:00:00 
8day_agg_2000_12_26|pruebas|2000-12-26 00:00:00|2001-01-01 00:00:00 
8day_agg_2001_01_01|pruebas|2001-01-01 00:00:00|2001-01-09 00:00:00 
... 
8day_agg_2001_12_11|pruebas|2001-12-11 00:00:00|2001-12-19 00:00:00
8day_agg_2001_12_19|pruebas|2001-12-19 00:00:00|2001-12-27 00:00:00 
8day_agg_2001_12_27|pruebas|2001-12-27 00:00:00|2002-01-01 00:00:00

Note that some maps from our daily strds remain not aggregated into the 8 day new time series, that’s because we used “sampling=contains”, which assures that only raster maps that are temporally during the time intervals of the strds are considered for computation.

Enjoy! :)