[GRASS-dev] Re: Problem when loading GRASS 6 raster with large integer values into R via r.out.bin

Markus Neteler neteler at osgeo.org
Thu Sep 18 04:12:28 EDT 2008


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:
>> > Hi
>> >
>> > 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:
>>  http://lists.osgeo.org/pipermail/grass-stats/2008-June/000799.html
>>
>> 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.

Well, not by me (maybe I was unclear?). I wrote:

> AFAIK the plugin delivers only *original* raster resolution and extent (that's
> why r.out.gdal was written in C to replace a former plugin based shell script).
> So, unless the plugin is changed here it might not be that useful for raster
> data *if* the GRASS behaviour of respecting raster settings during export
> should be maintained.

means:
- the GDAL plugin is no option here since it does not respect current region
  settings
- r.out.gdal is good since it does the job (AFAIK). Written in C
- r.out.gdal.sh is bad since it used the plugin.

...
> 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.

I am confused. AFAIK the behaviour of r.out.bin and r.out.gdal is the same.
Perhaps you mean r.out.gdal.sh?

Best
Markus


More information about the grass-dev mailing list