[GRASS-dev] ​GSoC 2018 report week 03 - GRASS GIS module for Sentinel-2 cloud and shadow detection

[Moritz Lennert]

Hi Roberta,

On 04/06/18 16:14, Roberta Fagandini wrote:
> 2018-06-04 11:54 GMT+02:00 Nikos Alexandris <nik at nikosalexandris.net 
> <mailto:nik at nikosalexandris.net>>:
> 
>     - for using the metadata file, and parsing it -- my experience with
>       Landsat and other high-resolution satellite products, showed it's
>     best to
>       trust the individual metadata that accompany an acquisition.
>        Parameters may be very specific to one single acquisition.
>       Also, a module that is designed to be "dynamic" is more
>       future-proof and easy to maintain and update.
>        For example, reading band names from the meta-data, as opposed to
>     more
>       "static" designs, i.e. expecting specific hardcoded options, such as
>       band names, or their order.
> 
> I have already thought about parsing the metadatafile to retrieve the 
> input bands but at the moment the module requires atmospherically 
> corrected bands and if users perform the atmospheric correction on their 
> own I don't have any control on naming. Moreover, the module needs to 
> know which raster map corresponds to the blue band, to the green band 
> and so on in order to apply the rules for clouds and shadows detection. 
> Therefore I need users specify each band but maybe I can manage this 
> issue requiring a specific suffix in the bands' names (e.g. blabla_blue, 
> blabla_green, etc.). In this way, users have to provide only the prefix 
> (blabla) while the module search for all raster maps with the specified 
> prefix and at the same time it is able to recognize each band.

I forgot that the data had to be pretreated, so reading your 
argumentation, I actually think your current approach is the most 
flexible and so the best. Imposing band names is not a good idea IMHO. 
One option could be a file= parameter which allows providing all the 
names of all input bands in a text file (respecting a given order), but 
I think this is not a priority.

> 
> Anyway, the aim of the next coding period is to create a python script 
> that wraps in a single GRASS module the download and import phase 
> (i.sentinel.download and i.sentinel.import), the atmospheric correction 
> using i.atcorr and the cloud and shadow detection procedure. In 
> particular, for what concerns the atmospheric correction, I'd like to 
> implement an iterative procedure that executes i.atcorr for all bands of 
> the input image changing accordingly the requested input parameters. 
> This part should simplify the management of input maps.

That's sounds really nice. I agree that your module should do one thing 
and do it good. As you say, wrapper scripts can then combine different 
modules to provide more automation.

Moritz