<div dir="ltr">Hi Nikos!<br><div class="gmail_extra"><br><div class="gmail_quote">2018-06-04 17:23 GMT+02:00 Nikos Alexandris <span dir="ltr"><<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* Roberta Fagandini <<a href="mailto:robifagandini@gmail.com" target="_blank">robifagandini@gmail.com</a>> [2018-06-04 16:14:16 +0200]:<div><div class="gmail-h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi all!<br>
<br>
Thank you, Moritz and Nikos, for your suggestions!<br>
<br>
2018-06-04 11:54 GMT+02:00 Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net" target="_blank">nik@nikosalexandris.net</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ciao Roberta,<br>
<br>
great work!<br>
<br>
Moritz got me faster, as I intended to chime in, with similar<br>
suggestions.<br>
<br>
So +1 for:<br>
<br>
- a "real" module, as Moritz described it<br>
<br>
</blockquote>
<br>
Done! I added the folder to my github repository but I have some trouble<br>
compiling the module with g.extension:<br>
<br>
g.extension extension=i.sentinel.mask operation=add url=<br>
<a href="https://github.com/RobiFag/GRASS_clouds_and_shadows" rel="noreferrer" target="_blank">https://github.com/RobiFag/GRA<wbr>SS_clouds_and_shadows</a><br>
<br>
error message:<br>
g.extension extension=i.sentinel.mask operation=add url=<br>
<a href="https://github.com/RobiFag/GRASS_clouds_and_shadows" rel="noreferrer" target="_blank">https://github.com/RobiFag/GRA<wbr>SS_clouds_and_shadows</a><br>
Fetching <i.sentinel.mask> from <<br>
<a href="https://github.com/RobiFag/GRASS_clouds_and_shadows/archive/master.zip" rel="noreferrer" target="_blank">https://github.com/RobiFag/GRA<wbr>SS_clouds_and_shadows/archive/<wbr>master.zip</a>> (be<br>
patient)...<br>
Compiling...<br>
make[1]: *** No rule to make target `/tmp/grass7-roberta-701<br>
4/tmpe7QEso/i.sentinel.mask/sc<wbr>ripts/i.sentinel.mask', needed<br>
by `script'. Stop.<br>
/bin/sh: 1: cannot create /usr/lib/grass74/error.log:<br>
Permission denied<br>
make: *** [i.sentinel.mask] Error 2<br>
ERROR: Compilation failed, sorry. Please check above error messages.<br>
<br>
any suggestion?<br>
</blockquote>
<br></div></div>
Maybe irrelevant, but perhaps it is best to name the script as<br>
`<a href="http://i.sentinel.mask.py" rel="noreferrer" target="_blank">i.sentinel.mask.py</a>`?</blockquote><div><br></div><div>I named the file as you suggested but I still have some problems, now the error message is: </div><div><br></div><div><div>Fetching <i.sentinel.mask> from <<a href="https://github.com/RobiFag/GRASS_clouds_and_shadows/archive/master.zip">https://github.com/RobiFag/GRASS_clouds_and_shadows/archive/master.zip</a>> (be patient)...</div><div>Compiling...</div><div>Installing...</div><div>make: *** No rule to make target `install'. Stop.</div><div>WARNING: Installation failed, sorry. Please check above error messages.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- for using the metadata file, and parsing it -- my experience with<br>
 Landsat and other high-resolution satellite products, showed it's 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 more<br>
 "static" designs, i.e. expecting specific hardcoded options, such as<br>
 band names, or their order.<br>
<br>
</blockquote>
<br>
I have already thought about parsing the metadatafile to retrieve the input<br>
bands but at the moment the module requires atmospherically corrected bands<br>
and if users perform the atmospheric correction on their own I don't have<br>
any control on naming. Moreover, the module needs to know which raster map<br>
corresponds to the blue band, to the green band and so on in order to apply<br>
the rules for clouds and shadows detection. Therefore I need users specify<br>
each band but maybe I can manage this issue requiring a specific suffix in<br>
the bands' names (e.g. blabla_blue, blabla_green, etc.). In this way, users<br>
have to provide only the prefix (blabla) while the module search for all<br>
raster maps with the specified prefix and at the same time it is able to<br>
recognize each band.<br>
<br>
Anyway, the aim of the next coding period is to create a python script that<br>
wraps in a single GRASS module the download and import phase<br>
(i.sentinel.download and i.sentinel.import), the atmospheric correction<br>
using i.atcorr and the cloud and shadow detection procedure. In particular,<br>
for what concerns the atmospheric correction, I'd like to implement an<br>
iterative procedure that executes i.atcorr for all bands of the input image<br>
changing accordingly the requested input parameters. This part should<br>
simplify the management of input maps.<br>
</blockquote>
<br></div></div>
One thing here: massive processing workflows like to have simple<br>
processing building blocks. One Input -> one Process -> one Output. In<br>
"your" case:<br>
<br>
- Input: name of/request one band and associated<br>
 metadata, and optionally other ancillary data.<br>
<br>
- Process: download, import, removal of atmospheric effects to estimate<br>
 surface reflectance<br>
<br>
- Output: surface reflectance ("corrected" for atmospheric effects) of<br>
 the requested input band<br>
<br>
This building block can run in one processing units/node. Making use of many<br>
processing units/nodes, this block can run in parallel for different<br>
input bands.<br>
<br>
I suggest to build the module in a way that it runs for one band or as many<br>
bands as the user requires for his workflow. I did this in<br>
<a href="https://gitlab.com/NikosAlexandris/i.fusion.hpf/blob/master/i.fusion.hpf.py" rel="noreferrer" target="_blank">https://gitlab.com/NikosAlexan<wbr>dris/i.fusion.hpf/blob/master/<wbr>i.fusion.hpf.py</a>.<br>
I don't suggest this script as an example. Yet I think the concept "for<br>
one or many" is useful and wanted.<br></blockquote><div><br></div><div><div>Thank you! This is very interesting..</div><div>I will check your module and I will certainly take it into account even if all the requested input bands are mandatory otherwise the clouds and shadows detection procedures [0] will return wrong results.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
As a sidenote:<br>
<br>
I think that we don't use the term "correction"<br>
correctly. An image acquired by a satellite-borne sensor is not "wrong"<br>
to need a correction. Rather, we try to retouch the digital form of the<br>
acquisition, in order to estimate the energy that was actually reflected<br>
by the surface, before the signal travels through the atmosphere.<br>
<br>
I studied remote sensing with Thomas Lillesand's; Ralph W.<br>
Kiefer's book "Remote Sensing and Image Interpretation". The book<br>
"correctly" touches this very question.<br>
<br>
Maybe it's only a perspective, and others have another say on this.<span class="gmail-"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- PEP8 rules and keeping module options in separate lines to increase<br>
legibility<br>
<br>
In line with the suggestions on style, I would stress out to fully<br>
spell out the names of functions, options, descriptions of flags,<br>
iterables and iterators.  It will make it easier for the next reader of<br>
your code.<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yes, you are both right!! I have to clean up the code from the style point<br>
of view and it will be one of the tasks of this week and especially of the<br>
last days before the GSoC Evaluation.<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Finally, it's a good idea to write even mini-tests, while you are<br>
progressing, for the small functions that eventually develop to keep the<br>
full scrip compact, functional and more legible.<br>
<br>
Writing a test, for your module, in the end, will be much easier.<br>
<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Sorry Nikos but I don't really understand what you mean by<br>
"mini-tests"..are you referring to the examples in the manual page?<br>
</blockquote>
<br></span>
For a function f(x) that takes x as an input and gives you y as output,<br>
test, for example, whether the output value 'y' is within the expected<br>
range. Test your single functions, inside the script. Use assertions, for<br>
example, etc. If you have 10 functions in your script, and have written<br>
a test for each, you will save your time later on when you will revisit<br>
the code to debug or modify.  Spend as much time as you can in testing.<br></blockquote><div><br></div><div>Ok, it's clearer to me now! I will certainly do it!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Again, this is what I try to stick to. And, lastly, I am not a core<br>
developer, nor a mentor. I am, however, interested in seeing this module<br>
coming alive. So, apologies to the mentors that I am chimingi in.<br></blockquote><div><br></div><div>Thanks, I hope you will continue to follow the development of the project/module. As for me also your suggestions and feedback are very useful!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[rest deleted]<br>
<br>
Grazie, Nikos<br></blockquote><div><br></div><div>Ciao</div><div>Roberta </div><div><br></div><div><br></div><div>[0] <a href="https://drive.google.com/file/d/1KYEKvNBurBFHw1xUTLjM0PW80Z-7br81/view?usp=sharing">https://drive.google.com/file/d/1KYEKvNBurBFHw1xUTLjM0PW80Z-7br81/view?usp=sharing</a> </div></div><br></div></div>