[GRASS-dev] Re: Problem when loading GRASS 6 raster with large
integer values into R via r.out.bin
Roger.Bivand at nhh.no
Thu Sep 18 05:10:46 EDT 2008
On Thu, 18 Sep 2008, Rainer M Krug wrote:
> On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
>> Markus Neteler <neteler <at> osgeo.org> writes:
>>> On Tue, Sep 16, 2008 at 6:50 PM, Rainer M Krug <r.m.krug <at> gmail.com> wrote:
>>>> I have a problem with importing raster maps of type CELL into R -
>>>> larger values become "wrapped" around as r.out.bin saves the raster
>>>> values as shortint values. Is there any possibility to change that
>>>> behaviour, or at least convert the exported values automatically from
>>>> integer to float?
>>> My suggestion to Roger was to change to r.out.gdal:
>>> Since the GRASS-R interface knows the GRASS version it could be
>>> conditionalized upon GRASS >= 6.3.0 for r.out.gdal, r.out.bin otherwise.
>> The actual suggestion was not to use r.out.gdal, but to use the GRASS GDAL
>> plugin if present. Then readRAST6() would use readGDAL() to read the
>> raster directly if possible, using the GRASS plugin driver. This avoids
>> creating a temporary file, but could be used directly from readGDAL() -
>> it just sets up the correct path and file name.
>>> Something has been implemented but it needs/ed to be activated
>>> by setting parameters (at least in June, didn't check later).
>> At present with default plugin=NULL, readRAST6() checks the list of drivers
>> and if "GRASS" is present, and if the current and raster file regions agree,
>> and only one raster is requested, it imports the raster directly into a
>> SpatialGridDataFrame object using readGDAL(). If Rainer's data are in a
>> raster that has the same region as the current region, the plugin would
>> solve the problem.
> No - the raster is covering a larger area, and the current region
> covers only a small area of the raster.
OK, so that really only leaves r.out.bin in readRAST6() after having made
a float or double copy in GRASS, unless the -i flag gets us anywhere (I'm
afraid it is hardwired to CELL_TYPE, which takes us back to 16-bits)?
>> I can look at using r.out.gdal for making the temporary file, but IIRC, it
>> suffers from the region mismatch problem that r.out.bin solves by resampling
>> on the fly.
>> Hope this helps,
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no
More information about the grass-dev