[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@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: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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@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: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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@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: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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@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: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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@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: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[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@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: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev