[GRASS-dev] nc_spm_08_grass8?

[Vaclav Petras]

On Thu, Sep 9, 2021 at 3:23 PM Maris Nartiss <maris.gis at gmail.com> wrote:

> 2021-09-09 19:19 GMT+03:00, Vaclav Petras <wenzeslaus at gmail.com>:
> >
> > In the documentation, we moved from (5 calls):
> >
> > ```
> > g.region raster=lsat7_2002_10
> > i.group group=lsat7_2002 subgroup=res_30m input=...
> > v.to.rast input=training output=training use=cat label_column=label
> > i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> > i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> > ```
> >
> > to (16 calls):
> >
> > ```
> > g.mapset mapset=PERMANENT
> > r.support map=lsat7_2002_10 bandref=TM7_1
> > r.support map=lsat7_2002_20 bandref=TM7_2
> > r.support map=lsat7_2002_30 bandref=TM7_3
> > r.support map=lsat7_2002_40 bandref=TM7_4
> > r.support map=lsat7_2002_50 bandref=TM7_5
> > r.support map=lsat7_2002_61 bandref=TM7_61
> > r.support map=lsat7_2002_62 bandref=TM7_62
> > r.support map=lsat7_2002_70 bandref=TM7_7
> > r.support map=lsat7_2002_80 bandref=TM7_8
> > g.mapset mapset=user1
> > g.region raster=lsat7_2002_10
> > i.group group=lsat7_2002 subgroup=res_30m input=...
> > v.to.rast input=training output=training use=cat label_column=label
> > i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> > i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> > ```
> >
> > This seems to be making GRASS more difficult to use instead of making it
> > easier to use or at least keeping the status quo.
>
> And we gained ability to use signatures from one scene to classify
> different scenes.
>

Why not to have both? Classify thousands of scenes while providing a simple
way of doing things?

If all import tools assigned band references, having them ready in the
dataset for landsat could be perhaps justified. That's the answer I was
hoping for, but that's not the case. Still, the question would be what if
you can't use such a tool.

As for getting closer to the original behavior where 5 commands were enough
to classify, i.group could add the band references since one needs to deal
with both groups and bands anyway or the signature handling could assign
them on the fly. I'm probably missing some important details you know
about, but here are some options I can think of:

Option 1) i.group has a new option bandref. It assigns band references to
the rasters. User needs to provide as many band references as inputs. Still
quite long, but i.group call is long already and it is at least technically
one step.

Option 2) i.group has a new flag to auto-assign band references 1,2,3,...
(2a). Or perhaps an option taking a prefix/basename (2b). Simple to set.
Minimal change from the current workflows. Almost feels like band
references are optional.

Option 3) i.group auto-assigns automatically when band references are not
present. No dealing with band references unless one needs to.

Option 4) i.gensigset et al. labels the bands 1,2,3,... on the fly only in
the signature file and i.smap et al. uses the same numbering scheme when
the rasters don't have band references. Band references are handled only
when needed even on the module level in addition to the user level.

With all options users still may take advantage of the flexible signature
file system if being careful about order. (Keeping the order right is
likely not an issue while scripting, so having a list of auto-assigned
numbers is just fine.) All options hide details of the actual reference
handling at least a little bit providing more space for changes later on.
The options 3 and 4 make dealing with band references completely optional.
Option 4 avoids mixing groups and band references and while option 3 hides
that part.

Other options would be modules such as r.number.bands/i.auto.bands (kind of
like options 2 and 3 but standalone) and i.band.identify (some heuristic to
determine band names from raster names perhaps taking an example or a
sensor).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210909/c3b7d7ff/attachment.html>