On Sun, May 22, 2016 at 12:09 PM, Markus Neteler <[email protected]> wrote: > On Sat, May 21, 2016 at 7:45 AM, Glynn Clements <[email protected]> > 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
