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

GDAL · October 9, 2008, 1:38am

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

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

GDAL · October 9, 2008, 7:23am

#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
--------------------------+-------------------------------------------------
Changes (by neteler):

* type: defect => enhancement

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

GDAL · October 9, 2008, 9:49am

#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 [ticket:324 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".

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

GDAL · October 10, 2008, 12:04am

#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>

GDAL · October 10, 2008, 5:20am

#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>

GDAL · October 12, 2008, 5:22pm

#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):

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

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

GDAL · October 13, 2008, 1:59am

#324: Ability to handle subgroups with general commands as all other datatypes
--------------------------+-------------------------------------------------
  Reporter: nikos | Owner: grass-dev@lists.osgeo.org
      Type: enhancement | Status: closed
  Priority: major | Milestone: 6.4.0
Component: default | Version: unspecified
Resolution: duplicate | Keywords: subgroup, general commands
  Platform: All | Cpu: Unspecified
--------------------------+-------------------------------------------------
Changes (by hamish):

* status: new => closed
* resolution: => duplicate

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