[GRASS-dev] [GRASS GIS] #2867: Add modifier parameter to r.series
GRASS GIS
trac at osgeo.org
Mon Jan 18 14:06:02 PST 2016
#2867: Add modifier parameter to r.series
--------------------------+-------------------------
Reporter: pvanbosgeo | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.4
Component: Raster | Version: unspecified
Resolution: | Keywords: r.series
CPU: Unspecified | Platform: Unspecified
--------------------------+-------------------------
Comment (by glynn):
Replying to [ticket:2867 pvanbosgeo]:
> An useful enhancement of r.series would be to add a "modifier" (or
similar name) parameter to r.series
> which would allow to calculate the statistic defined by "method" on a
modified version of the maps (e.g. squared, square root, log, sin, cos,
etc.).
My main concern is that this is going to open the door to a never-ending
stream of requests to add more modifiers or more features (e.g. parametric
modifiers, or selecting modifiers on a per-output bases) until we end up
having to embed either r.mapcalc or Python into r.series.
OTOH, I'm aware that the usual solution (use in conjunction with
r.mapcalc) has a significant overhead when you're potentially dealing with
hundreds of input maps. Even so, I'd be inclined to limit the available
modifiers to those which seem likely to be particularly useful (only
sqrt/x^2 and log/exp spring to mind); there are a *lot* of real->real
functions in the standard math library.
As for the patch itself, I'd suggest:
1. Determining the function during initialisation and setting a function
pointer, rather than performing the test in the inner loop. Multiple
strcmp()s inside a triple-nested loop (rows*columns*inputs) are likely to
add significant overhead.
2. Vectorising the operations so that the dispatch is only done once per
row, not per value. Even an indirect call via a function pointer may be
more expensive than the function itself (some math functions may compile
to a single FPU instruction). The simplest way to do this would be to
modify inputs[].buf[] in-place after reading.
In that regard, maybe we should try to extract the relevant portions of
r.mapcalc to a separate library so that they can be re-used here?
Or maybe a better option would be to just package up the raster-I/O loops
as a Python module so that the actual processing can be implemented as
Python functions which convert a 2D (inputs*columns) array into a set of
1D arrays (one per output).
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2867#comment:2>
GRASS GIS <https://grass.osgeo.org>
More information about the grass-dev
mailing list