* Vaclav Petras <[email protected]> [2018-08-23 19:09:47 -0400]:
On Thu, Aug 23, 2018 at 5:40 AM Nikos Alexandris <[email protected]> wrote:Is there an elegant alternative?As for your script design/coding approach: You were concerned about nice history at one point. You can wrap it, not just in a plain script, but in a module.
There are three things in mind, in order: Provenance (as you name it below), then re-usability/reproducibility lastly legibility.
Then you can hide any particulars of the implementation and write proper history in the module. This avoids changing history which would lead to history not being representative of what actually happened (provenance is the keyword here).
Changing, or hiding, history is not wanted. As elsewhere, also in this case, intermediate map names of some processing, get a prefix using `script.core.tempfile()` [0], to get them easily removed at exit. Removed if the user does not request for their output, which is an option. If the user requests for their output, they are renamed to the requested output name, so as to no be picked up by the clean up `atexit.register(cleanup)` call that does this job. [0] https://grass.osgeo.org/grass75/manuals/libpython/script.html?highlight=tempfile#script.core.tempfile Specifically, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 1 && tmp.22599.19.opportunity == 1), 1, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 1 && tmp.22599.19.opportunity == 2), 2, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 1 && tmp.22599.19.opportunity == 3), 3, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 2 && tmp.22599.19.opportunity == 1), 4, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 2 && tmp.22599.19.opportunity == 2), 5, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 2 && tmp.22599.19.opportunity == 3), 6, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 3 && tmp.22599.19.opportunity == 1), 7, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 3 && tmp.22599.19.opportunity == 2), 8, if((tmp.22599.18.tmp.22599.11.tmp.22599.6.recreation_potential == 3 && tmp.22599.19.opportunity == 3), 9))))))))) will be best represented as: if((potential == 1 && opportunity == 1), 1, if((potential == 1 && opportunity == 2), 2, if((potential == 1 && opportunity == 3), 3, if((potential == 2 && opportunity == 1), 4, if((potential == 2 && opportunity == 2), 5, if((potential == 2 && opportunity == 3), 6, if((potential == 3 && opportunity == 1), 7, if((potential == 3 && opportunity == 2), 8, if((potential == 3 && opportunity == 3), 9))))))))) Making it more meaningful and useful is the point. By the way, I am still not sure how the combinations done by `r.cross` will look like. The order of the end categories [1, 9] matters. To test, perhaps easy to solve with an `r.categories` call and a proper set of rules. Some 'tmp' parts, in the names above, are prototyping leftovers, and may be simply unnecessary. I have to correct/fix. The question, anyhow still valid, is: what is the cost for "provenance" if these prefixes are squashed? If the answer is "none" or "almost none", then why not allow this squashing? Are the design choices (program) made so far the right ones? Perhaps they can be improved/corrected, and questions like the above can be avoided altogether. I will look into this. Further: what does it mean for "reproducibility"? Will it actually help to understand better what is what, trace errors or support improving an analysis? Perhaps, improve the algorithm/module itself? As for legibility, I think it is as important as any other part of programming. Spend less time in reading, more in thinking what can be done with this tool.
If you actually publish the module or not that's a different question.
I, and my client, will publish it. It's mentioned here https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Autumn_2017#In_person and then here https://grasswiki.osgeo.org/wiki/GRASS_GIS_Community_Sprint_Bonn_2018#In_person. It's not yet there. There have been modifications in the underlying algorithm(s). And there are processes to deal with licensing and distribution. We are doing our best.
Your script/code is needed to reproduce the data in anyway since you want to change history and additionally it would be reasonable to use your script/code to actually reproduce, so then the only difference is number of files and interface of the scripts (some custom solution versus module).
Splitting your code would also make sense because you are saying it is quite long.
It does/is planned. It's been a long prototyping of the implementation.
Vaclav
Thank you Vaclav, as usual your messages help a lot, in many directions. Grateful to be (feel) part of this community, Nikos
signature.asc
Description: PGP signature
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
