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