<div dir="ltr">Hello Sajid!<div><br></div><div>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. </div><div><br></div><div>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) :-)</div><div><br></div><div>Cheers, </div><div>Vero</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-31 11:00 GMT+01:00 Sajid Pareeth <span dir="ltr"><<a href="mailto:spareeth@gmail.com" target="_blank">spareeth@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi all<br><br></div>Thanks MarkusM and Vero for the detailed follow up.<br><br>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).<br><br></div><div>But it seems inadequate when it comes to determine the <b>start and end time of the growing season</b> in a year. I am looking for a solution along the line as given in this paper:<br><br><a href="https://www.researchgate.net/publication/238418948_Measuring_Phenological_Variability_From_Satellite_Imagery" target="_blank">https://www.researchgate.net/<wbr>publication/238418948_<wbr>Measuring_Phenological_<wbr>Variability_From_Satellite_<wbr>Imagery</a><br><br></div><div>I think once we have the start and end of growing season, rest of the related parameters are easy to compute.<br><br></div><div>May be, there already exists a way in GRASS to do it using TGRASS !!.<br><br></div><div>Regards<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Sajid<br></div><div><br><br></div><div><br><br></div><div><br><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 10:40 AM, Veronica Andreo <span dir="ltr"><<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Nikos and all :)<div><br></div><div>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.</div><div><br></div><div>@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]</div><div><br></div><div>@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].</div><div><br></div><div>Best,</div><div>Vero</div><div><br></div><div>[0] <a href="https://grasswiki.osgeo.org/wiki/Temporal_data_processing" target="_blank">https://grasswiki.osgeo.org/wi<wbr>ki/Temporal_data_processing</a></div><div>[1] <a href="https://grasswiki.osgeo.org/wiki/Temporal_data_processing/GRASS_R_raster_time_series_processing" target="_blank">https://grasswiki.osgeo.org/wi<wbr>ki/Temporal_data_processing/GR<wbr>ASS_R_raster_time_series_proce<wbr>ssing</a></div><div>[2] <a href="http://modb.oce.ulg.ac.be/mediawiki/index.php/DINEOF" target="_blank">http://modb.oce.ulg.ac.be/medi<wbr>awiki/index.php/DINEOF</a></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_2367783786116779393h5">2016-10-31 10:06 GMT+01:00 Nikos Alexandris <span dir="ltr"><<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_2367783786116779393h5">* Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com" target="_blank">markus.metz.giswork@gmail.com</a><wbr>> [2016-10-30 22:30:46 +0100]:<div><div class="m_2367783786116779393m_-6445605480316004871h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Oct 30, 2016 at 12:37 PM, Nikos Alexandris<br>
<<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nikos Alexandris:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
is there a GRASS-native, of GRASS-friendly, practical tool or tutorial<br>
or implementation of models, as in the TIMESAT [0] software or SPIRITS<br>
[1], to exctract phenological parameters from NDVI (or, preferrably<br>
EVI2) times series?<br>
<br>
Thank you, Nikos<br>
<br>
[0] <a href="http://web.nateko.lu.se/timesat/timesat.asp" rel="noreferrer" target="_blank">http://web.nateko.lu.se/timesa<wbr>t/timesat.asp</a><br>
[1] <a href="http://spirits.jrc.ec.europa.eu/download/software/" rel="noreferrer" target="_blank">http://spirits.jrc.ec.europa.e<wbr>u/download/software/</a><br>
</blockquote></blockquote>
<br>
<br>
Sajid Pareeth:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was also looking for the same functionalities very recently. Closest<br>
solution i could find is the 'greenbrown' package in R. Atleast we could<br>
make use of the GRASS-R interface to implement the work flow.<br>
<br>
Phenology function in this package has a good comprehensive list of<br>
functions as in timestat and spirits.<br>
See fig4 here: <a href="http://greenbrown.r-forge.r-project.org/phenology.php" rel="noreferrer" target="_blank">http://greenbrown.r-forge.r-pr<wbr>oject.org/phenology.php</a><br>
<br>
If you find anything else, please do post here.<br>
<br>
And above all, it would be really great to have these functionalities in<br>
GRASS ;)<br>
</blockquote>
<br>
<br>
Thank you Sajid.<br>
<br>
As I am not an expert in cropping cycles monitoring, I<br>
naively thought there would be more or less some ready to use tools in<br>
the GFOSS domain (TIMESAT requires Matlab, SPIRITS works only under<br>
Windows).<br>
<br>
R is good, but there is still the back-and-forth step.  There is also a<br>
"french" tool for QGIS:<br>
<a href="https://plugins.qgis.org/plugins/VERSAO_VegaMonitor/" rel="noreferrer" target="_blank">https://plugins.qgis.org/plugi<wbr>ns/VERSAO_VegaMonitor/</a><br>
<br>
At the moment I am looking for an over-simplified way to just<br>
hint/classify surfaces on which multiple cropping cycles per year take<br>
place (related to industrial agricultural surfaces).  Something to get<br>
going.<br>
<br>
Given TGRASS, if we find a practical algorithm, it shouldn't be too hard<br>
to implement it GRASS-natively.<br>
</blockquote></blockquote>
<br></div></div>
Markus M:<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[ currently trying to get a grip on MODIS version 6 time series ]<br>
<br>
In theory, extracting seasons such as cropping cycles is quite easy to<br>
implement: whenever a parameter in a time series is above/below a<br>
given threshold, start/stop the season. The question is how to store<br>
the results for multiple cropping cycles: a separate raster for each<br>
cycle and each start and stop date?<br>
</blockquote>
<br></span>
May Yann's addon i.lmf (Temporal Local Maximum Fitting of vegetation<br>
indices) be useful within the context? (can't test it, it<br>
segfaults and I have no time to debug these days).<span class="m_2367783786116779393m_-6445605480316004871HOEnZb"><font color="#888888"><br>
<br>
Nikos</font></span><span class="m_2367783786116779393m_-6445605480316004871im m_2367783786116779393m_-6445605480316004871HOEnZb"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For preparation, I think that GRASS needs more tools to remove<br>
outliers and fill gaps in time series. A commonly used tool is local<br>
weighted regression, also known as LOESS or LOWESS.<br>
<br>
I would like to have a module like r.series.lwr (local weighted<br>
regression) in GRASS with the options<br>
<br>
* order=1,2,3 with 1 = linear regression, 2 = second order polynomial<br>
regression, 3 = third order polynomial regression<br>
* dod = degree of over-determination because for e.g. linear<br>
regression you need only 2 data points but that gives an exact fit and<br>
does not remove outliers, so a number of additional points<br>
(over-determination) is needed for smoothing. The number of additional<br>
points should not be too large, otherwise local real fluctuations can<br>
not be represented by the regression and are smoothed out.<br>
* weighing function: default tricube, additional options uniform,<br>
triangular, epanechnikov, quartic, triweight, cosine<br>
* extreme: iteratively replace outliers with the estimate until a<br>
given goodness of fit (e.g. coefficient of determination) is obtained<br>
<br>
Output: one output for each input map.<br>
<br>
Currently I am using r.hants a lot, but r.hants assumes more or less<br>
regular cycles in the time series (e.g. NDVI) and fits a single<br>
function to the complete time series, while a local weighted<br>
regression can work with much less points and can still capture<br>
short-term non-linear fluctuations.<br>
<br>
Markus M<br>
</blockquote></span></div></div><div class="m_2367783786116779393m_-6445605480316004871HOEnZb"><div class="m_2367783786116779393m_-6445605480316004871h5">
______________________________<wbr>_________________<span><br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/grass-user</a></span></div></div></blockquote></div><br></div>
<br>______________________________<wbr>_________________<br>
grass-user mailing list<br>
<a href="mailto:grass-user@lists.osgeo.org" target="_blank">grass-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/grass-user</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>