[GRASS-dev] GSoC 2018 report week 03 - GRASS GIS module for Sentinel-2 cloud and shadow detection
nik at nikosalexandris.net
Mon Jun 4 02:54:01 PDT 2018
Moritz got me faster, as I intended to chime in, with similar
So +1 for:
- a "real" module, as Moritz described it
- 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.
- PEP8 rules and keeping module options in separate lines to increase legibility
In line with the suggestions on style, I would stress out to fully
spell out the names of functions, options, descriptions of flags,
iterables and iterators. It will make it easier for the next reader of
Finally, it's a good idea to write even mini-tests, while you are
progressing, for the small functions that eventually develop to keep the
full scrip compact, functional and more legible.
Writing a test, for your module, in the end, will be much easier.
I am sure you know all this. Yet, discussing it is a good thing in
Keep up the good work, Nikos
* Moritz Lennert <mlennert at club.worldonline.be> [2018-06-04 11:03:41 +0200]:
>Hi Roberta !
>On 03/06/18 14:38, Roberta Fagandini wrote:
>>I'm Roberta Fagandini and I'm working on my GSoC project, a GRASS
>>GIS module for Sentinel-2 cloud and shadow detection.
>>This is my report for the third week of coding.
>>*1) What did I complete this week?*
>> * Implemented some changes from dev feedback (e.g. r.univar instead of
>> * Tested the modified python script and fixed bugs
>> * Prepared the python script in order to start implementing the GUI
>> * Started implementing the GUI
>> * Made some changes to the code depending on the GUI requirements (add
>> controls and check on input, output and temporary file, etc.)
>> * Cleaned up the whole code
>> * Tested the GUI and fixed bugs
>> * Frequently added the basic version of the GUI to my
>> GitHub repository 
>> * Shared progress with the community
>I'm sorry, I haven't had the time to test your module, yet. A few
>recommendation, though, based on a quick read of the code. I assume
>that the relevant file is i.sentinel.mask.
>- I would recommend to immediately create a real complete module that
>can be installed with g.extension. This means creating a directory
>with the module as .py file, a .html manual page file, but which could
>be empty at the beginning, and a Makefile (see existing scripts in the
>core code or in addons for examples). Being able to install everything
>directly from github with a simple g.extension call makes testing much
>- I see that all the input bands are marked as required. Are they all
>necessary to the calculations ? If yes, aren't all these bands always
>from the same acquisition ? If yes, then maybe we can avoid parameter
>inflation by either just asking for a prefix and then getting all
>bands from that prefix (following standard sentinel naming), or
>provide the MTD file and read the band names from there, or you could
>ask for a group name and it would be up to the user to create the
>group before launching the module.
>- A small idea in terms of coding style: I personally think that code
>should be as easily understandable as possible. For example: in the
>formulas you use the f_bands list. Maybe you could make this into a
>dictionary and so instead of reading f_bands, we would read
>f_bands['blue'] making the formulas easier to follow.
>- Please follow PEP8 style guide (see ). Amongst others, this means
>limiting lines to 79 characters. So:
> - The general style used for gscript.*_command calls in Python scripts is
> i.e. each parameter on its own line. This make it easier to read
> and lines shorter.
> - The same for r.mapcalc calls: if necessary you can construct
> the individual rules over more than one line.
>I'll try to find some time this week to test the module and maybe come
>back with some more feedback on the coding.
>Great job so far, though !
>grass-dev mailing list
>grass-dev at lists.osgeo.org
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the grass-dev