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