[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 glynn):

 Replying to [comment:3 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).

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