[GRASS-dev] Re: [GRASS GIS] #324: Ability to handle subgroups with general commands as all other datatypes

[GRASS GIS]

#324: Ability to handle subgroups with general commands as all other datatypes
--------------------------+-------------------------------------------------
  Reporter:  nikos        |       Owner:  grass-dev at lists.osgeo.org 
      Type:  enhancement  |      Status:  new                       
  Priority:  major        |   Milestone:  6.4.0                     
 Component:  default      |     Version:  unspecified               
Resolution:               |    Keywords:  subgroup, general commands
  Platform:  All          |         Cpu:  Unspecified               
--------------------------+-------------------------------------------------
Comment (by 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?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/324#comment:3>
GRASS GIS <http://grass.osgeo.org>