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

[Roberta Fagandini]

Hi Moritz,

2018-06-06 9:12 GMT+02:00 Moritz Lennert <mlennert at club.worldonline.be>:

> 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.


Thank you for the hint! I think the file option is the best choice at the
moment.


>
>> 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.


Providing more automation as possible is my goal! I hope to be able to
reach it ;-)

Roberta

>
>
> Moritz
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180606/7929338b/attachment-0001.html>