#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 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>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
