[GRASS-dev] Management of signature files

[Maris Nartiss]

Hello list,
I have been working on moving automatic classification signature files
(ones used by i.maxlik and i.smap) out of imagery groups. Existing
approach was not flexible enough as there was no official way of how
to reuse signatures from one imagery group in another group (train on
one, classify many).
At the moment I have managed to implement all internal bits of fully
reusable signatures – at the time of creation, band references are
written to the signature file; before signature use, band references
are used to reorder signatures to match band order in the new group
(or bail out if bands do not match).
https://github.com/OSGeo/grass/pull/1501

There are only two bits left before this work is complete:
1) remove current special signature file handling in GUI;
2) signature management.

I would like to hear some feedback on how to proceed with signature
management. At the moment I have placed signature files into following
structure:
<GISDBASE>/<LOCATION>/<MAPSET>/signatures/<SIG_TYPE>/<signature file name>
As you can see, this structure differs from the canonical GRASS
approach of having single level to represent type (e.g. raster,
vector, ...) as there is a need to differentiate various signature
file types (at the moment there are two types – sig and sigset. I'll
finish work on a third (svm) after merging this PR).

Options for signature file managemet are:

#1 In GRASS 7 there are no options to manage signature files at all.
Once file is created, it can be only removed with OS file management
tools. g.list|copy|rename|remove have no idea of signature files. Pro:
easy to implement (=works already). Con: poking around mapset should
be done only by those who understand consequences.

#2 A variation of #1. Add a separate signature file management tool
(i.signatures?). We do have a precedent already – imagery groups are
managed by i.group module as g.* modules only see group but not
subgroups inside a group; time datasets. Pro: still easy to implement.
Con: needs special handling in GUI; one has to remember to use a
special module that differs from the rest (vect, raster, raster3d).

#3 Modify management library (g.* tools) to accept two level
specifiers e.g. "<SIG_TYPE>/<name>(@<MAPSET>)". Pro: one can use usual
g.* tools as with other data elements. Con: tricky to implement
without significant changes to lib/management; needs special handling
in GUI (show items matching SIG_TYPE); element syntax differs from
other data elements.

#4 A variation of #3. Change signature storage to
"<MAPSET>/signatures/<signature file name>.<SIG_TYPE>" Pro: easy to
add to g.* tools with element syntax "<name>.<SIG_TYPE>(@<MAPSET>)".
Con: needs special handling in GUI (show items matching SIG_TYPE);
element syntax differs from other data elements.

Let me know your preferred option or other ideas regarding signature
files. When I started to work on the issue, I was leaning towards #3
but now #4 seems to be even easier from implementation point of view,
although #2 is always an option.

After merging this PR, I have only r.in.pdal on my agenda and then
I'll remind everyone that GRASS 8.0 is long overdue ;-)
Māris.