#324: Ability to handle subgroups with general commands as all other datatypes
--------------------------+-------------------------------------------------
Reporter: nikos | Owner: grass-dev@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>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
