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 <[email protected]> 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#Fi >>> lling_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 :) >>> >> > 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user >
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
