[GRASS-dev] Which are the strds 'columns'?

[Markus Metz]

On Sun, Oct 22, 2017 at 9:47 PM, Sören Gebbert <soerengebbert at googlemail.com>
wrote:
>
> [snip]
>
> > (Sorry for bottom-posting, want to break the discussion to a new
> > "thread")
> >
> > It is, and was, clear that the `t.rast.list` module does exactly
> > what it is named for. It lists the raster maps of an strds and their
> > properties.
> >
> > On the other hand, the skepsis on t.rast.univar to be able to report
> > maps with a where SQL query that accepts mean values as a "column" is of
> > interest.
>
> But t.rast.univar is designed to compute the mean values. IMHO, you
> can't expect to have a selection option of a value that should be
> computed after selection?
> The beauty of GRASS GIS is its Unix-like design. Many dedicated
> modules that show their strength when combined with other Unix tools.
> How about using AWK?
>
> > Univariate statistics are computed and reported. Is it really
> > such a computational overhead to keep that "mean", or any other of the
> > descriptive statistics, and re-loop over the maps to filter the output?
>
> The temporal database has no "mean" column, so the current where
> option can not be used.
> However, its really simple to improve that. Feel free to implement the
> following steps into GRASS, to avoid extra post-processing by adding
> new statistical metadata columns:
>
> 1. Patch the raster library to compute and store the mean value on the
> fly while writing the raster rows and write tests for validation. It
> already stores min and max, so this shouldn't be too difficult. In
> addition, you can compute many other statistical values on the fly
> like median and so on and add them to the raster map metadata. Be
> aware of backward compatibility for raster map layers that do not have
> the new metadata.
> 2. Patch r.info to show the new statistical metadata and write tests
> to validate it. Be aware of backward compatibility.

Adding
- standard deviation
- number of non-NULL cells
- handling of maps that are all NULL
- compatibility between 32 bit and 64 bit versions
- compatibility between little endian and big endian systems

Having these statistics instantly available with r.info could substantially
speed up time series processing. Technically this is possible.

Markus M

> 3. Patch the temporal database SQL scripts to add the new statistical
> columns to raster layers and space time raster datasets (STRDS) e.g.:
> min_mean, max_mean, min_median, max_median, ... .
> 4. Patch the temporal framework and include the new statistical
> columns in the space-time classes for raster layers and STRDS and
> write tests for validation. Make sure your improvements are compatible
> with older GRASS GIS temporal database versions.
> 5. Patch the temporal modules to make use the new statistical columns
> (where queries, t.info ...) and write tests for validation. Be aware
> of backward compatibility.
> 6. Patch r.univar and t.rast.univar to compute only the remaining
> statistical values, write tests and update the documentation.
> 7. Update the documentation about raster map layers and the temporal
> framework using the new statistical metadata for raster maps and STRDS
>
> This is a nice little GRASS development project. :)
>
> > I feel it's worth it to avoid the extra post-processing step, outside of
> > GRASS' environment. May I open an enhancement request?
>
> Yes, feel free to open an enhancement request. The workflow howto
> implement this is clear i think.
>
> Best regards
> Sören
>
> >
> > Thank you, Nikos
> >
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20171022/c6b97e69/attachment.html>