* Blumentrath, Stefan <[email protected]> [2016-05-14 21:21:25 +0000]:
Hei Nikos (and others),
H(e)i :-) ( On my way to understand how to work as, what you described, an educated programmer (more than half-way through a series of excellent courses, Rice University). To this end, I try to build good programming habits: clean and extensively commented code, modularity (assisting re-usability) and tests, tests and tests. And of course, (algorithm-ic) efficiency (read input size vs. running time). That's why I use a lot of helper functions, instead of "lambda" functions. )
Actually, on a second thought, I am considering to change the module significantly. Maybe better to just generate a file with reclassification rules for all possible combination of bitpattern?
That would simplify the module (only the filter criteria are required as input), and the resulting r.reclass rules can be applied to any landsat scene... So they can be generated once and then reused.
That would be more efficient if several scenes should be processed with the same procedure.
Decreasing the final running time, yes. Another option, in such a case of multiple scenes, might be to cache the rules in question, after the first loop (?).
However users would have to run r.reclass themselfs in a next step... But that is probably more in line with the modular concept of GRASS...
What do you think /prefer?
I'll have more time next month and, I think, I can contribute in this discussion. I am sorry if this isn't of great help at the moment. I started implementing the idea of a dedicated Landsat8 python class (for GRASS, of course): https://github.com/NikosAlexandris/landsat8_metadata. One of the To Do points is "Implement mechanism to translate QA pixel values to QA bits, and vice versa?". It would be wonderful to have feedback from higher level experts in the list. Warmest Regards, Nikos _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
