#134: Add a flag for subgroup listing in i.group
--------------------------+-------------------------------------------------
Reporter: nikos | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: unspecified
Resolution: | Keywords:
--------------------------+-------------------------------------------------
Comment (by glynn):
Replying to [comment:3 neteler]:
> With fixed i.group, it is possible but too complicated to list
subgroups:
Let me clarify. You can list the files which make up a subgroup, but you
cannot list the subgroups of a group.
> -> subgroups missing, not even indicated that they are present in that
group.
The -l switch just dumps the REF file for a group or subgroup.
> "g.list subgroup" does not exist.
Well, each group has its own list of subgroups. g.list only lists "top-
level" entities (rasters, vectors, groups, etc).
> Now '''only''' the subgroups are listed.
Only the contents of a specific subgroup are listed. Adding subgroup=
causes -l to
dump that subgroup's REF file rather than the group's REF file.
> But how to know its name to issue this command?
Exactly.
> I see some conceptual problems here. Proposal
>
> - either list automatically also the subgroup(s) when only indicating
group=
That could be confusing, particularly if you have scripts parsing the
output of "i.group -l".
> - or add a new flag for subgroup(s) listing
That seems like the most viable solution. And there is actually a function
to do this, named I_list_subgroups(), although nothing uses it at present.
FWIW, there is also I_list_groups(), but the only thing which uses it is
I_ask_group_old() (if you type "list"), which in turn is only used by the
i.ortho.photo front-end.
Both of those functions are abominations which uses popen("ls ...") to
enumerate the directory. They also do all of the formatting, and send the
results to the pager. There isn't anything like I_get_[sub]group_ref()
which just returns the information to the caller in a usable form.
> - or enhance g.list to ist subgroup names (but looks moreover confusig
to me).
You would need to add a group= parameter to g.list, unless you want it to
enumerate all subgroups of all groups. But that's arguably outside of the
scope of g.list, which isn't supposed to know the details of the various
entity types (it violates that principle for vectors, although I'm not
sure if that's really necessary).
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/134#comment:4>
GRASS GIS <http://grass.osgeo.org>