[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 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 ___ 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 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 ___ 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 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.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 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 ___ 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 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
[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 gpcp_1dd_p1d.2001_sum 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 grass-dev@lists.osgeo.org 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 gpcp_1dd_p1d.2001_sum 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 gpcp_1dd_p1d.2001_sum 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] 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 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.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 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev -- Roger Bivand Economic Geography Section, Department of
[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=filename 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 color=... handle the various color= choices else if rules=... 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=filename 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 color=... handle the various color= choices else if rules=... 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 gpcp_1dd_p1d.2001_sum 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=filename 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 color=... handle the various color= choices else if rules=... 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: http://trac.osgeo.org/grass/ticket/96#comment:3
GRASS GIS http://grass.osgeo.org
___
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
