Emissivity retrieval problem i.landsat8.swlst about grass-addons

[JacopoRosaRizzotto]

Ok, here is the command string in use:

i.landsat8.swlst mtl="D:\Lavoro\Convenzione Cattolica\Landsat8_150320_USGS\LC08_L1TP_192028_20200315_20200325_01_T1_MTL.txt" b10=LC08_L1TP_192028_20200315_20200325_01_T1_B10@PERMANENT b11=LC08_L1TP_192028_20200315_20200325_01_T1_B11@PERMANENT qab=LC08_L1TP_192028_20200315_20200325_01_T1_BQA@PERMANENT landcover=Classificazione_FROM_GLC_10E_50N@PERMANENT lst=lst window=7

The add-on is available by accessing the extension repository of GRASS GIS through the GUI. The main add-on windows appears like this:

[NikosAlexandris]

@JacopoRosaRizzotto Can you manually check if there is a valid pixel value in the FROM GLC map? Can you share your data? Area which you are working on?

[NikosAlexandris]

(By the way, @JacopoRosaRizzotto, best to include the exact command issued in the bug description.)

[JacopoRosaRizzotto]

About the data: I am working on the 10E 50N area, retrieved from: http://data.ess.tsinghua.edu.cn/fromglc2015_v1.html

For what concerns the command issued, I ran the script directly from the GRASS i.landsat8.swlst graphic interface, so I didn't manually send any command, and the only output I received is the one I posted here.
Thanks.

[NikosAlexandris]

@JacopoRosaRizzotto In the bottom part of any command-"window" in GRASS GIS' GUI, one can see and copy-paste the command. However, I have never used this add-on through the GUI. It is not available, as far as I know, through the GUI's menus. Is it?

[NikosAlexandris]

Dear @JacopoRosaRizzotto, sorry for the late reply. Too much work.
I have been given this a try myself and found out there are some if not several stuff to update in the module. So, I can't test it straightforward.

The error is strange. The land cover classes are hardcoded, here: https://github.com/OSGeo/grass-addons/blob/master/grass7/imagery/i.landsat8.swlst/average_emissivity.csv. I remember that this is the file that is read by the module. The classes are the ones from the FROM-GLC nomenclature. So, it must be something else.

Is the region set correctly? But even so, I think the module does this automatically and uses one of the thermal bands to set the region.

Can you verify the land cover map is correctly imported? Can you visualise it in GRASS GIS for example?

[NikosAlexandris]

@JacopoRosaRizzotto A series of updates for Python 3 were required. I updated the add-on.
(As messy as it is, looking at it now after so many years... :-D).

Here the LST map mentioned in the first post of this issue:

By the way, the add-on worked in Python 2.

[neteler]

@JacopoRosaRizzotto A series of updates for Python 3 were required. I updated the add-on.

@NikosAlexandris where did you update it? Here I don't see recent changes:
https://github.com/OSGeo/grass-addons/commits/master/grass7/imagery/i.landsat8.swlst

Is there a different repo?

[NikosAlexandris]

@JacopoRosaRizzotto A series of updates for Python 3 were required. I updated the add-on.

@NikosAlexandris where did you update it? Here I don't see recent changes:
https://github.com/OSGeo/grass-addons/commits/master/grass7/imagery/i.landsat8.swlst

Is there a different repo?

Yes (actually two synced ones: https://gitlab.com/NikosAlexandris/i.landsat8.swlst and https://github.com/NikosAlexandris/i.landsat8.swlst). The straightforward way to update the grass-addons seems to be to copy-paste the stuff inside it (in the i.landsat8.swlst subdirectory) and loose however, the detailed commit history.

I wonder if the GRASS GIS dev team thinks of using submodules, or any other way/technique, to be more flexible when developing individual add-ons.

[NikosAlexandris]

See d422fa9

[neteler]

See d422fa9

Thanks for the massive update!

[neteler]

Is there a different repo?

Yes (actually two synced ones: https://gitlab.com/NikosAlexandris/i.landsat8.swlst and https://github.com/NikosAlexandris/i.landsat8.swlst). The straightforward way to update the grass-addons seems to be to copy-paste the stuff inside it (in the i.landsat8.swlst subdirectory) and loose however, the detailed commit history.

I wonder if the GRASS GIS dev team thinks of using submodules, or any other way/technique, to be more flexible when developing individual add-ons.

Perhaps @wenzeslaus has an idea how to handle that?