Could you explain your motivation behind this commit ? There have been discussions on and off (latest at the code sprint in Bonn) about the possibility to actually get rid of the notion of subgroups altogether. For that discussion, it would be interesting to know the actual patterns of use of subgroups.
--- grass/trunk/scripts/i.spectral/i.spectral.py 2018-04-26 10:20:18 UTC (rev 72649)
+++ grass/trunk/scripts/i.spectral/i.spectral.py 2018-04-26 11:19:33 UTC (rev 72650)
@@ -36,6 +36,10 @@
#% required : no
#% guisection: Input
#%end
+#%option G_OPT_I_SUBGROUP
+#% required : no
+#% guisection: Input
+#%end
#%option G_OPT_R_INPUTS
#% key: raster
#% required : no
@@ -198,6 +202,7 @@
def main():
group = options['group']
+ subgroup = options['subgroup']
raster = options['raster']
output = options['output']
coords = options['coordinates']
@@ -226,7 +231,10 @@
# get data from group listing and set the x-axis labels
if group:
# Parse the group list output
- s = gcore.read_command('i.group', flags='g', group=group, quiet=True)
+ if subgroup:
+ s = gcore.read_command('i.group', flags='g', group=group, subgroup=subgroup, quiet=True)
+ else:
+ s = gcore.read_command('i.group', flags='g', group=group, quiet=True)
rastermaps = s.splitlines()
else:
# get data from list of files and set the x-axis labels
Hello Moritz,
if subgroups are removed, it will be necessary to update all i.
modules to follow some kind of new workflow. For the current state of
GRASS, subgroups are crucial.
I'm adding output of i.group on my system. As you can see, output of
i.spectral on the output of i.maxlik is nonsense and thus should be
avoided. Also I like to have one group for whole scene and switch
between RGB (visible) and RGBI (VNIR) bands as needed.
IMHO subgroups should be implemented in a way as in i.spectral – if no
subgroup is provided, all maps from the group are used. Thus subgroup
usage would be opt-in for those who understand how to use them.
I somehow fail to see what kind of problem will be solved by removing
subgroup functionality.
Māris.
i.group -l Mai05
group <Mai05> references the following raster maps
-------------
<B02COR_20170505T094031@piemers> <B03COR_20170505T094031@piemers>
<B04COR_20170505T094031@piemers> <B08COR_20170505T094031@piemers>
<Mai05_clusters@piemers> <Mai05_5clusters@piemers>
<Mai05_clusters3@piemers> <Mai05_clusters5@piemers>
<Mai05_clusters6@piemers> <Mai05_allsigs_MLC@piemers>
-------------
i.group -ls Mai05
group <Mai05> references the following subgroups
-------------
all rgb
-------------
i.group -ls Mai05 subgroup=all
subgroup <all> of group <Mai05> references the following raster maps
-------------
<B02COR_20170505T094031@piemers> <B04COR_20170505T094031@piemers>
<B03COR_20170505T094031@piemers> <B08COR_20170505T094031@piemers>
-------------
i.group -ls Mai05 subgroup=rgb
subgroup <rgb> of group <Mai05> references the following raster maps
-------------
<B02COR_20170505T094031@piemers> <B04COR_20170505T094031@piemers>
<B03COR_20170505T094031@piemers>
-------------
2018-04-26 15:46 GMT+03:00 Moritz Lennert <mlennert@club.worldonline.be>:
Hi Maris,
Could you explain your motivation behind this commit ? There have been
discussions on and off (latest at the code sprint in Bonn) about the
possibility to actually get rid of the notion of subgroups altogether. For
that discussion, it would be interesting to know the actual patterns of use
of subgroups.
--- grass/trunk/scripts/i.spectral/i.spectral.py 2018-04-26
10:20:18 UTC (rev 72649)
+++ grass/trunk/scripts/i.spectral/i.spectral.py 2018-04-26
11:19:33 UTC (rev 72650)
@@ -36,6 +36,10 @@
#% required : no
#% guisection: Input
#%end
+#%option G_OPT_I_SUBGROUP
+#% required : no
+#% guisection: Input
+#%end
#%option G_OPT_R_INPUTS
#% key: raster
#% required : no
@@ -198,6 +202,7 @@
def main():
group = options['group']
+ subgroup = options['subgroup']
raster = options['raster']
output = options['output']
coords = options['coordinates']
@@ -226,7 +231,10 @@
# get data from group listing and set the x-axis labels
if group:
# Parse the group list output
- s = gcore.read_command('i.group', flags='g', group=group,
quiet=True)
+ if subgroup:
+ s = gcore.read_command('i.group', flags='g', group=group,
subgroup=subgroup, quiet=True)
+ else:
+ s = gcore.read_command('i.group', flags='g', group=group,
quiet=True)
rastermaps = s.splitlines()
else:
# get data from list of files and set the x-axis labels
Le Fri, 27 Apr 2018 10:31:23 +0300,
Maris Nartiss <maris.gis@gmail.com> a écrit :
Hello Moritz,
if subgroups are removed, it will be necessary to update all i.
modules to follow some kind of new workflow. For the current state of
GRASS, subgroups are crucial.
I'm adding output of i.group on my system. As you can see, output of
i.spectral on the output of i.maxlik is nonsense and thus should be
avoided. Also I like to have one group for whole scene and switch
between RGB (visible) and RGBI (VNIR) bands as needed.
IMHO subgroups should be implemented in a way as in i.spectral – if no
subgroup is provided, all maps from the group are used. Thus subgroup
usage would be opt-in for those who understand how to use them.
I somehow fail to see what kind of problem will be solved by removing
subgroup functionality.
It is a question of simplification.
It is not easier to create subgroups than to create groups. So modules
could be rewritten to work simply with groups, not having to handle the
subgroups.
As I said, I'm trying to collect different examples of use cases, as in
the last developer meetings many didn't actually understand where the
whole notion and need for subgroups came from.
In my understanding, subgroups are mostly a remnant of a time where
most imagery data came non-georeferenced and so the typical workflow
would be
- import into XY location and creation of a group with all bands
- georeference entire group into projected location
- run analysis on subgroups
There were thus operations that you would run on all bands (i.e. the
group) and others on a subset of the bands (i.e. the subgroup).
Nowadays, the need for the georeferencing step has diminished. And so
there is less of a distinction between operations run on groups and
others on subgroups. This lead to the idea of some to just get rid of
subgroups altogether for simplification.