R: Re: [GRASS-dev] g_parser() ERROR

I wonder if those standard schemes should be hardcoded in a *.h file, with an option to chose one of them by name or custom with an optional and add/rename a new option called rules= to load the custom file? then less work to specify path to the *.dat file... Yes Hamish, I'm agree! but (as

R: Re: [GRASS-dev] g_parser() ERROR

I mean sand and class has to be in 0-100 range. I will indicate in option module Thanks Hamish, sincerely! gianluca ___ grass-dev mailing list grass- d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] g_parser() ERROR

Hy list, I've a problem with r.soils.texture (http://trac.osgeo. org/grass/browser/grass-addons/raster/r.soils.texture) . In past and in previous test It worked properly but now I've this message: ERROR: Required parameter CLAY not set: Actually all input module are null (tested with

[GRASS-dev] Re: [GRASS-user] Compiling addons from svn repository

Mortiz, thank you for interesting about mcda. I need help and suggest for better coding! - Yes, r.mcda.electre, r.mcda.regime use G_alloc_matrix((nrows*ncols),(nrows*ncols)) with related memory problem. I'm looking for a better algorithm, especially for pairwise comparison that need large