Ability to handle subgroups with general commands as all other datatypes

[nikos]

I think it would be useful to extent all general commands so they handle subgroups as all other datatypes.

Examples: (a) g.list type=subgroup group=SomeGroup? # to list the subgroups contained in SomeGroup? (b) g.remove group=SomeGroup? subgroup=SomeSubGroup? # perhaps with a switch to ensure only subgroup removal and avoid loosing the group (c) g.rename group=SomeGroup? subgroup=SomeSubGroup?_new,SomeSubGroup?_tested

[glynn]

Replying to nikos:

I think it would be useful to extent all general commands so they handle subgroups as all other datatypes.

This request suggests a misunderstanding about subgroups. They aren't self-contained entities like groups or rasters or vectors; they're properties of a group.

Using g.rename to modify a subgroup would be like using g.rename to change a map's title. Using g.remove to remove a subgroup would be like using g.remove to remove features from a vector map.

I suggest that this is resolved as "invalid".

[nikos]

Glynn, thank you for the explanation. Perhaps adding such functions in i.group would make sense (?)

example: i.group group=pca -s # -s: list subgroups and not individual maps added in the group

I'll try to make my point: I have lots of principal components that came from different band combinations, why should I need to create as much groups as the combinations from which they came from (in order to have an easy overview for later classification tasks for example).

I only have one group called pca and in it lots of subgroups depending on the initial band combination used to produce these components. Then I can apply a classification using the same training set upon the different subgroups. It takes less effort to "invent" names for groups/subgroups and gives me the feel that its easier to review/check the data (=groups/subgroups).

This is how I thought/think that subgroups are meaningful. Would you recomment another "best practice" of GRASS groups/subgroups handling?

[glynn]

Replying to nikos:

Glynn, thank you for the explanation. Perhaps adding such functions in i.group would make sense (?)

i.group (or another i.* module) would be the right place for anything related to groups.

example: i.group group=pca -s # -s: list subgroups and not individual maps added in the group

That would probably be useful.

I'll try to make my point:

[snip]

This is how I thought/think that subgroups are meaningful. Would you recomment another "best practice" of GRASS groups/subgroups handling?

The issue isn't about how to use groups/subgroups, but about where the code required to do so belongs.

g.{list,copy,rename,remove} don't contain any knowledge about the various entity types beyond what is contained in etc/element_list (other than a special case for vectors, and one for the colr2 directory for rasters). They just read the etc/element_list file to discover which files make up the element, then list, copy, rename or remove the corresponding files. Even the set of command-line options is built from the contents of the element_list file.

If you want similar features for imagery subgroups, it would be better to have something like:

i.subgroup [-l] group=... [remove=...] [copy=...] [rename=...]

The amount of code involved would be less (maybe significantly less) than if the same features were added to the g.* commands, as you wouldn't need code to override the "generic" behaviour of the g.* commands (e.g. when g.remove sees "group=...", it will delete those groups, so you would have to explicitly prevent that).

[nikos]

I did not remember that I posted this one already (ticket #134). May I mark the current one as a duplicate?