Markus Neteler wrote: > >> currently r.colors has a new flag (-p) to print color table assigned > >> to the raster map. I have implemented this functionality because I > >> simply overlook r.colors.out in GRASS 7. We can > >> > >> a) remove -p flag from r.colors and continue with r.colors.out (and > >> backport it to GRASS 6) > >> > >> or > >> > >> b) improve -p flag in r.colors and drop r.colors.out. > >> > >> I would vote for option b), we have quite a lot modules in core > >> distribution in GRASS7. What do you think? > > > > I'd choose a). The two operations have almost nothing in common, so > > there's no reason for them to be in the same module. > > Frmo a user's perspective, a situation like > > r.statistics/ r.statistics2/ r.statistics3/ r.stats/ > > is just confusing...
Mostly because a number of substantially different modules have all been lumped under "statistics". But given that "statistics" is such a broad concept, it's actually rather illogical to expect every "statistics" operation to be bundled into a single module. The naming could probably be improved. Also, there's no reason for r.statistics to exist if r.statistics[23] have been tested and found satisfactory. If anything, r.statistics3 should probably be merged into r.quantile (it's just a extension of r.quantile to support a base map). The default should be for distinct operations to have distinct modules. The main reason for having multiple operations in a single module is if they share code and/or parameters. This eliminates code duplication and improves consistency. E.g. calculation of most accumulator-based aggregates (sum, mean, variance, etc) is structurally similar, so it makes sense for them to share a common module. OTOH, calculation of quantiles has almost nothing in common with accumulator-based aggregates. Likewise, merging the functionality of r.colors.out into r.colors makes no more sense than merging the various r.out.* modules with their r.in.* counterparts. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
