<div dir="ltr"><div dir="ltr"><br></div>Hi Vero, Maris,<div><br></div><div>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.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss <<a href="mailto:maris.gis@gmail.com">maris.gis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Anna, Veronica.<br>
<br>
2021-09-08 23:09 GMT+03:00, Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank">veroandreo@gmail.com</a>>:<br>
> Hi Anna, all<br>
><br>
> Good point! Thanks for raising this!<br>
><br>
> Seems we are all trying to better understand band references and how they<br>
> integrate with existing functionality :)<br>
<br>
Band reference usage in the context of classification of imagery is<br>
explained in a scheme in the most recent GRASS 8 feature presentation:<br>
<a href="https://veroandreo.github.io/grass-gis-talks/wageningen2021.html#/4/6" rel="noreferrer" target="_blank">https://veroandreo.github.io/grass-gis-talks/wageningen2021.htmlmuch#/4/6</a><br>
<br>
> In<br>
> <a href="https://github.com/OSGeo/grass/pull/1844/" rel="noreferrer" target="_blank">https://github.com/OSGeo/grass/pull/1844/</a> we discuss temporal framework and<br>
> band references.<br>
<br>
I can not comment on band references in t.* modules as I do not<br>
understand their role there. Some changes might be needed there.<br>
<br>
> Indeed, we have a problem if all examples using Landsat will stop working<br>
> in grass 8, so if this is the case, then we might need a new version of the<br>
> sample data which by the way might also include the MODIS LST mapset (~10<br>
> Mb) to do some time series stuff.<br>
<br>
A new version of sample dataset would be good. Still existing version<br>
also works OK as long as you do an extra step of assigning band<br>
references at the first time. You'll find usage examples in manual<br>
pages of i.cluster with following in i.maxlik; and a full example in<br>
i.smap.<br>
<br>
<a href="https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265" rel="noreferrer" target="_blank">https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265</a><br>
<a href="https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html" rel="noreferrer" target="_blank">https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html</a><br>
<a href="https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144" rel="noreferrer" target="_blank">https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144</a><br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> In my opinion, band reference should be something optional, no?<br>
<br>
They are optional as long as you are not using i.maxlik or i.smap or<br>
i.svm.predict (and respective signature generation modules for them).<br>
Can't comment on t.* modules.<br>
<br></blockquote><div><br></div><div>So in that case it seems we need a new version, which would at least have the</div><div>band references assigned. Since you only assign them from the actual mapset,</div><div>the current dataset is more difficult to use for any classification examples.</div><div>E.g. this would be confusing in a workshop.</div><div>I think sample data should be ready to be used. It seems the assigned band references are ignored in 7.8 and</div><div>everything works (is that right, Maris?), so we could just update the current dataset as a quick fix.</div><div>Adding more data would be certainly valuable, but the whole dataset would deserve update.</div><div>Then also the dataset has grass7 in the name...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> On the<br>
> other hand, I think I understood from Maris that with r.support we could<br>
> add band references and that the restrictions were relaxed but these<br>
> changes are not yet documented. There's this thread:<br>
> <a href="https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html</a><br>
<br>
Band reference rules are relaxed and now any word can be a band<br>
reference as long as its length does not exceed GNAME_MAX and its<br>
symbol set is limited to a-Z 0-9 and "-", "_".<br>
<a href="https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149" rel="noreferrer" target="_blank">https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149</a><br>
Can not comment on t.* modules as they are bypassing C library and<br>
doing some magick in Python instead of fully integrating with the rest<br>
of GRASS.<br>
<br>
It is pity that the PR relaxing band reference requirements got merged<br>
although it didn't change the documentation to reflect changes in the<br>
code. It is my fault as I wasn't fast enough to stop Markus Metz from<br>
merging without required changes. I hope Markus M. will fix his<br>
blunder and provide changes also to the documentation to reflect<br>
changes in the code made by him.<br>
<a href="https://github.com/OSGeo/grass/pull/1796" rel="noreferrer" target="_blank">https://github.com/OSGeo/grass/pull/1796</a></blockquote><div><br></div><div>I cc'ed Markus.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> Band references need some further discussion IMHO<br></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Harmonization of t.* Python based band reference handling with C<br>
library based one should be done by someone who completely understands<br>
the Python part in t.* (as an idea and not only code). As<br>
functionality is required in both C and Python code, C has precedence<br>
over Python (functionality in C + wrapper functions for Python or just<br>
plain ctypes as it is done in tests).<br>
<br>
>From the i.* module point of view, modules g.bands and i.bands are not<br>
required and are not used at all. Besides i.bands is a bad module name<br>
as bands are assigned to rasters and not groups thus it should be<br>
r.bands but the management functionality is already covered with<br>
r.support leaving only printing for i.bands without an alternative. I<br>
would drop i.bands completely unless it is completely reworked.<br>
g.bands is a nice idea but, unless someone implements editing part, it<br>
is of limited use. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> my 2 cents<br>
> Vero<br>
<br>
Māris.<br>
</blockquote></div></div></div>