[GRASS-dev] nc_spm_08_grass8?

Anna Petrášová kratochanna at gmail.com
Thu Sep 9 07:29:18 PDT 2021


Hi Vero, Maris,

thanks for responding! This is concerning, I personally don't work a lot
with remote sensing data and temporal stuff, but it seems to be delaying
GRASS 8 release.

On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss <maris.gis at gmail.com> wrote:

> 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.htmlmuch#/4/6
> <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.
>
>
So in that case it seems we need a new version, which would at least have
the
band references assigned. Since you only assign them from the actual mapset,
the current dataset is more difficult to use for any classification
examples.
E.g. this would be confusing in a workshop.
I think sample data should be ready to be used. It seems the assigned band
references are ignored in 7.8 and
everything works (is that right, Maris?), so we could just update the
current dataset as a quick fix.
Adding more data would be certainly valuable, but the whole dataset would
deserve update.
Then also the dataset has grass7 in the name...


> > 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


I cc'ed Markus.

>
>
> > Band references need some further discussion IMHO
>

+1

>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20210909/b4494d0a/attachment-0001.html>


More information about the grass-dev mailing list