<div dir="ltr"><div><div><div><div><div><div><div><div><br><br>On Sun, Oct 22, 2017 at 9:47 PM, Sören Gebbert <<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>> wrote:<br>><br>> [snip]<br>><br>> > (Sorry for bottom-posting, want to break the discussion to a new<br>> > "thread")<br>> ><br>> > It is, and was, clear that the `t.rast.list` module does exactly<br>> > what it is named for. It lists the raster maps of an strds and their<br>> > properties.<br>> ><br>> > On the other hand, the skepsis on t.rast.univar to be able to report<br>> > maps with a where SQL query that accepts mean values as a "column" is of<br>> > interest.<br>><br>> But t.rast.univar is designed to compute the mean values. IMHO, you<br>> can't expect to have a selection option of a value that should be<br>> computed after selection?<br>> The beauty of GRASS GIS is its Unix-like design. Many dedicated<br>> modules that show their strength when combined with other Unix tools.<br>> How about using AWK?<br>><br>> > Univariate statistics are computed and reported. Is it really<br>> > such a computational overhead to keep that "mean", or any other of the<br>> > descriptive statistics, and re-loop over the maps to filter the output?<br>><br>> The temporal database has no "mean" column, so the current where<br>> option can not be used.<br>> However, its really simple to improve that. Feel free to implement the<br>> following steps into GRASS, to avoid extra post-processing by adding<br>> new statistical metadata columns:<br>><br>> 1. Patch the raster library to compute and store the mean value on the<br>> fly while writing the raster rows and write tests for validation. It<br>> already stores min and max, so this shouldn't be too difficult. In<br>> addition, you can compute many other statistical values on the fly<br>> like median and so on and add them to the raster map metadata. Be<br>> aware of backward compatibility for raster map layers that do not have<br>> the new metadata.<br>> 2. Patch <a href="http://r.info">r.info</a> to show the new statistical metadata and write tests<br>> to validate it. Be aware of backward compatibility.<br><br></div>Adding<br></div>- standard deviation<br></div>- number of non-NULL cells<br></div>- handling of maps that are all NULL<br></div>- compatibility between 32 bit and 64 bit versions<br></div>- compatibility between little endian and big endian systems<br><br></div>Having these statistics instantly available with <a href="http://r.info">r.info</a> could substantially speed up time series processing. Technically this is possible.<br><br></div>Markus M<br><div><div><div><div><div><div><div><div><br>> 3. Patch the temporal database SQL scripts to add the new statistical<br>> columns to raster layers and space time raster datasets (STRDS) e.g.:<br>> min_mean, max_mean, min_median, max_median, ... .<br>> 4. Patch the temporal framework and include the new statistical<br>> columns in the space-time classes for raster layers and STRDS and<br>> write tests for validation. Make sure your improvements are compatible<br>> with older GRASS GIS temporal database versions.<br>> 5. Patch the temporal modules to make use the new statistical columns<br>> (where queries, <a href="http://t.info">t.info</a> ...) and write tests for validation. Be aware<br>> of backward compatibility.<br>> 6. Patch r.univar and t.rast.univar to compute only the remaining<br>> statistical values, write tests and update the documentation.<br>> 7. Update the documentation about raster map layers and the temporal<br>> framework using the new statistical metadata for raster maps and STRDS<br>><br>> This is a nice little GRASS development project. :)<br>><br>> > I feel it's worth it to avoid the extra post-processing step, outside of<br>> > GRASS' environment. May I open an enhancement request?<br>><br>> Yes, feel free to open an enhancement request. The workflow howto<br>> implement this is clear i think.<br>><br>> Best regards<br>> Sören<br>><br>> ><br>> > Thank you, Nikos<br>> ><br>> _______________________________________________<br>> grass-dev mailing list<br>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-dev">https://lists.osgeo.org/mailman/listinfo/grass-dev</a><br><br></div></div></div></div></div></div></div></div></div>