[GRASS-dev] Calling all imagery (especially i.maxlik and i.smap) users

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).

#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

Thank you in advance for your feedback,
Māris.

1. https://trac.osgeo.org/grass/ticket/3440
2. https://trac.osgeo.org/grass/ticket/3525

Hi Māris,

Yes, with GRASS 8 in the horizon, this is the right time to change some things.

[…]

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).

I do not use subgroups at all, indeed I’m mostly annoyed by modules asking for subgroups, too. Moreover, in the hypothetical case of using subgroups to store for example only bands, indices, textures, etc., some very useful addons like r.learn.ml do not consider subgroups, hence I’d still need to create different groups anyway.

I’m totally in favour of removing subgroups.

#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

+1 for removal of this behaviour too

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

Fully agree with Sajid here

Cheers,
Vero

Hello Brad.
piektd., 2020. g. 8. maijs, plkst. 05:36 — lietotājs Brad ReDacted
(<brad.redacted@protonmail.com>) rakstīja:

Hello,

IIRC, signatures cannot be handled as colors without significant modification to api.

Is there a particular reason for not improving the API to be map portable and remove subgroups from modules that do not explicitly require it?

Thanks also to Veronica and Sajid for feedback :slight_smile:
Yes, that's the whole point of this thread — to find out more how
people use GRASS image groups so they can be changed (requiring
breaking API, GRASS database structure).

Last night I couldn't sleep and came up with a sound idea of replacing
subgroups with semantically sounder alternative that would allow to
make group independent signature files. Concept still needs some
thinking over and writing/drawing. If anyone is willing to help in
changing imagery support for GRASS 8, let me know.

Māris.

PS. More user stories are still welcome :slight_smile:

On 6/05/20 08:33, Maris Nartiss wrote:

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).

Subgroups used to be very useful when imagery came without georeferencing. One would import the data into XY, and georeference all bands contained in one group. In the projected location one could then define subgroups to do the actual work on them.

In other word, they were (are?) useful when you have different parts of your workflow where one part concerns all bands while other parts only a subset of these bands.

As most imagery comes georeferenced nowadays, this workflow is much less frequent nowadays and for most of my usage of subgroups today, it could be replaced without any problem by the use of groups.

#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

+1 to remove this functionality.

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

I do think that mapset-specific groups make sense and that for me personally I see a lot of potential for chaos if I could have signature files in a mapset that pertain to groups in other mapsets. It is so easy to create a group that I'm not sure what the significant added value would be.

So, I'm more skeptical about this one, without having a clear-cut opinion.

Moritz

Hi Maris

Thank you for bringing this topic.

#2 Should i.maxlik add its output to the group?

Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

In my experience, having the outputs stored in the group/subgroup is not useful and we should remove this behavior. Don’t see any particular advantage of this.

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

IMHO we should be able to list the signatures and should also be able to use outside the group. There are cases where we want to use the same signature with a different imagery group same spectral combination but from a different date for example.
In this context want to point out these addons by Luca Delucchi, to move, list the signatures.
i.signature.copy: Copies signature file from a group/subgroup to another group/subgroup.
i.signature.list: Lists signature file of a group/subgroup.
i.signature.remove: Removes signature file in a group/subgroup.

It would be nice if we can export/save (resue) the signature (for example .sig file) outside grass mapset like the color files.

best
Sajid