[GRASS-dev] r.in.gdal: add scale and shift parameters?
Markus Neteler
neteler at osgeo.org
Wed Dec 7 14:35:57 PST 2016
On Sun, May 22, 2016 at 12:09 PM, Markus Neteler <neteler at osgeo.org> wrote:
> On Sat, May 21, 2016 at 7:45 AM, Glynn Clements <glynn at 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
More information about the grass-dev
mailing list