Hi,
sometimes it is convenient to scale/shift input maps on the fly during
the import in order to avoid an extra step with r.mapcalc (think: tons
of scaled Landsat data etc).
https://grass.osgeo.org/grass70/manuals/r.series.accumulate.html
comes with
scale=float
Scale factor for input
Default: 1.0
shift=float
Shift factor for input
Default: 0.0
which might make sense also here. Maybe the type propagation
(CELL/FCELL/DCELL is an issue though.
Ideas?
thanks,
Markus
Markus Neteler wrote:
sometimes it is convenient to scale/shift input maps on the fly during
the import in order to avoid an extra step with r.mapcalc (think: tons
of scaled Landsat data etc).
Perhaps a better option (albeit one which requires some amount of
design, rathern than just coding) would be to have this performed
during read, i.e. similarly to how reclass maps are handled.
This would allow it to be used with r.external maps without needing to
make a copy (which largely defeats the point of using r.external).
It would also allow most maps to be stored as CELL, with better
precision than FCELL (32 bits rather than 24) and less space than
DCELL. It's quite rare for physical measurements to be sufficiently
accurate that 32 bits isn't enough.
--
Glynn Clements <glynn@gclements.plus.com>
On Sat, May 21, 2016 at 7:45 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
sometimes it is convenient to scale/shift input maps on the fly during
the import in order to avoid an extra step with r.mapcalc (think: tons
of scaled Landsat data etc).Perhaps a better option (albeit one which requires some amount of
design, rathern than just coding) would be to have this performed
during read, i.e. similarly to how reclass maps are handled.This would allow it to be used with r.external maps without needing to
make a copy (which largely defeats the point of using r.external).It would also allow most maps to be stored as CELL, with better
precision than FCELL (32 bits rather than 24) and less space than
DCELL. It's quite rare for physical measurements to be sufficiently
accurate that 32 bits isn't enough.
The latter idea, to store all data as CELL and the derive the
different representations from that I quite like.
As an example: Temperature data are often shipped as e.g. degree
Celsius * 10 or degree Celsius * 100. While I prefer to continue in
GRASS with Celsius (hence divide by the respective value) it is a
waste of disk space to then make all subsequent maps e.g. DCELL since
that precision isn't there anyway available from the original data.
As soon as 7.2.svn is branched off, we could consider to implement
such a change in trunk and publish it later as 7.4 or even 8.
Markus
On Sun, May 22, 2016 at 12:09 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sat, May 21, 2016 at 7:45 AM, Glynn Clements <glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
sometimes it is convenient to scale/shift input maps on the fly during
the import in order to avoid an extra step with r.mapcalc (think: tons
of scaled Landsat data etc).Perhaps a better option (albeit one which requires some amount of
design, rathern than just coding) would be to have this performed
during read, i.e. similarly to how reclass maps are handled.This would allow it to be used with r.external maps without needing to
make a copy (which largely defeats the point of using r.external).It would also allow most maps to be stored as CELL, with better
precision than FCELL (32 bits rather than 24) and less space than
DCELL. It's quite rare for physical measurements to be sufficiently
accurate that 32 bits isn't enough.The latter idea, to store all data as CELL and the derive the
different representations from that I quite like.As an example: Temperature data are often shipped as e.g. degree
Celsius * 10 or degree Celsius * 100. While I prefer to continue in
GRASS with Celsius (hence divide by the respective value) it is a
waste of disk space to then make all subsequent maps e.g. DCELL since
that precision isn't there anyway available from the original data.As soon as 7.2.svn is branched off, we could consider to implement
such a change in trunk and publish it later as 7.4 or even 8.
I found also a related ticket:
https://trac.osgeo.org/grass/ticket/1640
Markus