<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 10, 2021 at 3:02 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">2021-09-10 5:56 GMT+03:00, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>>:</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">...<br>
= Not a big difference from existing implementation<br></blockquote><div> </div><div>Just to be clear, all these would be in addition to the proper handling of band references and applied only when you don't want to deal with band references directly.<br></div><div><br></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>
> Option 4) i.gensigset et al. labels the bands 1,2,3,... on the fly only in<br>
> the signature file and i.smap et al. uses the same numbering scheme when<br>
> the rasters don't have band references. Band references are handled only<br>
> when needed even on the module level in addition to the user level.<br>
<br>
Didn't understood how this differs from option #2.<br></blockquote><div><br></div><div>The difference would be that the band references are never added to the rasters in #4, only added to the signature file and re-created in the same way for classification. In #2 they are actually added to rasters by i.group. However, here is another option which I think is better than my previous ones: </div><div><br></div><div>Option 5) Add a library function to read band reference which has a fallback (band reference getter with a default). A reasonable fallback seems to be the name of the raster map. This function can be then used on all places in the signature/classification context instead of Rast_read_bandref. i.gensigset et al. writes raster names as band references to the signature file, i.smap et al. reads these names and matches them with result from this new function unless the user didn't set or renamed the raster map in the meantime. No additional step needed to the v7 workflow if you don't need to use band references. The signatures are associated with the raster map name rather than the order (as it is in v7). Signatures from one mapset can then be used in another mapset as long as the names of the rasters are the same (let's say each scene imported under the same name into its own mapset for parallel processing). Something like this function:<br></div><div><br></div><div>/** Return band reference or fallback to raster name if it is not set. */<br></div><div>char *Rast_read_bandref_with_fallback(const char *name, const char *mapset)<br>{<br>   char *ret = Rast_read_bandref(name, mapset);<br>   if (ret)<br>       return ret;<br>   else<br>       return G_store(name);<br>}<br> </div></div></div>