<div dir="ltr">Hi Moritz,<br><div class="gmail_extra"><br><div class="gmail_quote">2018-06-06 9:12 GMT+02:00 Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Roberta,<br>
<br>
On 04/06/18 16:14, Roberta Fagandini wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2018-06-04 11:54 GMT+02:00 Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a> <mailto:<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.ne<wbr>t</a>>>:<span class=""><br>
<br>
- for using the metadata file, and parsing it -- my experience with<br>
Landsat and other high-resolution satellite products, showed it's<br>
best to<br>
trust the individual metadata that accompany an acquisition.<br>
Parameters may be very specific to one single acquisition.<br>
Also, a module that is designed to be "dynamic" is more<br>
future-proof and easy to maintain and update.<br>
For example, reading band names from the meta-data, as opposed to<br>
more<br>
"static" designs, i.e. expecting specific hardcoded options, such as<br>
band names, or their order.<br>
<br>
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.<br>
</span></blockquote>
<br>
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.</blockquote><div><br></div><div>Thank you for the hint! I think the file option is the best choice at the moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>Providing more automation as possible is my goal! I hope to be able to reach it ;-)</div><div> </div><div>Roberta</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Moritz<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>