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?
On Sun, Oct 31, 2010 at 11:14 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
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?
+1 for option b) to avoid the ongoing increase of modules in
the core distribution.
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.
On Sun, Oct 31, 2010 at 5:33 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Martin Landa 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.
>> 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.
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.