[GRASS-dev] nc_spm_08_grass8?

Maris Nartiss maris.gis at gmail.com
Thu Sep 9 01:46:22 PDT 2021


Hello Anna, Veronica.

2021-09-08 23:09 GMT+03:00, Veronica Andreo <veroandreo at gmail.com>:
> Hi Anna, all
>
> Good point! Thanks for raising this!
>
> Seems we are all trying to better understand band references and how they
> integrate with existing functionality :)

Band reference usage in the context of classification of imagery is
explained in a scheme in the most recent GRASS 8 feature presentation:
https://veroandreo.github.io/grass-gis-talks/wageningen2021.html#/4/6

> In
> https://github.com/OSGeo/grass/pull/1844/ we discuss temporal framework and
> band references.

I can not comment on band references in t.* modules as I do not
understand their role there. Some changes might be needed there.

> Indeed, we have a problem if all examples using Landsat will stop working
> in grass 8, so if this is the case, then we might need a new version of the
> sample data which by the way might also include the MODIS LST mapset (~10
> Mb) to do some time series stuff.

A new version of sample dataset would be good. Still existing version
also works OK as long as you do an extra step of assigning band
references at the first time. You'll find usage examples in manual
pages of i.cluster with following in i.maxlik; and a full example in
i.smap.

https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265
https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html
https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144

> In my opinion, band reference should be something optional, no?

They are optional as long as you are not using i.maxlik or i.smap or
i.svm.predict (and respective signature generation modules for them).
Can't comment on t.* modules.

> On the
> other hand, I think I understood from Maris that with r.support we could
> add band references and that the restrictions were relaxed but these
> changes are not yet documented. There's this thread:
> https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html

Band reference rules are relaxed and now any word can be a band
reference as long as its length does not exceed GNAME_MAX and its
symbol set is limited to a-Z 0-9 and "-", "_".
https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149
Can not comment on t.* modules as they are bypassing C library and
doing some magick in Python instead of fully integrating with the rest
of GRASS.

It is pity that the PR relaxing band reference requirements got merged
although it didn't change the documentation to reflect changes in the
code. It is my fault as I wasn't fast enough to stop Markus Metz from
merging without required changes. I hope Markus M. will fix his
blunder and provide changes also to the documentation to reflect
changes in the code made by him.
https://github.com/OSGeo/grass/pull/1796

> Band references need some further discussion IMHO

Harmonization of t.* Python based band reference handling with C
library based one should be done by someone who completely understands
the Python part in t.* (as an idea and not only code). As
functionality is required in both C and Python code, C has precedence
over Python (functionality in C + wrapper functions for Python or just
plain ctypes as it is done in tests).

>From the i.* module point of view, modules g.bands and i.bands are not
required and are not used at all. Besides i.bands is a bad module name
as bands are assigned to rasters and not groups thus it should be
r.bands but the management functionality is already covered with
r.support leaving only printing for i.bands without an alternative. I
would drop i.bands completely unless it is completely reworked.
g.bands is a nice idea but, unless someone implements editing part, it
is of limited use.

> my 2 cents
> Vero

Māris.


More information about the grass-dev mailing list