Hi Moritz, 2018-06-06 9:12 GMT+02:00 Moritz Lennert <mlenn...@club.worldonline.be>:
> Hi Roberta, > > On 04/06/18 16:14, Roberta Fagandini wrote: > >> 2018-06-04 11:54 GMT+02:00 Nikos Alexandris <n...@nikosalexandris.net >> <mailto:n...@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 > > >
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev