[GRASS-dev] r.colors.out X r.colors -p

[Glynn Clements]

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 <glynn at gclements.plus.com>