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?
Thanks
Rainer
On Tue, Sep 16, 2008 at 6:50 PM, Rainer M Krug <r.m.krug@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.
Something has been implemented but it needs/ed to be activated
by setting parameters (at least in June, didn't check later).
Markus
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.htmlSince 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.
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,
Roger
Markus
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand@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.htmlSince 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
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand@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.htmlSince 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.
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,
Roger
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
On Thu, 18 Sep 2008, Rainer M Krug wrote:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand@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.htmlSince 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)?
Roger
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,
Roger
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Roger Bivand
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@nhh.no
Markus Neteler <neteler <at> osgeo.org> writes:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand <at>
nhh.no> wrote:
> Markus Neteler <neteler <at> osgeo.org> writes:
>
>>
...
Well, not by me (maybe I was unclear?). I wrote:
...
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.
OK, probably my misunderstanding, I thought that the only concern was
using the plugin to avoid any temporary file wastage of time or space.
I can revisit this in relation to using r.out.gdal for GRASS >= 6.3
instead of r.out.bin - in which case I can make r.out.gdal use 32
bits for integers and 64 bits for float/doubles.
Roger
Perhaps you mean r.out.gdal.sh?
Best
Markus
Roger Bivand <Roger.Bivand <at> nhh.no> writes:
Markus Neteler <neteler <at> osgeo.org> writes:
>
> On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand <at>
> nhh.no> wrote:
> > Markus Neteler <neteler <at> osgeo.org> writes:
> >
> 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
I can revisit this in relation to using r.out.gdal for GRASS >= 6.3
instead of r.out.bin - in which case I can make r.out.gdal use 32
bits for integers and 64 bits for float/doubles.
Committed on R-spatial sourceforge CVS, new flag useGDAL=FALSE for now
default, uses Int32 for CELL, so maybe could be tried to see if it works
better than r.out.bin.
If it does, I'll change writeRAST6() too, change the default to TRUE, and
release.
Roger
Roger
> Perhaps you mean r.out.gdal.sh?
>
> Best
> Markus
>
OK - I finally got around to testing it.
I installed spgrass6 as well as rgdal from source, as spgrass6 needed
a newer version of rgdal then available in CRAN (Error: package
'rgdal' 0.5-25 was found, but >= 0.5.26 is required by 'spgrass6').
It is working, when using useGDAL=TRUE. See output below:
In GRASS:
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=ros_2016.max
min=0
max=36852
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R >
In R:
x <- readRAST6("ros_2016.max",useGDAL=FALSE )
Creating BIL support files...
Header File =
/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.hdr
World File =
/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.wld
Exporting raster as integer values (bytes=2)
Using the current region settings...
north=6247000.000000
south=6195000.000000
east=270200.000000
west=251000.000000
r=520
c=192
100%
range(x[[1]], na.rm=TRUE)
[1] -31916 30755
x <- readRAST6("ros_2016.max",useGDAL=TRUE )
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format.
WARNING: Input raster map constains cells with NULL-value (no-data). The
value 999 was used to represent no-data values in the input
map.You can specify nodata value by nodata parameter.
/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max
has GDAL driver GTiff
and has 520 rows and 192 columns
range(x[[1]], na.rm=TRUE)
[1] 0 36852
I would suggest that you proceed as suggested below.
Thanks
Rainer
On Thu, Sep 18, 2008 at 11:01 PM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
Roger Bivand <Roger.Bivand <at> nhh.no> writes:
Markus Neteler <neteler <at> osgeo.org> writes:
>
> On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand <at>
> nhh.no> wrote:
> > Markus Neteler <neteler <at> osgeo.org> writes:
> >
> 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 CI can revisit this in relation to using r.out.gdal for GRASS >= 6.3
instead of r.out.bin - in which case I can make r.out.gdal use 32
bits for integers and 64 bits for float/doubles.Committed on R-spatial sourceforge CVS, new flag useGDAL=FALSE for now
default, uses Int32 for CELL, so maybe could be tried to see if it works
better than r.out.bin.If it does, I'll change writeRAST6() too, change the default to TRUE, and
release.Roger
Roger
> Perhaps you mean r.out.gdal.sh?
>
> Best
> Markus
>_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
On Tue, 23 Sep 2008, Rainer M Krug wrote:
OK - I finally got around to testing it.
I installed spgrass6 as well as rgdal from source, as spgrass6 needed
a newer version of rgdal then available in CRAN (Error: package
'rgdal' 0.5-25 was found, but >= 0.5.26 is required by 'spgrass6').
Hi,
I had to modify rgdal to get writeRAST6() to use writeGDAL() - there was a bug in otherwise unused code to setting the NODATA value in rgdal. Could you try this out too? Should I try to trap the verbose messages?
Best wishes,
Roger
It is working, when using useGDAL=TRUE. See output below:
In GRASS:
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=ros_2016.max
min=0
max=36852
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R >In R:
x <- readRAST6("ros_2016.max",useGDAL=FALSE )
Creating BIL support files...
Header File =
/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.hdr
World File =
/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.wld
Exporting raster as integer values (bytes=2)
Using the current region settings...
north=6247000.000000
south=6195000.000000
east=270200.000000
west=251000.000000
r=520
c=192
100%range(x[[1]], na.rm=TRUE)
[1] -31916 30755
x <- readRAST6("ros_2016.max",useGDAL=TRUE )
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF format.
WARNING: Input raster map constains cells with NULL-value (no-data). The
value 999 was used to represent no-data values in the input
map.You can specify nodata value by nodata parameter.
/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max
has GDAL driver GTiff
and has 520 rows and 192 columnsrange(x[[1]], na.rm=TRUE)
[1] 0 36852
I would suggest that you proceed as suggested below.
Thanks
Rainer
On Thu, Sep 18, 2008 at 11:01 PM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
Roger Bivand <Roger.Bivand <at> nhh.no> writes:
Markus Neteler <neteler <at> osgeo.org> writes:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand <at>
nhh.no> wrote:Markus Neteler <neteler <at> osgeo.org> writes:
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 CI can revisit this in relation to using r.out.gdal for GRASS >= 6.3
instead of r.out.bin - in which case I can make r.out.gdal use 32
bits for integers and 64 bits for float/doubles.Committed on R-spatial sourceforge CVS, new flag useGDAL=FALSE for now
default, uses Int32 for CELL, so maybe could be tried to see if it works
better than r.out.bin.If it does, I'll change writeRAST6() too, change the default to TRUE, and
release.Roger
Roger
Perhaps you mean r.out.gdal.sh?
Best
Markus_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Roger Bivand
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@nhh.no
On Tue, Sep 23, 2008 at 1:11 PM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
On Tue, 23 Sep 2008, Rainer M Krug wrote:
OK - I finally got around to testing it.
I installed spgrass6 as well as rgdal from source, as spgrass6 needed
a newer version of rgdal then available in CRAN (Error: package
'rgdal' 0.5-25 was found, but >= 0.5.26 is required by 'spgrass6').Hi,
I had to modify rgdal to get writeRAST6() to use writeGDAL() - there was a
bug in otherwise unused code to setting the NODATA value in rgdal. Could you
try this out too? Should I try to trap the verbose messages?
It is working for me, although when I am using useGDAL=FALSE, it is
converted from integer to double (see below).
In R:
x <- readRAST6("ros_2016.max",useGDAL=TRUE )
writeRAST6(x,"xuseGDALFALSE",useGDAL=FALSE )
100%
writeRAST6(x,"xuseGDALTRUE",useGDAL=TRUE )
WARNING: Datum <unknown> not recognised by GRASS and no parameters found.
Projection of input dataset and current location appear to match
100%
r.in.gdal complete.
In GRASS:
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=xuseGDALTRUE
min=0
max=36852
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=xuseGDALFALSE
min=0.000000
max=36852.000000
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R >
Concerning trapping of the verbose messages, I think it would be a
good idea to do the following:
1) add a parameter verbose=TRUE in readRAST6 and writeRAST6 to enable
or disable it
2) if possible, raise an R error, if GRASS returns ERROR
This is one approach which I would be interested to use as well when
calling GRASS commands from R.
What is the
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in
TIFF format.
mean? Is it relevant for R?
Thanks
Rainer
Best wishes,
Roger
It is working, when using useGDAL=TRUE. See output below:
In GRASS:
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=ros_2016.max
min=0
max=36852
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R >In R:
x <- readRAST6("ros_2016.max",useGDAL=FALSE )
Creating BIL support files...
Header File =/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.hdr
World File =/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.wld
Exporting raster as integer values (bytes=2)
Using the current region settings...
north=6247000.000000
south=6195000.000000
east=270200.000000
west=251000.000000
r=520
c=192
100%range(x[[1]], na.rm=TRUE)
[1] -31916 30755
x <- readRAST6("ros_2016.max",useGDAL=TRUE )
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF
format.
WARNING: Input raster map constains cells with NULL-value (no-data). The
value 999 was used to represent no-data values in the input
map.You can specify nodata value by nodata parameter./home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max
has GDAL driver GTiff
and has 520 rows and 192 columnsrange(x[[1]], na.rm=TRUE)
[1] 0 36852
I would suggest that you proceed as suggested below.
Thanks
Rainer
On Thu, Sep 18, 2008 at 11:01 PM, Roger Bivand <Roger.Bivand@nhh.no>
wrote:Roger Bivand <Roger.Bivand <at> nhh.no> writes:
Markus Neteler <neteler <at> osgeo.org> writes:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand <at>
nhh.no> wrote:Markus Neteler <neteler <at> osgeo.org> writes:
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 CI can revisit this in relation to using r.out.gdal for GRASS >= 6.3
instead of r.out.bin - in which case I can make r.out.gdal use 32
bits for integers and 64 bits for float/doubles.Committed on R-spatial sourceforge CVS, new flag useGDAL=FALSE for now
default, uses Int32 for CELL, so maybe could be tried to see if it works
better than r.out.bin.If it does, I'll change writeRAST6() too, change the default to TRUE, and
release.Roger
Roger
Perhaps you mean r.out.gdal.sh?
Best
Markus_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
Roger Bivand
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@nhh.no
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
On Tue, 23 Sep 2008, Rainer M Krug wrote:
On Tue, Sep 23, 2008 at 1:11 PM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
On Tue, 23 Sep 2008, Rainer M Krug wrote:
OK - I finally got around to testing it.
I installed spgrass6 as well as rgdal from source, as spgrass6 needed
a newer version of rgdal then available in CRAN (Error: package
'rgdal' 0.5-25 was found, but >= 0.5.26 is required by 'spgrass6').Hi,
I had to modify rgdal to get writeRAST6() to use writeGDAL() - there was a
bug in otherwise unused code to setting the NODATA value in rgdal. Could you
try this out too? Should I try to trap the verbose messages?It is working for me, although when I am using useGDAL=FALSE, it is
converted from integer to double (see below).In R:
x <- readRAST6("ros_2016.max",useGDAL=TRUE )
writeRAST6(x,"xuseGDALFALSE",useGDAL=FALSE )100%
writeRAST6(x,"xuseGDALTRUE",useGDAL=TRUE )
WARNING: Datum <unknown> not recognised by GRASS and no parameters found.
Projection of input dataset and current location appear to match
100%
r.in.gdal complete.In GRASS:
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=xuseGDALTRUE
min=0
max=36852
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=xuseGDALFALSE
min=0.000000
max=36852.000000
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R >Concerning trapping of the verbose messages, I think it would be a
good idea to do the following:1) add a parameter verbose=TRUE in readRAST6 and writeRAST6 to enable
or disable it
I'll try to do this using the existing ignore.stderr= in system(), but it may not stop everything.
2) if possible, raise an R error, if GRASS returns ERROR
If GRASS fails, the next actions on the R side should fail. I can look at trying to capture the $? value returned by the R command in certain places, but this involves a shell dependency that isn't convenient (as in the native Windows version).
This is one approach which I would be interested to use as well when
calling GRASS commands from R.
What is the
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in
TIFF format.
mean? Is it relevant for R?
Almost certainly not, it is a GDAL message, not an error as such, and could be got round (I think) in r.out.gdal by only creating colour tables for the GTiff driver if the conditions are met.
Roger
Thanks
Rainer
Best wishes,
Roger
It is working, when using useGDAL=TRUE. See output below:
In GRASS:
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R > r.info -r
map=ros_2016.max
min=0
max=36852
[Raster MASK present]
GRASS 6.3.0 (grass):~/Documents/Projects/AlienSpread/R >In R:
x <- readRAST6("ros_2016.max",useGDAL=FALSE )
Creating BIL support files...
Header File =/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.hdr
World File =/home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max.wld
Exporting raster as integer values (bytes=2)
Using the current region settings...
north=6247000.000000
south=6195000.000000
east=270200.000000
west=251000.000000
r=520
c=192
100%range(x[[1]], na.rm=TRUE)
[1] -31916 30755
x <- readRAST6("ros_2016.max",useGDAL=TRUE )
ERROR 6: SetColorTable() only supported for Byte or UInt16 bands in TIFF
format.
WARNING: Input raster map constains cells with NULL-value (no-data). The
value 999 was used to represent no-data values in the input
map.You can specify nodata value by nodata parameter./home/rkrug/Documents/Projects/AlienSpread/R/../grass/simulation/.tmp/ecolmod/ros_2016.max
has GDAL driver GTiff
and has 520 rows and 192 columnsrange(x[[1]], na.rm=TRUE)
[1] 0 36852
I would suggest that you proceed as suggested below.
Thanks
Rainer
On Thu, Sep 18, 2008 at 11:01 PM, Roger Bivand <Roger.Bivand@nhh.no>
wrote:Roger Bivand <Roger.Bivand <at> nhh.no> writes:
Markus Neteler <neteler <at> osgeo.org> writes:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand <Roger.Bivand <at>
nhh.no> wrote:Markus Neteler <neteler <at> osgeo.org> writes:
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 CI can revisit this in relation to using r.out.gdal for GRASS >= 6.3
instead of r.out.bin - in which case I can make r.out.gdal use 32
bits for integers and 64 bits for float/doubles.Committed on R-spatial sourceforge CVS, new flag useGDAL=FALSE for now
default, uses Int32 for CELL, so maybe could be tried to see if it works
better than r.out.bin.If it does, I'll change writeRAST6() too, change the default to TRUE, and
release.Roger
Roger
Perhaps you mean r.out.gdal.sh?
Best
Markus_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
Roger Bivand
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@nhh.no
--
Roger Bivand
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@nhh.no
> Concerning trapping of the verbose messages, I think it would be a
> good idea to do the following:
>
> 1) add a parameter verbose=TRUE in readRAST6 and writeRAST6 to enable
> or disable it
Roger:
I'll try to do this using the existing ignore.stderr= in system(), but
it may not stop everything.
When possible it should utilize the --quiet and --verbose flags which all
GRASS modules listen for, or set the GRASS_VERBOSE environment variable
to the required level. Blindly throwing all stderr messages to /dev/null
should be a last resort, there may be something important there.
Hamish
On Wed, Sep 24, 2008 at 4:45 AM, Hamish <hamish_b@yahoo.com> wrote:
> Concerning trapping of the verbose messages, I think it would be a
> good idea to do the following:
>
> 1) add a parameter verbose=TRUE in readRAST6 and writeRAST6 to enable
> or disable itRoger:
I'll try to do this using the existing ignore.stderr= in system(), but
it may not stop everything.When possible it should utilize the --quiet and --verbose flags which all
GRASS modules listen for, or set the GRASS_VERBOSE environment variable
to the required level. Blindly throwing all stderr messages to /dev/null
should be a last resort, there may be something important there.
I think that's a good idea - to use the same standard flags that GRASS
is also using (including the --overwrite which would be nice to have
in the writeRAST6 by the way).
I will keep that approach in mind for other commands interfacing to GRASS.
Rainer
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa
On Wed, 24 Sep 2008, Rainer M Krug wrote:
On Wed, Sep 24, 2008 at 4:45 AM, Hamish <hamish_b@yahoo.com> wrote:
Concerning trapping of the verbose messages, I think it would be a
good idea to do the following:1) add a parameter verbose=TRUE in readRAST6 and writeRAST6 to enable
or disable itRoger:
I'll try to do this using the existing ignore.stderr= in system(), but
it may not stop everything.When possible it should utilize the --quiet and --verbose flags which all
GRASS modules listen for, or set the GRASS_VERBOSE environment variable
to the required level. Blindly throwing all stderr messages to /dev/null
should be a last resort, there may be something important there.I think that's a good idea - to use the same standard flags that GRASS
is also using (including the --overwrite which would be nice to have
in the writeRAST6 by the way).
I will keep that approach in mind for other commands interfacing to GRASS.
Yes in principle, but do we know whether users are still on 6.2, or have migrated to 6.3 and there is no further need to condition on feature creep? Remember that the R/GRASS interface isn't GRASS, it's an interface. I can look at reading the GRASS_VERBOSE shell variable and using it to set verbosity if present. The -q versus --q change killed the tests/examples when it happened, so I'd prefer conservatism (do nothing) to using GRASS facilities that vary between GRASS versions.
Roger
Rainer
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Roger Bivand
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@nhh.no
Roger Bivand wrote:
Yes in principle, but do we know whether users are still on 6.2, or have
migrated to 6.3 and there is no further need to condition on feature
creep? Remember that the R/GRASS interface isn't GRASS, it's an interface.
I can look at reading the GRASS_VERBOSE shell variable and using it to set
verbosity if present. The -q versus --q change killed the tests/examples
when it happened, so I'd prefer conservatism (do nothing) to using GRASS
facilities that vary between GRASS versions.
FWIW, --quiet and --verbose are silently ignored in GRASS 6.2.3 so
newer scripts could be shared. Prior to that it will throw an error
complaining about an unknown flag.
the GRASS_VERBOSE env var will safely be ignored if the version of GRASS
doesn't know to look for it. Probably what you should use, should you
choose to worry about verbosity levels.
-q vs --q? All -q flags in GRASS 6.x should be retained exactly for those
backwards compatibility reasons. If one has been removed then it's a bug.
Any command line script written for GRASS 6.0.0 should still work with
any GRASS 6.99.x. We've taken a lot of disciplined effort to ensure that.
One huge exception might be the change of r.out.gdal.sh to r.out.gdal (C
version), WRT observing overall map vs. current region bounds, but I am
not sure of that, probably you know better than me if that is actually
the case and causes pain.
Hamish
On Wed, Sep 24, 2008 at 11:32 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:
On Wed, 24 Sep 2008, Rainer M Krug wrote:
On Wed, Sep 24, 2008 at 4:45 AM, Hamish <hamish_b@yahoo.com> wrote:
Concerning trapping of the verbose messages, I think it would be a
good idea to do the following:1) add a parameter verbose=TRUE in readRAST6 and writeRAST6 to enable
or disable itRoger:
I'll try to do this using the existing ignore.stderr= in system(), but
it may not stop everything.When possible it should utilize the --quiet and --verbose flags which all
GRASS modules listen for, or set the GRASS_VERBOSE environment variable
to the required level. Blindly throwing all stderr messages to /dev/null
should be a last resort, there may be something important there.I think that's a good idea - to use the same standard flags that GRASS
is also using (including the --overwrite which would be nice to have
in the writeRAST6 by the way).
I will keep that approach in mind for other commands interfacing to GRASS.Yes in principle, but do we know whether users are still on 6.2, or have
migrated to 6.3 and there is no further need to condition on feature creep?
Remember that the R/GRASS interface isn't GRASS, it's an interface. I can
look at reading the GRASS_VERBOSE shell variable and using it to set
verbosity if present. The -q versus --q change killed the tests/examples
when it happened, so I'd prefer conservatism (do nothing) to using GRASS
facilities that vary between GRASS versions.
Agreed - that's a good point.
I don't think it is a good idea to use the GRASS_VERBOSE variable,
unless you provide a function to set (and unset) it from R - then it
could be used - but I would prefer an approach where the R function
has an argument specifying if it should be verbose or not, and quiet
or not. For a GRASS user it would be an advantage to have its named
after the GRASS flag, i.e verbose=TRUE would provide the output of the
GRASS module (with --verbose) to stderr. verbose=FALSE would not - but
you could still keep the --verbose flag and discard the output from
GRASS.
Rainer
Roger
Rainer
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev--
Roger Bivand
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@nhh.no
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation
Biology, UCT), Dipl. Phys. (Germany)
Centre of Excellence for Invasion Biology
Faculty of Science
Natural Sciences Building
Private Bag X1
University of Stellenbosch
Matieland 7602
South Africa