[GRASS-dev] GSoC 2018 report week 03 - GRASS GIS module for Sentinel-2 cloud and shadow detection
mlennert at club.worldonline.be
Wed Jun 6 00:12:01 PDT 2018
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
> "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.
More information about the grass-dev