[GRASS-dev] Added i.landsat8.swlst in grass-addons

[Blumentrath, Stefan]

Hi Nikos,

There are no real benefits from removing the kelvin_to_celsius function except for that code is a few lines shorter and the function is no longer used (plus that it is unlikely that you will be using it in the module in future). But the same applies probably to the "copy" helper function and the other stuff I just commented out could be removed too I guess, but I am not educated as a programmer. So others are much more qualified to comment on coding styles...

However, now I also had a closer look at the output of i.landsat8.swlst from a methodological point of view. Here it seems that - at least in my case of the city of Oslo - the difference between land-cover-corrected-LST and not land-cover-corrected-LST (I used land cover type 70 as a constant which has an average emissivity value) is almost insignificant (~ +- 1 degree celsius). The max/min differences were between -20 and +20 degrees Celsius, but these values appeared only at the boundary of the LST maps. Within the scenes differences were never > +-5 degree and very rarely > +-2.
Given the amount of data and computation required to incorporate land cover effects, you might consider to make a land cover map optional and just use a constant in the map calculator expression if no landcover map is provided...?

Another issue I came across it that currently, a possibly existing user mask will be simply overwritten, while it might be more friendly to backup the user mask before and restore it after the module finished... However, in order to simplify the module a bit, an option might be to move the masking part out of the module, and probably write something like this: https://grass.osgeo.org/grass70/manuals/i.modis.qc.html for Landsat, if that does not exist yet(?). Seems you thought about it already?
Based on Markus tutorial (http://courses.neteler.org/processing-landsat8-data-in-grass-gis-7/#Applying_the_Landsat_8_Quality_Assessment_%28QA%29_Band) and the info here http://landsat.usgs.gov/qualityband.php that should be a quite doable job. If no landsat bitpattern module exists I might be able to volunteer...
The idea would be something like this: extract raster values from QA band, loop over those values, compare the bit pattern representation of the integer values with acceptable bit patterns defined by the user, add the result of the comparison to r.reclass rules, and finally reclassify the QA band...

But all in all the results look pretty good, which you could see here: http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst and here: http://urban.nina.no/layers/geonode%3Alc81980182015183lgn00_lst_const_lc if our GeoNode worked as it should...

Kind regards,
Stefan



-----Original Message-----
From: Nikos Alexandris [mailto:nikos.alexandris at unige.ch] 
Sent: 9. mai 2016 16:31
To: Vaclav Petras <wenzeslaus at gmail.com>
Cc: Nikos Alexandris <nik at nikosalexandris.net>; Blumentrath, Stefan <Stefan.Blumentrath at nina.no>; grass-dev at lists.osgeo.org
Subject: Re: [GRASS-dev] Added i.landsat8.swlst in grass-addons

* Vaclav Petras <wenzeslaus at gmail.com> [2016-05-08 20:10:46 -0400]:

>On Sat, May 7, 2016 at 5:14 PM, Nikos Alexandris 
><nik at nikosalexandris.net>
>wrote:
>
>> -        The k-flag (keep current computational region) is invers to GRASS
>>> standards. Maybe better to switch the behavior?
>>>
>>
>> Not sure.  It's kind of related to the #1 mistake everyone does, 
>> forget setting the right region extent.  So, I'd thought of letting 
>> the module operate on the whole scene.
>>
>
>Then really all GRASS modules should be changed.

:-) -- Let's change'm all!

I am joking, of course.  Will alter the behaviour in the module.

>
>>
>> Do we have a reference for this ("GRASS standards") or you mean the 
>> "common" behaviour of most modules?
>
>
>No. Perhaps we need another Submitting page on Trac or perhaps just 
>adding a best practice to the main Submitting page.

Yep!

Cheers, Nikos

[..]