[GRASS-user] Extracting vegetation phenology from Landsat-based time series

GRASS GRASS user
1

Dear list,

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

2

Dear Nikos

I was also looking for the same functionalities very recently. Closest solution i could find is the ‘greenbrown’ package in R. Atleast we could make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of functions as in timestat and spirits.

See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in GRASS :wink:

Regards

Sajid

···

On Sat, Oct 29, 2016 at 2:58 PM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Dear list,

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

3

Nikos Alexandris:

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

Sajid Pareeth:

I was also looking for the same functionalities very recently. Closest
solution i could find is the 'greenbrown' package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS :wink:

Thank you Sajid.

As I am not an expert in cropping cycles monitoring, I
naively thought there would be more or less some ready to use tools in
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
Windows).

R is good, but there is still the back-and-forth step. There is also a "french" tool for QGIS:
https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/

At the moment I am looking for an over-simplified way to just
hint/classify surfaces on which multiple cropping cycles per year take
place (related to industrial agricultural surfaces). Something to get
going.

Given TGRASS, if we find a practical algorithm, it shouldn't be too hard
to implement it GRASS-natively.

Nikos

4

On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

Sajid Pareeth:

I was also looking for the same functionalities very recently. Closest
solution i could find is the 'greenbrown' package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS :wink:

Thank you Sajid.

As I am not an expert in cropping cycles monitoring, I
naively thought there would be more or less some ready to use tools in
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
Windows).

R is good, but there is still the back-and-forth step. There is also a
"french" tool for QGIS:
https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/

At the moment I am looking for an over-simplified way to just
hint/classify surfaces on which multiple cropping cycles per year take
place (related to industrial agricultural surfaces). Something to get
going.

Given TGRASS, if we find a practical algorithm, it shouldn't be too hard
to implement it GRASS-natively.

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

For preparation, I think that GRASS needs more tools to remove
outliers and fill gaps in time series. A commonly used tool is local
weighted regression, also known as LOESS or LOWESS.

I would like to have a module like r.series.lwr (local weighted
regression) in GRASS with the options

* order=1,2,3 with 1 = linear regression, 2 = second order polynomial
regression, 3 = third order polynomial regression
* dod = degree of over-determination because for e.g. linear
regression you need only 2 data points but that gives an exact fit and
does not remove outliers, so a number of additional points
(over-determination) is needed for smoothing. The number of additional
points should not be too large, otherwise local real fluctuations can
not be represented by the regression and are smoothed out.
* weighing function: default tricube, additional options uniform,
triangular, epanechnikov, quartic, triweight, cosine
* extreme: iteratively replace outliers with the estimate until a
given goodness of fit (e.g. coefficient of determination) is obtained

Output: one output for each input map.

Currently I am using r.hants a lot, but r.hants assumes more or less
regular cycles in the time series (e.g. NDVI) and fits a single
function to the complete time series, while a local weighted
regression can work with much less points and can still capture
short-term non-linear fluctuations.

Markus M

Nikos

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

5

* Markus Metz <markus.metz.giswork@gmail.com> [2016-10-30 22:30:46 +0100]:

On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

Sajid Pareeth:

I was also looking for the same functionalities very recently. Closest
solution i could find is the 'greenbrown' package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS :wink:

Thank you Sajid.

As I am not an expert in cropping cycles monitoring, I
naively thought there would be more or less some ready to use tools in
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
Windows).

R is good, but there is still the back-and-forth step. There is also a
"french" tool for QGIS:
https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/

At the moment I am looking for an over-simplified way to just
hint/classify surfaces on which multiple cropping cycles per year take
place (related to industrial agricultural surfaces). Something to get
going.

Given TGRASS, if we find a practical algorithm, it shouldn't be too hard
to implement it GRASS-natively.

Markus M:

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

May Yann's addon i.lmf (Temporal Local Maximum Fitting of vegetation
indices) be useful within the context? (can't test it, it
segfaults and I have no time to debug these days).

Nikos

For preparation, I think that GRASS needs more tools to remove
outliers and fill gaps in time series. A commonly used tool is local
weighted regression, also known as LOESS or LOWESS.

I would like to have a module like r.series.lwr (local weighted
regression) in GRASS with the options

* order=1,2,3 with 1 = linear regression, 2 = second order polynomial
regression, 3 = third order polynomial regression
* dod = degree of over-determination because for e.g. linear
regression you need only 2 data points but that gives an exact fit and
does not remove outliers, so a number of additional points
(over-determination) is needed for smoothing. The number of additional
points should not be too large, otherwise local real fluctuations can
not be represented by the regression and are smoothed out.
* weighing function: default tricube, additional options uniform,
triangular, epanechnikov, quartic, triweight, cosine
* extreme: iteratively replace outliers with the estimate until a
given goodness of fit (e.g. coefficient of determination) is obtained

Output: one output for each input map.

Currently I am using r.hants a lot, but r.hants assumes more or less
regular cycles in the time series (e.g. NDVI) and fits a single
function to the complete time series, while a local weighted
regression can work with much less points and can still capture
short-term non-linear fluctuations.

Markus M

6

Hello Nikos and all :slight_smile:

Don’t know exactly which parameters you would like to extract from your time series, Nikos, but if helpful, what I did was to use a combination of r.hants and temporal modules to get some phenological indicators such as, number of cycles per year, yearly max and min values, dates of yearly max and min values, period that the variable was above a certain threshold, max rate of change (slope between every pair of maps and then aggregate per year with method=maximum). Some of those examples are in the wiki [0]. I believe that much more could be done with t.rast.algebra (it seems very powerfull), but I haven’t yet tested enough.

@Sajid, I agree it would be great to have such functionalities as “ready-to-use” module in GRASS, too. Therefore, we could avoid all the steps of moving a time series into r and then back again into GRASS [1]

@MarkusM, local weighted regression sounds cool. +1 for that! It would be also very useful to have DINEOF [2] natively implemented. It is very nice when you want to keep the variation of the series instead of smoothing it out [1].

Best,
Vero

[0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing
[1] https://grasswiki.osgeo.org/wiki/Temporal_data_processing/GRASS_R_raster_time_series_processing
[2] http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF

···

2016-10-31 10:06 GMT+01:00 Nikos Alexandris <nik@nikosalexandris.net>:

On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

Sajid Pareeth:

I was also looking for the same functionalities very recently. Closest
solution i could find is the ‘greenbrown’ package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS :wink:

Thank you Sajid.

As I am not an expert in cropping cycles monitoring, I
naively thought there would be more or less some ready to use tools in
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
Windows).

R is good, but there is still the back-and-forth step. There is also a
“french” tool for QGIS:
https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/

At the moment I am looking for an over-simplified way to just
hint/classify surfaces on which multiple cropping cycles per year take
place (related to industrial agricultural surfaces). Something to get
going.

Given TGRASS, if we find a practical algorithm, it shouldn’t be too hard
to implement it GRASS-natively.

Markus M:

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

May Yann’s addon i.lmf (Temporal Local Maximum Fitting of vegetation
indices) be useful within the context? (can’t test it, it
segfaults and I have no time to debug these days).

Nikos

For preparation, I think that GRASS needs more tools to remove
outliers and fill gaps in time series. A commonly used tool is local
weighted regression, also known as LOESS or LOWESS.

I would like to have a module like r.series.lwr (local weighted
regression) in GRASS with the options

  • order=1,2,3 with 1 = linear regression, 2 = second order polynomial
    regression, 3 = third order polynomial regression
  • dod = degree of over-determination because for e.g. linear
    regression you need only 2 data points but that gives an exact fit and
    does not remove outliers, so a number of additional points
    (over-determination) is needed for smoothing. The number of additional
    points should not be too large, otherwise local real fluctuations can
    not be represented by the regression and are smoothed out.
  • weighing function: default tricube, additional options uniform,
    triangular, epanechnikov, quartic, triweight, cosine
  • extreme: iteratively replace outliers with the estimate until a
    given goodness of fit (e.g. coefficient of determination) is obtained

Output: one output for each input map.

Currently I am using r.hants a lot, but r.hants assumes more or less
regular cycles in the time series (e.g. NDVI) and fits a single
function to the complete time series, while a local weighted
regression can work with much less points and can still capture
short-term non-linear fluctuations.

Markus M

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

7

Hi all

Thanks MarkusM and Vero for the detailed follow up.

I also use r.hants a lot, and recently was trying to make use of amplitude and phase outputs to infer some of the phenological parameters from the annual cycle (still not sure, if it is a feasible approach).

But it seems inadequate when it comes to determine the start and end time of the growing season in a year. I am looking for a solution along the line as given in this paper:

https://www.researchgate.net/publication/238418948_Measuring_Phenological_Variability_From_Satellite_Imagery

I think once we have the start and end of growing season, rest of the related parameters are easy to compute.

May be, there already exists a way in GRASS to do it using TGRASS !!.

Regards

Sajid

···

On Mon, Oct 31, 2016 at 10:40 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hello Nikos and all :slight_smile:

Don’t know exactly which parameters you would like to extract from your time series, Nikos, but if helpful, what I did was to use a combination of r.hants and temporal modules to get some phenological indicators such as, number of cycles per year, yearly max and min values, dates of yearly max and min values, period that the variable was above a certain threshold, max rate of change (slope between every pair of maps and then aggregate per year with method=maximum). Some of those examples are in the wiki [0]. I believe that much more could be done with t.rast.algebra (it seems very powerfull), but I haven’t yet tested enough.

@Sajid, I agree it would be great to have such functionalities as “ready-to-use” module in GRASS, too. Therefore, we could avoid all the steps of moving a time series into r and then back again into GRASS [1]

@MarkusM, local weighted regression sounds cool. +1 for that! It would be also very useful to have DINEOF [2] natively implemented. It is very nice when you want to keep the variation of the series instead of smoothing it out [1].

Best,
Vero

[0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing
[1] https://grasswiki.osgeo.org/wiki/Temporal_data_processing/GRASS_R_raster_time_series_processing
[2] http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

2016-10-31 10:06 GMT+01:00 Nikos Alexandris <nik@nikosalexandris.net>:

On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

Sajid Pareeth:

I was also looking for the same functionalities very recently. Closest
solution i could find is the ‘greenbrown’ package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS :wink:

Thank you Sajid.

As I am not an expert in cropping cycles monitoring, I
naively thought there would be more or less some ready to use tools in
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
Windows).

R is good, but there is still the back-and-forth step. There is also a
“french” tool for QGIS:
https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/

At the moment I am looking for an over-simplified way to just
hint/classify surfaces on which multiple cropping cycles per year take
place (related to industrial agricultural surfaces). Something to get
going.

Given TGRASS, if we find a practical algorithm, it shouldn’t be too hard
to implement it GRASS-natively.

Markus M:

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

May Yann’s addon i.lmf (Temporal Local Maximum Fitting of vegetation
indices) be useful within the context? (can’t test it, it
segfaults and I have no time to debug these days).

Nikos

For preparation, I think that GRASS needs more tools to remove
outliers and fill gaps in time series. A commonly used tool is local
weighted regression, also known as LOESS or LOWESS.

I would like to have a module like r.series.lwr (local weighted
regression) in GRASS with the options

  • order=1,2,3 with 1 = linear regression, 2 = second order polynomial
    regression, 3 = third order polynomial regression
  • dod = degree of over-determination because for e.g. linear
    regression you need only 2 data points but that gives an exact fit and
    does not remove outliers, so a number of additional points
    (over-determination) is needed for smoothing. The number of additional
    points should not be too large, otherwise local real fluctuations can
    not be represented by the regression and are smoothed out.
  • weighing function: default tricube, additional options uniform,
    triangular, epanechnikov, quartic, triweight, cosine
  • extreme: iteratively replace outliers with the estimate until a
    given goodness of fit (e.g. coefficient of determination) is obtained

Output: one output for each input map.

Currently I am using r.hants a lot, but r.hants assumes more or less
regular cycles in the time series (e.g. NDVI) and fits a single
function to the complete time series, while a local weighted
regression can work with much less points and can still capture
short-term non-linear fluctuations.

Markus M

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

8

Hello Sajid!

I came across the same issue when i was working with Chlorophyll data. The problem is to define what you mean by start and end of growing season first, i.e.: a certain increasing or decreasing growth rate, a certain level of accumulated biomass, only a threshold in VI values, etc. Thing is that to get a “good” estimate of start and end, you have to control/check what happens before/after the thresholds for start/end, otherwise how to distinguish start from end?.. By then, I didn’t find a way to do that only with GRASS commands, so, i did a bit of coding in R to get start date of phytoplankton blooms. Though, as mentioned before, I believe to some extent that t.rast.algebra might be the the way to go since it allows for temporal indexing.

An probable solution might be to alternatively aggregate time series by month, changing starting date (for example: first aggregate starting in january, then in february, then in march and so on) and save the dates in which the value of the time series crosses a threshold (or reaches the maximum or minimum). Then, you may aggregate the output by year asking the mode and range… that should give the date in which it is most common to find the start of the season (or max or min) and the range of dates… But this I haven’t really tested (yet) :slight_smile:

Cheers,
Vero

···

2016-10-31 11:00 GMT+01:00 Sajid Pareeth <spareeth@gmail.com>:

Hi all

Thanks MarkusM and Vero for the detailed follow up.

I also use r.hants a lot, and recently was trying to make use of amplitude and phase outputs to infer some of the phenological parameters from the annual cycle (still not sure, if it is a feasible approach).

But it seems inadequate when it comes to determine the start and end time of the growing season in a year. I am looking for a solution along the line as given in this paper:

https://www.researchgate.net/publication/238418948_Measuring_Phenological_Variability_From_Satellite_Imagery

I think once we have the start and end of growing season, rest of the related parameters are easy to compute.

May be, there already exists a way in GRASS to do it using TGRASS !!.

Regards

Sajid

On Mon, Oct 31, 2016 at 10:40 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hello Nikos and all :slight_smile:

Don’t know exactly which parameters you would like to extract from your time series, Nikos, but if helpful, what I did was to use a combination of r.hants and temporal modules to get some phenological indicators such as, number of cycles per year, yearly max and min values, dates of yearly max and min values, period that the variable was above a certain threshold, max rate of change (slope between every pair of maps and then aggregate per year with method=maximum). Some of those examples are in the wiki [0]. I believe that much more could be done with t.rast.algebra (it seems very powerfull), but I haven’t yet tested enough.

@Sajid, I agree it would be great to have such functionalities as “ready-to-use” module in GRASS, too. Therefore, we could avoid all the steps of moving a time series into r and then back again into GRASS [1]

@MarkusM, local weighted regression sounds cool. +1 for that! It would be also very useful to have DINEOF [2] natively implemented. It is very nice when you want to keep the variation of the series instead of smoothing it out [1].

Best,
Vero

[0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing
[1] https://grasswiki.osgeo.org/wiki/Temporal_data_processing/GRASS_R_raster_time_series_processing
[2] http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

2016-10-31 10:06 GMT+01:00 Nikos Alexandris <nik@nikosalexandris.net>:

On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Nikos Alexandris:

is there a GRASS-native, of GRASS-friendly, practical tool or tutorial
or implementation of models, as in the TIMESAT [0] software or SPIRITS
[1], to exctract phenological parameters from NDVI (or, preferrably
EVI2) times series?

Thank you, Nikos

[0] http://web.nateko.lu.se/timesat/timesat.asp
[1] http://spirits.jrc.ec.europa.eu/download/software/

Sajid Pareeth:

I was also looking for the same functionalities very recently. Closest
solution i could find is the ‘greenbrown’ package in R. Atleast we could
make use of the GRASS-R interface to implement the work flow.

Phenology function in this package has a good comprehensive list of
functions as in timestat and spirits.
See fig4 here: http://greenbrown.r-forge.r-project.org/phenology.php

If you find anything else, please do post here.

And above all, it would be really great to have these functionalities in
GRASS :wink:

Thank you Sajid.

As I am not an expert in cropping cycles monitoring, I
naively thought there would be more or less some ready to use tools in
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under
Windows).

R is good, but there is still the back-and-forth step. There is also a
“french” tool for QGIS:
https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/

At the moment I am looking for an over-simplified way to just
hint/classify surfaces on which multiple cropping cycles per year take
place (related to industrial agricultural surfaces). Something to get
going.

Given TGRASS, if we find a practical algorithm, it shouldn’t be too hard
to implement it GRASS-natively.

Markus M:

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

May Yann’s addon i.lmf (Temporal Local Maximum Fitting of vegetation
indices) be useful within the context? (can’t test it, it
segfaults and I have no time to debug these days).

Nikos

For preparation, I think that GRASS needs more tools to remove
outliers and fill gaps in time series. A commonly used tool is local
weighted regression, also known as LOESS or LOWESS.

I would like to have a module like r.series.lwr (local weighted
regression) in GRASS with the options

  • order=1,2,3 with 1 = linear regression, 2 = second order polynomial
    regression, 3 = third order polynomial regression
  • dod = degree of over-determination because for e.g. linear
    regression you need only 2 data points but that gives an exact fit and
    does not remove outliers, so a number of additional points
    (over-determination) is needed for smoothing. The number of additional
    points should not be too large, otherwise local real fluctuations can
    not be represented by the regression and are smoothed out.
  • weighing function: default tricube, additional options uniform,
    triangular, epanechnikov, quartic, triweight, cosine
  • extreme: iteratively replace outliers with the estimate until a
    given goodness of fit (e.g. coefficient of determination) is obtained

Output: one output for each input map.

Currently I am using r.hants a lot, but r.hants assumes more or less
regular cycles in the time series (e.g. NDVI) and fits a single
function to the complete time series, while a local weighted
regression can work with much less points and can still capture
short-term non-linear fluctuations.

Markus M

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

9

Hi Markus

···

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

Yes, Output could be number of rasters equal to the maximum crop cycles found in the scene. For those pixels with only one dominant cycle can be represented with null() in the start and stop DOY maps of the next cycles.

I couldnt find any tool or study which captures multiple SOS and EOS in case of crops. This would be really great to have. For example the phenology parameters computed using R package greenbrown (http://greenbrown.r-forge.r-project.org/phenology.php) considers only one cycle (Not really for the crop phenology change). The method they use is explained in page 5 of the associated paper:

Quoting the paper:

“In the third step, we used the smoothed and daily interpolated time series to estimate start of growing season (SOS) and end of growing season (EOS) by either using 50% thresholds on the seasonal greenness curve (approach Trs) (White et al., 1997) or the derivative of the seasonal curve (approach Deriv) (Tateishi & Ebata, 2004) (Data S1). Both approaches are based on the definition of SOS and EOS as the mid-points of spring
greenup and autumn senescence, respectively”

Co-dominant water control on global inter-annual variability and trends in land surface phenology and greenness. Available from: https://www.researchgate.net/publication/275050767_Co-dominant_water_control_on_global_inter-annual_variability_and_trends_in_land_surface_phenology_and_greenness [accessed Oct 31, 2016]."

10

* Veronica Andreo <veroandreo@gmail.com> [2016-10-31 10:40:33 +0100]:

Hello Nikos and all :slight_smile:

Don't know exactly which parameters you would like to extract from your
time series, Nikos, but if helpful, what I did was to use a combination of
r.hants and temporal modules to get some phenological indicators such as,
number of cycles per year,...

Vero,

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn't grasp that. Can you pin-point? It's
exactly what we need at the moment.

Nikos

...yearly max and min values, dates of yearly max
and min values, period that the variable was above a certain threshold, max
rate of change (slope between every pair of maps and then aggregate per
year with method=maximum). Some of those examples are in the wiki [0]. I
believe that much more could be done with t.rast.algebra (it seems very
powerfull), but I haven't yet tested enough.

@Sajid, I agree it would be great to have such functionalities as
"ready-to-use" module in GRASS, too. Therefore, we could avoid all the
steps of moving a time series into r and then back again into GRASS [1]

@MarkusM, local weighted regression sounds cool. +1 for that! It would be
also very useful to have DINEOF [2] natively implemented. It is very nice
when you want to keep the variation of the series instead of smoothing it
out [1].

Best,
Vero

[0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing
[1]
https://grasswiki.osgeo.org/wiki/Temporal_data_processing/GRASS_R_raster_time_series_processing
[2] http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF

[rest deleted]

11

Hello Nikos,

Yes, maybe it is not well explained, but it is here:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Filling_and_reconstructing_time_series_data_with_gaps_-_HANTS

and also in the manual under “NOTES”
https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

The idea is, once you are happy with the result of hants, you ask for amplitude outputs and with those amplitude maps (you’ll have one map per frequency) you run r.series method=max_raster. This will give you the most important frequency (according to amplitude value of that frequency) in each pixel. If the result is that the most important frequency is 0, then you have one cycle per year (that, if you use a base period of one year of course).

Hope it is clearer now :slight_smile:

Best,
Vero

···

2016-11-01 8:30 GMT+01:00 Nikos Alexandris <nik@nikosalexandris.net>:

Hello Nikos and all :slight_smile:

Don’t know exactly which parameters you would like to extract from your
time series, Nikos, but if helpful, what I did was to use a combination of
r.hants and temporal modules to get some phenological indicators such as,
number of cycles per year,…

Vero,

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn’t grasp that. Can you pin-point? It’s
exactly what we need at the moment.

Nikos

…yearly max and min values, dates of yearly max
and min values, period that the variable was above a certain threshold, max
rate of change (slope between every pair of maps and then aggregate per
year with method=maximum). Some of those examples are in the wiki [0]. I
believe that much more could be done with t.rast.algebra (it seems very
powerfull), but I haven’t yet tested enough.

@Sajid, I agree it would be great to have such functionalities as
“ready-to-use” module in GRASS, too. Therefore, we could avoid all the
steps of moving a time series into r and then back again into GRASS [1]

@MarkusM, local weighted regression sounds cool. +1 for that! It would be
also very useful to have DINEOF [2] natively implemented. It is very nice
when you want to keep the variation of the series instead of smoothing it
out [1].

Best,
Vero

[0] https://grasswiki.osgeo.org/wiki/Temporal_data_processing
[1]
https://grasswiki.osgeo.org/wiki/Temporal_data_processing/GRASS_R_raster_time_series_processing
[2] http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF

[rest deleted]

12

On Mon, Oct 31, 2016 at 12:07 PM, Sajid Pareeth <spareeth@gmail.com> wrote:

Hi Markus

[ currently trying to get a grip on MODIS version 6 time series ]

In theory, extracting seasons such as cropping cycles is quite easy to
implement: whenever a parameter in a time series is above/below a
given threshold, start/stop the season. The question is how to store
the results for multiple cropping cycles: a separate raster for each
cycle and each start and stop date?

Yes, Output could be number of rasters equal to the maximum crop cycles
found in the scene. For those pixels with only one dominant cycle can be
represented with null() in the start and stop DOY maps of the next cycles.

I couldnt find any tool or study which captures multiple SOS and EOS in case
of crops. This would be really great to have. For example the phenology
parameters computed using R package greenbrown
(http://greenbrown.r-forge.r-project.org/phenology.php) considers only one
cycle (Not really for the crop phenology change). The method they use is
explained in page 5 of the associated paper:

Multiple SOS and EOS would be easy to implement with an option setting
the maximum number of cycles/seasons. As Vero said, "The problem is to
define what you mean by start and end of growing season first, i.e.: a
certain increasing or decreasing growth rate, a certain level of
accumulated biomass, only a threshold in VI values, etc."

Quoting the paper:

"In the third step, we used the smoothed and daily interpolated time series
to estimate start of growing season (SOS) and end of growing season (EOS) by
either using 50% thresholds on the seasonal greenness curve (approach Trs)
(White et al., 1997) or the derivative of the seasonal curve (approach
Deriv) (Tateishi & Ebata, 2004) (Data S1). Both approaches are based on the
definition of SOS and EOS as the mid-points of spring
greenup and autumn senescence, respectively"

The derivate can be a problem in case of noisy data with values
jumping around the threshold in a short period of time, particularly
with daily data.

IMHO, the preparation of a time series (outlier removal and gap
filling) is quite important because it influences any subsequent
results. This thread mentions different approaches. They can be
grouped into some kind of global fitting of the whole time series or
local fitting (moving window over time). I tend to prefer local
fitting methods (i.lmf, local weighted regression) for time series
that do not show clear and regular cycles. Further on, approaches can
be grouped by the kind of fitting: harmonics (r.hants, i.lmf),
polynomial regression (local weighted regression), or PCA (DINEOF).

The nice aspect of DINEOF is that it combines the spatial and temporal
domains. I made an attempt to port DINEOF to GRASS 2 years ago, but
did not finish because it is computationally too intensive (too much
memory, too slow). DINEOF uses tricks to work with reduced matrices to
overcome this problem, but the tricks are tricky (a lot of work to
implement).

Local weighted regression on the other hand is relatively easy, I am
nearly done with the implementation. LWR seems to be more robust
against outliers than HANTS, and there are no overshoots as in HANTS.

Markus M

Co-dominant water control on global inter-annual variability and trends in
land surface phenology and greenness. Available from:
https://www.researchgate.net/publication/275050767_Co-dominant_water_control_on_global_inter-annual_variability_and_trends_in_land_surface_phenology_and_greenness
[accessed Oct 31, 2016]."

13

Veronica Andreo:

Don't know exactly which parameters you would like to extract from your
time series, Nikos, but if helpful, what I did was to use a combination of
r.hants and temporal modules to get some phenological indicators such as,
number of cycles per year,...

Nikos Alexandris:

Vero,

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn't grasp that. Can you pin-point? It's
exactly what we need at the moment.

Veronica Andreo:

Yes, maybe it is not well explained, but it is here:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Filling_and_reconstructing_time_series_data_with_gaps_-_HANTS

and also in the manual under "NOTES"
https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

The idea is, once you are happy with the result of hants, you ask for
amplitude outputs and with those amplitude maps (you'll have one map per
frequency) you run r.series method=max_raster. This will give you the most
important frequency (according to amplitude value of that frequency) in
each pixel. If the result is that the most important frequency is 0, then
you have one cycle per year (that, if you use a base period of one year of
course).

Hope it is clearer now :slight_smile:

Yes. It was even before -- just me read through quickly.

r.hants is awesome!

We have 24 Landsat 8 derived EVI2 maps (2 for each month) for one year.
Clouds and Water surfaces removed. Another set of "relatively normalised
images, using `i.histo.match` is also ready. We really need to "fix"
`i.histo.match` to crunch floats directly. The resulting ranges worry
me a bit -- I just followed the "old" way as discussed some years ago in
a relevant thread (floats > integers > histo-matching > floats).

Anyhow, I am testing the following:

for NF in 4 5 6 7 8 ;do r.hants file=evi2_maps nf=$NF fet=0.05 dod=3 base_period=24 suffix=_hants_nf_$NF amplitude=amplitude_hants_nf_$NF phase=phase_hants_nf_$NF ;done

(thinking loudly... it would be super-nice to have `t.rast.hants`)

Not sure about `dod`. Perhaps it should also follow a patten like 3 4 5
6 and 7 for the above?

for NF in 5 6 7 8 ; do t.rast.series evi2_hants_nf_$NF method=max_raster output=dominant_frequencies_hants_nf_$NF --o

"Dominant" frequencies 0, 1, 2 and 3 appear to be within the areas
of our interest (agricultural surfaces). Very good. And convincing.
Yet I am learning to interpret this correctly. And the "phase" as well.
Reminds math studies, years ago.

As I am working this out in a remote workstation, it's a bit annoying
not to be able to play an animation directly. The GUI runs fine,
though slow, of course (via ssh -CY).

Awesome to have all this in our fingertips :slight_smile:

Cheers, Nikos

[rest deleted]

14

Nikos Alexandris:

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn't grasp that. Can you pin-point? It's
exactly what we need at the moment.

Veronica Andreo:

Yes, maybe it is not well explained, but it is here:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Filling_and_reconstructing_time_series_data_with_gaps_-_HANTS

and also in the manual under "NOTES"
https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

The idea is, once you are happy with the result of hants, you ask for
amplitude outputs and with those amplitude maps (you'll have one map per
frequency) you run r.series method=max_raster. This will give you the most
important frequency (according to amplitude value of that frequency) in
each pixel. If the result is that the most important frequency is 0, then
you have one cycle per year (that, if you use a base period of one year of
course).

Hope it is clearer now :slight_smile:

Nikos:

Yes. It was even before -- just me read through quickly.

r.hants is awesome!

We have 24 Landsat 8 derived EVI2 maps (2 for each month) for one year.
Clouds and Water surfaces removed. Another set of "relatively normalised
images, using `i.histo.match` is also ready. We really need to "fix"
`i.histo.match` to crunch floats directly. The resulting ranges worry
me a bit -- I just followed the "old" way as discussed some years ago in
a relevant thread (floats > integers > histo-matching > floats).

Anyhow, I am testing the following:

for NF in 4 5 6 7 8 ;do r.hants file=evi2_maps nf=$NF fet=0.05 dod=3 base_period=24 suffix=_hants_nf_$NF amplitude=amplitude_hants_nf_$NF phase=phase_hants_nf_$NF ;done

(thinking loudly... it would be super-nice to have `t.rast.hants`)

Not sure about `dod`. Perhaps it should also follow a patten like 3 4 5
6 and 7 for the above?

for NF in 5 6 7 8 ; do t.rast.series evi2_hants_nf_$NF method=max_raster output=dominant_frequencies_hants_nf_$NF --o

Just in case, the above *should* read:

for NF in 4 5 6 7 8 ;do r.series input=`g.list rast pattern=amplitude*nf_${NF}* separator=comma` method=max_raster output=dominant_frequencies_hants_nf_${NF} --o ;done

"Dominant" frequencies 0, 1, 2 and 3 appear to be within the areas
of our interest (agricultural surfaces). Very good. And convincing.
Yet I am learning to interpret this correctly. And the "phase" as well.
Reminds math studies, years ago.

It is a "good" thing to actually have similar dominant frequency "maps"
for all of the experimented Number of Frequencies.

A confirmation would be reassuring.

Thanks, Nikos

[rest deleted]

15

There is a new addon r.seasons which determines the number of seasons per pixel and extracts start and end dates for the given number of seasons from a time series.

The module is designed for noisy input, e.g.

time>value
0|0
1|0
2|1
3|0
4|1
5|1
6|1
7|0
8|1
9|1
10|1
11|1
12|0
13|0

with threshold 0.5 and minimum season length set to 3 would detect one season. Core season start is at 4, end at 10. Full season start is at 2, end at 10.

Markus M

···

On Wed, Nov 9, 2016 at 4:17 PM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Nikos Alexandris:

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn’t grasp that. Can you pin-point? It’s
exactly what we need at the moment.

Veronica Andreo:

Yes, maybe it is not well explained, but it is here:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Filling_and_reconstructing_time_series_data_with_gaps_-_HANTS

and also in the manual under “NOTES”
https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

The idea is, once you are happy with the result of hants, you ask for
amplitude outputs and with those amplitude maps (you’ll have one map per
frequency) you run r.series method=max_raster. This will give you the most
important frequency (according to amplitude value of that frequency) in
each pixel. If the result is that the most important frequency is 0, then
you have one cycle per year (that, if you use a base period of one year of
course).

Hope it is clearer now :slight_smile:

Nikos:

Yes. It was even before – just me read through quickly.

r.hants is awesome!

We have 24 Landsat 8 derived EVI2 maps (2 for each month) for one year.
Clouds and Water surfaces removed. Another set of "relatively normalised
images, using i.histo.match is also ready. We really need to “fix”
i.histo.match to crunch floats directly. The resulting ranges worry
me a bit – I just followed the “old” way as discussed some years ago in
a relevant thread (floats > integers > histo-matching > floats).

Anyhow, I am testing the following:

for NF in 4 5 6 7 8 ;do r.hants file=evi2_maps nf=$NF fet=0.05 dod=3 base_period=24 suffix=hants_nf$NF amplitude=amplitude_hants_nf_$NF phase=phase_hants_nf_$NF ;done

(thinking loudly… it would be super-nice to have t.rast.hants)

Not sure about dod. Perhaps it should also follow a patten like 3 4 5
6 and 7 for the above?

for NF in 5 6 7 8 ; do t.rast.series evi2_hants_nf_$NF method=max_raster output=dominant_frequencies_hants_nf_$NF --o

Just in case, the above should read:

for NF in 4 5 6 7 8 ;do r.series input=g.list rast pattern=amplitude*nf_${NF}* separator=comma method=max_raster output=dominant_frequencies_hants_nf_${NF} --o ;done

“Dominant” frequencies 0, 1, 2 and 3 appear to be within the areas
of our interest (agricultural surfaces). Very good. And convincing.
Yet I am learning to interpret this correctly. And the “phase” as well.
Reminds math studies, years ago.

It is a “good” thing to actually have similar dominant frequency “maps”
for all of the experimented Number of Frequencies.

A confirmation would be reassuring.

Thanks, Nikos

[rest deleted]

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

16

Very cool! Thanks Markus.

This sounds very useful.

I hope I find the time soon to test it!

···

There is a new addon r.seasons which determines the number of seasons per pixel and extracts start and end dates for the given number of seasons from a time series.

The module is designed for noisy input, e.g.

time|value
0|0
1|0
2|1
3|0
4|1
5|1
6|1
7|0
8|1
9|1
10|1
11|1
12|0
13|0

with threshold 0.5 and minimum season length set to 3 would detect one season. Core season start is at 4, end at 10. Full season start is at 2, end at 10.

Markus M

On Wed, Nov 9, 2016 at 4:17 PM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Nikos Alexandris:

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn’t grasp that. Can you pin-point? It’s
exactly what we need at the moment.

Veronica Andreo:

Yes, maybe it is not well explained, but it is here:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Filling_and_reconstructing_time_series_data_with_gaps_-_HANTS

and also in the manual under “NOTES”
https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

The idea is, once you are happy with the result of hants, you ask for
amplitude outputs and with those amplitude maps (you’ll have one map per
frequency) you run r.series method=max_raster. This will give you the most
important frequency (according to amplitude value of that frequency) in
each pixel. If the result is that the most important frequency is 0, then
you have one cycle per year (that, if you use a base period of one year of
course).

Hope it is clearer now :slight_smile:

Nikos:

Yes. It was even before – just me read through quickly.

r.hants is awesome!

We have 24 Landsat 8 derived EVI2 maps (2 for each month) for one year.
Clouds and Water surfaces removed. Another set of "relatively normalised
images, using i.histo.match is also ready. We really need to “fix”
i.histo.match to crunch floats directly. The resulting ranges worry
me a bit – I just followed the “old” way as discussed some years ago in
a relevant thread (floats > integers > histo-matching > floats).

Anyhow, I am testing the following:

for NF in 4 5 6 7 8 ;do r.hants file=evi2_maps nf=$NF fet=0.05 dod=3 base_period=24 suffix=hants_nf$NF amplitude=amplitude_hants_nf_$NF phase=phase_hants_nf_$NF ;done

(thinking loudly… it would be super-nice to have t.rast.hants)

Not sure about dod. Perhaps it should also follow a patten like 3 4 5
6 and 7 for the above?

for NF in 5 6 7 8 ; do t.rast.series evi2_hants_nf_$NF method=max_raster output=dominant_frequencies_hants_nf_$NF --o

Just in case, the above should read:

for NF in 4 5 6 7 8 ;do r.series input=g.list rast pattern=amplitude*nf_${NF}* separator=comma method=max_raster output=dominant_frequencies_hants_nf_${NF} --o ;done

“Dominant” frequencies 0, 1, 2 and 3 appear to be within the areas
of our interest (agricultural surfaces). Very good. And convincing.
Yet I am learning to interpret this correctly. And the “phase” as well.
Reminds math studies, years ago.

It is a “good” thing to actually have similar dominant frequency “maps”
for all of the experimented Number of Frequencies.

A confirmation would be reassuring.

Thanks, Nikos

[rest deleted]

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

17

Thanks Markus,

Will try it soon.

Sajid

···

On Mon, Nov 28, 2016 at 9:03 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

There is a new addon r.seasons which determines the number of seasons per pixel and extracts start and end dates for the given number of seasons from a time series.

The module is designed for noisy input, e.g.

time|value
0|0
1|0
2|1
3|0
4|1
5|1
6|1
7|0
8|1
9|1
10|1
11|1
12|0
13|0

with threshold 0.5 and minimum season length set to 3 would detect one season. Core season start is at 4, end at 10. Full season start is at 2, end at 10.

Markus M

On Wed, Nov 9, 2016 at 4:17 PM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Nikos Alexandris:

Is the number of cycles per year in the Wiki as well? Going through,
last time, I think I didn’t grasp that. Can you pin-point? It’s
exactly what we need at the moment.

Veronica Andreo:

Yes, maybe it is not well explained, but it is here:
https://grasswiki.osgeo.org/wiki/Temporal_data_processing#Filling_and_reconstructing_time_series_data_with_gaps_-_HANTS

and also in the manual under “NOTES”
https://grass.osgeo.org/grass70/manuals/addons/r.hants.html

The idea is, once you are happy with the result of hants, you ask for
amplitude outputs and with those amplitude maps (you’ll have one map per
frequency) you run r.series method=max_raster. This will give you the most
important frequency (according to amplitude value of that frequency) in
each pixel. If the result is that the most important frequency is 0, then
you have one cycle per year (that, if you use a base period of one year of
course).

Hope it is clearer now :slight_smile:

Nikos:

Yes. It was even before – just me read through quickly.

r.hants is awesome!

We have 24 Landsat 8 derived EVI2 maps (2 for each month) for one year.
Clouds and Water surfaces removed. Another set of "relatively normalised
images, using i.histo.match is also ready. We really need to “fix”
i.histo.match to crunch floats directly. The resulting ranges worry
me a bit – I just followed the “old” way as discussed some years ago in
a relevant thread (floats > integers > histo-matching > floats).

Anyhow, I am testing the following:

for NF in 4 5 6 7 8 ;do r.hants file=evi2_maps nf=$NF fet=0.05 dod=3 base_period=24 suffix=hants_nf$NF amplitude=amplitude_hants_nf_$NF phase=phase_hants_nf_$NF ;done

(thinking loudly… it would be super-nice to have t.rast.hants)

Not sure about dod. Perhaps it should also follow a patten like 3 4 5
6 and 7 for the above?

for NF in 5 6 7 8 ; do t.rast.series evi2_hants_nf_$NF method=max_raster output=dominant_frequencies_hants_nf_$NF --o

Just in case, the above should read:

for NF in 4 5 6 7 8 ;do r.series input=g.list rast pattern=amplitude*nf_${NF}* separator=comma method=max_raster output=dominant_frequencies_hants_nf_${NF} --o ;done

“Dominant” frequencies 0, 1, 2 and 3 appear to be within the areas
of our interest (agricultural surfaces). Very good. And convincing.
Yet I am learning to interpret this correctly. And the “phase” as well.
Reminds math studies, years ago.

It is a “good” thing to actually have similar dominant frequency “maps”
for all of the experimented Number of Frequencies.

A confirmation would be reassuring.

Thanks, Nikos

[rest deleted]

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

18

On Mon, Nov 7, 2016 at 3:01 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
...

As I am working this out in a remote workstation, it's a bit annoying
not to be able to play an animation directly. The GUI runs fine,
though slow, of course (via ssh -CY).

OT:
Try this in instead: X2Go (http://wiki.x2go.org). Just install the
server and the client packages respectively and connect (it does so
via ssh). No configuration needed at all except for specifying the
server name and which Desktop environment to use remotely :slight_smile: It even
works over 3G mobile.

cheers
Markus

19

* Markus Metz <markus.metz.giswork@gmail.com> [2016-11-28 09:03:30 +0100]:

There is a new addon r.seasons which determines the number of seasons per
pixel and extracts start and end dates for the given number of seasons from
a time series.

The module is designed for noisy input, e.g.

time|value
0|0
1|0
2|1
3|0
4|1
5|1
6|1
7|0
8|1
9|1
10|1
11|1
12|0
13|0

with threshold 0.5 and minimum season length set to 3 would detect one
season. Core season start is at 4, end at 10. Full season start is at 2,
end at 10.

Markus M

This is Awesome! Will have to test as soon as possible.
Thank you so much Markus.

Nikos