[GRASS-dev] Submitting code / fixed broken r.spread module
Hi
How can I submit the revised code for the r.spread module of the
WIldfire simulation?
managed to get it working and it looks fine to me.
The original code in the file replaceHa.c read:
while ( (smaller_child <= *heap_len) &&
(new_min_cost > heap[smaller_child].min_cost)) {
heap[i].min_cost = heap[smaller_child].min_cost;
heap[i].angle = heap[smaller_child].angle;
heap[i].row = heap[smaller_child].row;
heap[i].col = heap[smaller_child].col;
and I changed it to:
while ( (smaller_child <= *heap_len) &&
(smaller_child > 0) &&
(new_min_cost > heap[smaller_child].min_cost)) {
.
.
.
Could please someone check if that is OK, and if yes submit to the
code repository?
Thanks
Rainer
--
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: Problem when loading GRASS 6 raster with large integer values into R via r.out.bin
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.00
south=6195000.00
east=270200.00
west=251000.00
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 <[EMAIL PROTECTED]> wrote:
> Roger Bivand nhh.no> writes:
>
>>
>> Markus Neteler osgeo.org> writes:
>>
>> >
>> > On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand
>> > nhh.no> wrote:
>> > > Markus Neteler 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
>> >
>>
>
>
>
>
> ___
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: Problem when loading GRASS 6 raster with large integer values into R via r.out.bin
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.00
south=6195000.00
east=270200.00
west=251000.00
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 <[EMAIL PROTECTED]> wrote:
Roger Bivand nhh.no> writes:
Markus Neteler osgeo.org> writes:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand
nhh.no> wrote:
Markus Neteler 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
___
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: [EMAIL PROTECTED]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: Problem when loading GRASS 6 raster with large integer values into R via r.out.bin
On Tue, Sep 23, 2008 at 1:11 PM, Roger Bivand <[EMAIL PROTECTED]> 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 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.00
max=36852.00
[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.00
>> south=6195000.00
>> east=270200.00
>> west=251000.00
>> 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 <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Roger Bivand nhh.no> writes:
>>>
Markus Neteler osgeo.org> writes:
>
> On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand
> nhh.no> wrote:
>>
>> Markus Neteler 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
>
>>>
>>>
>>>
>>>
>>> ___
>>> 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: [EMAIL PROTECTED]
>
>
--
Rainer M. Krug, PhD (Conservation E
[GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
Hi, the manual of 6.4 r.colors says: "The rules color table type will cause r.colors to read color table specifications from standard input (stdin) and will build the color table accordingly. " r.colors help | grep rules ... color Type of color table options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, differences,elevation,etopo2,evi,grey,grey1.0,grey255, gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, srtm,terrain,wave,random,grey.eq,grey.log,rules ... rules: create new color table based on user-specified rules ... rules Path to rules file but: r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col ERROR: "color", "rules", and "raster" options are mutually exclusive I know, I know.. but it is far from intuitive... any ideas to improve this behaviour/docs? This works of course...: r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col Color table for set to color_tab.col The first command version above doesn't look harmful to me, could we (re)enable it? thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: grass-dev Digest, Vol 29, Issue 62
On Sep 23, 2008, at 7:22 AM, <[EMAIL PROTECTED]> wrote: Date: Tue, 23 Sep 2008 16:22:24 +0200 From: "Markus Neteler" <[EMAIL PROTECTED]> Subject: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options To: "GRASS developers list" Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1 Hi, the manual of 6.4 r.colors says: "The rules color table type will cause r.colors to read color table specifications from standard input (stdin) and will build the color table accordingly. " r.colors help | grep rules ... color Type of color table options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, differences,elevation,etopo2,evi,grey,grey1.0,grey255, gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, srtm,terrain,wave,random,grey.eq,grey.log,rules ... rules: create new color table based on user-specified rules ... rules Path to rules file but: r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col ERROR: "color", "rules", and "raster" options are mutually exclusive This shouldn't cause this error. It seems to think that the raster option has been used (when it hasn't). A new bug recently introduced? Michael I know, I know.. but it is far from intuitive... any ideas to improve this behaviour/docs? This works of course...: r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col Color table for set to color_tab.col The first command version above doesn't look harmful to me, could we (re)enable it? thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
On Tue, Sep 23, 2008 at 7:22 AM, Markus Neteler <[EMAIL PROTECTED]> wrote: > Hi, > > the manual of 6.4 r.colors says: > "The rules color table type will cause r.colors to read color table > specifications from standard > input (stdin) and will build the color table accordingly. > " > > r.colors help | grep rules > ... > color Type of color table > options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, >differences,elevation,etopo2,evi,grey,grey1.0,grey255, >gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, >srtm,terrain,wave,random,grey.eq,grey.log,rules > ... >rules: create new color table based on user-specified rules > ... > rules Path to rules file > > but: > > r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col > ERROR: "color", "rules", and "raster" options are mutually exclusive > > I know, I know.. but it is far from intuitive... any ideas to improve this > behaviour/docs? > > This works of course...: > r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col > Color table for set to color_tab.col > > The first command version above doesn't look harmful to me, could we > (re)enable it? > > thanks > Markus > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-dev > This version seems most intuitive to me: r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col Cheers, Dylan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
On Tue, Sep 23, 2008 at 5:52 PM, Dylan Beaudette <[EMAIL PROTECTED]> wrote: > On Tue, Sep 23, 2008 at 7:22 AM, Markus Neteler <[EMAIL PROTECTED]> wrote: ... >> r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col >> ERROR: "color", "rules", and "raster" options are mutually exclusive >> ... > This version seems most intuitive to me: > r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col To me, too. What about silently dropping color=rules instead of issuing the ERROR? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Rotation of vector map
Hi, I need to rotate vector map at display time. I don't want to create a new vector map ratated (like v.trasform) but I need a new option on d.vect command like zrot in v.trasform. This functionality is already developed or I must devolop it myself? someone can suggest me the right mode to do that (I think to "copy" part of v.trasform in d.vect)? Thanks at all Massimo Costantini ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
On Tuesday 23 September 2008, Markus Neteler wrote: > On Tue, Sep 23, 2008 at 5:52 PM, Dylan Beaudette > > <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 23, 2008 at 7:22 AM, Markus Neteler <[EMAIL PROTECTED]> > > wrote: > > ... > > >> r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col > >> ERROR: "color", "rules", and "raster" options are mutually exclusive > > ... > > > This version seems most intuitive to me: > > r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col > > To me, too. > What about silently dropping color=rules instead of issuing the ERROR? > > Markus works for me. that shouldn't break too many scripts, and besides-- it makes more sense. Would this be back-ported to 6.4? Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: Problem when loading GRASS 6 raster with large integer values into R via r.out.bin
On Tue, 23 Sep 2008, Rainer M Krug wrote:
On Tue, Sep 23, 2008 at 1:11 PM, Roger Bivand <[EMAIL PROTECTED]> 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 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.00
max=36852.00
[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.00
south=6195000.00
east=270200.00
west=251000.00
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 <[EMAIL PROTECTED]>
wrote:
Roger Bivand nhh.no> writes:
Markus Neteler osgeo.org> writes:
On Wed, Sep 17, 2008 at 10:49 AM, Roger Bivand
nhh.no> wrote:
Markus Neteler 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
___
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
Eco
[GRASS-dev] Re: [GRASS-user] Attempt to export (r.out.gdal) produces sometimes an error and sometimes not
Nikos Alexandris wrote: > 1st attempt to export: > > r.out.gdal in=composite_b123 > out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif > Exporting to GDAL data type: UInt16 > Segmentation fault > Shouldn't the same error message (from the 1st attempt) remain? It appears that there is a memory corruption bug somewhere, either in r.out.gdal, the GRASS libraries, the GDAL library, or a library which it uses. The consequences of a memory corruption bug often depend upon the exact memory layout, or even the exact contents of uninitialised memory. Sometimes it will cause problems, sometimes it won't. It doesn't help that such bugs often fail to manifest if the program is run under a debugger (colloquially referred to as a "Heisenbug", in reference to the quantum mechanics principle that simply observing a system can change its behaviour). -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: grass-dev Digest, Vol 29, Issue 62
Michael Barton wrote: > > the manual of 6.4 r.colors says: > > "The rules color table type will cause r.colors to read color table > > specifications from standard > > input (stdin) and will build the color table accordingly. > > " > > > > r.colors help | grep rules > > ... > > color Type of color table > > options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, > > > > differences,elevation,etopo2,evi,grey,grey1.0,grey255, > > > > gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, > >srtm,terrain,wave,random,grey.eq,grey.log,rules > > ... > >rules: create new color table based on user-specified rules > > ... > > rules Path to rules file > > > > but: > > > > r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col > > ERROR: "color", "rules", and "raster" options are mutually exclusive > > This shouldn't cause this error. It seems to think that the raster > option has been used (when it hasn't). A new bug recently introduced? It certainly should cause this error. color=rules means to read rules from stdin, while rules= means to read rules from a named file. If you specify both, where is it supposed to read the rules from? Arguably, the description for color=rules should have "from stdin" appended to it, as that's how it behaves. Note that removing the mutual exclusivity check will simply cause the rules= option to be ignored, as color= is checked first. The rules option is only used if color= isn't given; specifically, the logic is: if <-i> read rules from stdin else if handle the various color= choices else if read rules from the specified file else copy colours from another map (raster=) FWIW, 7.0, doesn't accept color=rules; you need to use rules=- to read rules from stdin (this makes it easier for the GUI, where reading from stdin won't work.) -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
r.colors - was Re: [GRASS-dev] Re: grass-dev Digest, Vol 29, Issue 62
On Tue, Sep 23, 2008 at 9:28 PM, Glynn Clements <[EMAIL PROTECTED]> wrote: > > Michael Barton wrote: > >> > the manual of 6.4 r.colors says: >> > "The rules color table type will cause r.colors to read color table >> > specifications from standard >> > input (stdin) and will build the color table accordingly. >> > " >> > >> > r.colors help | grep rules >> > ... >> > color Type of color table >> > options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, >> > >> > differences,elevation,etopo2,evi,grey,grey1.0,grey255, >> > >> > gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, >> >srtm,terrain,wave,random,grey.eq,grey.log,rules >> > ... >> >rules: create new color table based on user-specified rules >> > ... >> > rules Path to rules file >> > >> > but: >> > >> > r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col >> > ERROR: "color", "rules", and "raster" options are mutually exclusive >> >> This shouldn't cause this error. It seems to think that the raster >> option has been used (when it hasn't). A new bug recently introduced? > > It certainly should cause this error. color=rules means to read rules > from stdin, while rules= means to read rules from a named > file. If you specify both, where is it supposed to read the rules > from? > > Arguably, the description for color=rules should have "from stdin" > appended to it, as that's how it behaves. OK, I have submitted this patch: ~/grass64/lib/gis > svn diff colors.desc Index: colors.desc === --- colors.desc (revision 33506) +++ colors.desc (working copy) @@ -21,7 +21,7 @@ rainbow: rainbow color table ramp: color ramp random: random color table -rules: create new color table based on user-specified rules +rules: create new color table based on user-specified rules read from stdin ryb: red through yellow to blue ryg: red through yellow to green sepia: yellowish-brown through to white > > Note that removing the mutual exclusivity check will simply cause the > rules= option to be ignored, as color= is checked first. The rules > option is only used if color= isn't given; specifically, the logic is: > >if <-i> read rules from stdin >else if handle the various color= choices >else if read rules from the specified file >else copy colours from another map (raster=) > > FWIW, 7.0, doesn't accept color=rules; you need to use rules=- to read > rules from stdin (this makes it easier for the GUI, where reading from > stdin won't work.) I have updated the docs of r.colors in both 6.4. and 7.trunk to reflect their behaviours. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Rotation of vector map
massimo costantini wrote: > I need to rotate vector map at display time. I don't want to create a > new vector map ratated (like v.trasform) but I need a new option on > d.vect command like zrot in v.trasform. > > This functionality is already developed or I must devolop it myself? The latter. > someone can suggest me the right mode to do that (I think to "copy" > part of v.trasform in d.vect)? Well, the easiest solution is a script which calls v.transform and d.vect. -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
Markus Neteler wrote: > the manual of 6.4 r.colors says: > "The rules color table type will cause r.colors to read color table > specifications from standard > input (stdin) and will build the color table accordingly. > " > > r.colors help | grep rules > ... >color Type of color table >options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, > differences,elevation,etopo2,evi,grey,grey1.0,grey255, > gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, > srtm,terrain,wave,random,grey.eq,grey.log,rules > ... > rules: create new color table based on user-specified rules > ... >rules Path to rules file > > but: > > r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col > ERROR: "color", "rules", and "raster" options are mutually exclusive > > I know, I know.. but it is far from intuitive... any ideas to improve this > behaviour/docs? -rules: create new color table based on user-specified rules +rules: create new color table based on user-specified rules read from stdin > This works of course...: > r.colors map=gpcp_1dd_p1d.2002_sum rules=color_tab.col > Color table for set to color_tab.col > > The first command version above doesn't look harmful to me, could we > (re)enable it? Why? If you don't want to read rules from stdin, don't use color=rules. If you don't want error messages, don't provide erroneous input. What's so special about this particular error that it should be silently ignored? -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
On Tue, Sep 23, 2008 at 9:54 PM, Glynn Clements <[EMAIL PROTECTED]> wrote: ... > What's so special about this particular error that it should be > silently ignored? all fine, it was answered in the forked thread. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: grass-dev Digest, Vol 29, Issue 62
On Sep 23, 2008, at 12:28 PM, Glynn Clements wrote: Michael Barton wrote: the manual of 6.4 r.colors says: "The rules color table type will cause r.colors to read color table specifications from standard input (stdin) and will build the color table accordingly. " r.colors help | grep rules ... color Type of color table options: aspect,aspectcolr,bcyr,bgyr,byg,byr,curvature, differences,elevation,etopo2,evi,grey,grey1.0,grey255, gyr,ndvi,population,rainbow,ramp,ryb,ryg,sepia,slope, srtm,terrain,wave,random,grey.eq,grey.log,rules ... rules: create new color table based on user-specified rules ... rules Path to rules file but: r.colors map=gpcp_1dd_p1d.2002_sum color=rules rules=color_tab.col ERROR: "color", "rules", and "raster" options are mutually exclusive This shouldn't cause this error. It seems to think that the raster option has been used (when it hasn't). A new bug recently introduced? It certainly should cause this error. color=rules means to read rules from stdin, while rules= means to read rules from a named file. If you specify both, where is it supposed to read the rules from? This makes sense, but is not clear in the documentation Arguably, the description for color=rules should have "from stdin" appended to it, as that's how it behaves. This would clear things up a lot. Michael Note that removing the mutual exclusivity check will simply cause the rules= option to be ignored, as color= is checked first. The rules option is only used if color= isn't given; specifically, the logic is: if <-i> read rules from stdin else if handle the various color= choices else if read rules from the specified file else copy colours from another map (raster=) FWIW, 7.0, doesn't accept color=rules; you need to use rules=- to read rules from stdin (this makes it easier for the GUI, where reading from stdin won't work.) -- Glynn Clements <[EMAIL PROTECTED]> ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Submitting code / fixed broken r.spread module
On Tue, Sep 23, 2008 at 10:08 AM, Rainer M Krug <[EMAIL PROTECTED]> wrote:
> Hi
>
> How can I submit the revised code for the r.spread module of the
> WIldfire simulation?
> managed to get it working and it looks fine to me.
>
> The original code in the file replaceHa.c read:
>
> while ( (smaller_child <= *heap_len) &&
> (new_min_cost > heap[smaller_child].min_cost)) {
>
> heap[i].min_cost = heap[smaller_child].min_cost;
> heap[i].angle = heap[smaller_child].angle;
> heap[i].row = heap[smaller_child].row;
> heap[i].col = heap[smaller_child].col;
>
> and I changed it to:
>
> while ( (smaller_child <= *heap_len) &&
> (smaller_child > 0) &&
> (new_min_cost > heap[smaller_child].min_cost)) {
> .
> Could please someone check if that is OK,
... not done...
> and if yes submit to the code repository?
Submitted (from offlist diff) to 6.3.svn (requested by Rainer),
6.4.svn and trunk.
cheers,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #96: v.surf.bspline broken
#96: v.surf.bspline broken
---+
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone: 6.4.0
Component: Raster| Version: unspecified
Resolution:|Keywords:
Platform: All | Cpu: All
---+
Changes (by neteler):
* cc: rantolin (added)
Comment:
I got a bugfix from Roberto which needs to be tested (patch attached).
It includes G_percent() output and two message cosmetics from me.
Test case for North Carolina data set:
{{{
g.region res=500 vect=precip_30ynormals -ap
v.surf.bspline precip_30ynormals colum=annual rast=precip_30ynormals_surf
layer=1 sin=1000 sie=1000
}}}
Markus
--
Ticket URL:
GRASS GIS
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: Problem when loading GRASS 6 raster with large integer values into R via r.out.bin
> > 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.colors confusion with "color", "rules", and "raster" options
> > I know, I know.. but it is far from intuitive... any > > ideas to improve this behaviour/docs? I've just added some logic in 6.x SVN to more nicely handle different user interpretations of the commands. "accept sloppy input, create tight output" and all that. Sure 'color=rules rules=filename' is redundant, but the intention is obvious. some people (especially those unfamiliar) like to tick every box. if it doesn't hurt anything, let 'em. I also backported the effect of rules=- meaning read from stdin. > -rules: create new color table based on user-specified rules > +rules: create new color table based on user-specified rules read from stdin I reverted that as it is somewhat misleading. It can mean either read directly from stdin or if no stream is waiting then to enter into the interactive environment. traditionally (not to mention currently) color=rules in grass 5/6 triggered the interactive environment prompt and help menu. I see no reason to strongly push users to use the -i flag instead of color=rules when both are removed in GRASS 7. Just let the old way fade away gracefully in its own time without disrupting users. Where's the gain in intentionally scuttling it early? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
