[GRASS-dev] Idea to remove subgroups [was: Re: [GRASS-SVN] r72650 - grass/trunk/scripts/i.spectral]

[Moritz Lennert]

Le Fri, 27 Apr 2018 10:31:23 +0300,
Maris Nartiss <maris.gis at gmail.com> a écrit :

> Hello Moritz,
> if subgroups are removed, it will be necessary to update all i.
> modules to follow some kind of new workflow. For the current state of
> GRASS, subgroups are crucial.
> I'm adding output of i.group on my system. As you can see, output of
> i.spectral on the output of i.maxlik is nonsense and thus should be
> avoided. Also I like to have one group for whole scene and switch
> between RGB (visible) and RGBI (VNIR) bands as needed.
> IMHO subgroups should be implemented in a way as in i.spectral – if no
> subgroup is provided, all maps from the group are used. Thus subgroup
> usage would be opt-in for those who understand how to use them.
> I somehow fail to see what kind of problem will be solved by removing
> subgroup functionality.

It is a question of simplification.

It is not easier to create subgroups than to create groups. So modules
could be rewritten to work simply with groups, not having to handle the
subgroups.

As I said, I'm trying to collect different examples of use cases, as in
the last developer meetings many didn't actually understand where the
whole notion and need for subgroups came from.

In my understanding, subgroups are mostly a remnant of a time where
most imagery data came non-georeferenced and so the typical workflow
would be 

- import into XY location and creation of a group with all bands
- georeference entire group into projected location
- run analysis on subgroups

There were thus operations that you would run on all bands (i.e. the
group) and others on a subset of the bands (i.e. the subgroup).
Nowadays, the need for the georeferencing step has diminished. And so
there is less of a distinction between operations run on groups and
others on subgroups. This lead to the idea of some to just get rid of
subgroups altogether for simplification.

Moritz