Had to resent the mail due to size limitations. You can take a look at
the attachments here:
https://karlsons.gisnet.lv/~marisn/imagery_classification_G7.png
https://karlsons.gisnet.lv/~marisn/imagery_classification_G8.png
2021-09-10 5:56 GMT+03:00, Vaclav Petras <wenzeslaus@gmail.com>:
Why not to have both? Classify thousands of scenes while providing a simple
way of doing things?
Because GRASS metadata handling implementation is inferior. See
Sentinel SAFE usage in SNAP for a correct one (XML/Java discussion
aside).
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.
Depends on the format. If imported format has band references (e.g.
SAFE), they should be written in GRASS as band references too. Still
this is a TODO for another day.
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:
To better understand my answer, take a look at two attached graphs –
how imagery groups and signature files work in G7 and how they have
been changed for G8. In G7 imagery group is only consistent
internally. In G8 signature files from one group are consistent in any
group.
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.
+ One long call instead of multiple calls to r.support
- Raster band must be set for each group separately (think NDVI or
slope map in multiple groups)
- User must set the same labels in a correct order also for any other
group where signature file is used
= Not a big difference from existing implementation
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.
+ Works well if one classifies the same group only
- Signature file can not be used to classify any other group as there
is no guarantee of band order in groups
= This is a GRASS 7 approach with a hack of copying SIG file from one
group to other group
Option 3) i.group auto-assigns automatically when band references are not
present. No dealing with band references unless one needs to.
+ Works well if one classifies the same group only
- Signature files must be modified to contain group name
- User will be able to select a signature file for classification of a
different group but action will be refused if band references are
missing
= Confusing as one can not know in advance if signature file can or
can not be used to classify a group (should we call it a pythonic way
– try...except?)
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.
Didn't understood how this differs from option #2.
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.
There is no guarantee of order of bands in a REF file. If band order
stays the same, you are lucky, if it isn't, you just got an incorrect
result without a warning (a.k.a. flipping a coin to determine if
output is correct or total bollocks as band order was messed up).
Assigning band reference via scripting is not a problem if e.g. it is
present in the raster name.
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).
This is the correct way to go. I would say:
1) enhance import tools to generate band references (if possible). I
assume specialized Sentinel, Landsat, Modis etc. import modules could
be enhanced easily to do so.
2) provide an easy GUI tool to assign band references. Here bands from
g.bands would come handy. Probably i.bands could be repurposed to mass
assignment for rasters from a group.
3) provide a signature management tool (list, rename, delete, import,
export, print info, ..?; most of the library part is already done).
Unfortunately as I shelved for too long my work on i.svm to solve
signature file inefficiency of GRASS, I have no time to work on either
of solutions as I have deadlines to meet. GRASS 8.2 seems to be a
reasonable time frame for easing up band reference handling.
Of course, rolling back PRs #1501 and #1850 is also an option. Still,
then we'll be stuck with GRASS 3..7 approach till GRASS 9.0, as these
are serious changes to library and mapset structure thus 8.0 or 9.0.
Māris.
In