[GRASS-user] Possible Grass Bug
Nikos Alexandris
nik at nikosalexandris.net
Tue Jul 3 15:59:47 PDT 2018
Rich Shepard:
> I've known about python integration but was not aware of the
>g.gui.modeler. Since GRASS is only one of the tools I use, and not on all
>projects, I would like to learn when it would be more appropriate to use a
>python or wxGUI Graphical Modeler rather than a bash shell script.
> I'm not challenging the use of python or g.gui.modeler. I want to
>determine whether either (or both) have advantages -- to me -- over writing
>a shell script and using it directly rather than as input to wx.gui.modeler
>or a python script.
Thanks Richard. I too, wonder what others think about this.
In short, from my learning efforts and practical experiences, always within the
GRASS GIS framework, I think:
- Python is best for scientific cross-platform tools. Likely, it will
run on any known operating system.
- the Graphical Modeler is a great way to overview and learn about process at
a glance.
- Bash shell scripts are great to glue different tools together. Complex
work flows and more than 100 to 200 lines of code, may become hard to
maintain. And likely it won't run everywhere, if this matters.
In support,
- Python is the default scripting language for GRASS GIS. As well, the
huge amount of Python libraries and tools speaks for itself.
- After all, we always try to visualise (data,) processes (and
information). Why not with a native GRASS GIS tool? -- This is (also)
a reminder to myself!
- Just an example, obviously not an ideal one: the shell script
https://gitlab.com/NikosAlexandris/r.internal.sh/blob/master/r.internal
seems, to me, overall easier to (re-)implement in Python.
> After reading the g.gui.modeler page I understand what it does but its
>advantages over a plain shell script are not obvious to me. Pointers to more
>information might provide the answers.
In the past, while beginning scripting in Python, the GUI modeler helped
me understand easier and learn better. The visual representation of and the
code behind a model, were easier to grasp than reading only a program.
A life-long learner, Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180704/c43e6978/attachment-0001.sig>
More information about the grass-user
mailing list