Hi Roberta,
On 04/06/18 16:14, Roberta Fagandini wrote:
2018-06-04 11:54 GMT+02:00 Nikos Alexandris <[email protected]
<mailto:[email protected]>>:
- 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
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
