I comment here on the several reactions to my message
"Re: Forestry and Grass + scripts for models"
Issue 1: Are "classic" programming languages (i.e., FORTRAN, c, c++...)
adequate for GIS modeling?
Rich Shepard <rshepard@appl-ecosys.com>
" It was only when I moved to microcomputers and C (in the mid-1980's) that
I learned the value of commenting code. Scientists aren't taught this;
programmers are.
My code now is at least 50% comments; often much more. I explain why I did
something a certain way or what I was trying to accomplish. The effort is
repaid manyfold when I look at old code years later. :-)"
Well, this demonstrates that C is not a good language for modeling, as
you have
to repeat each line in a different language. Would English be an adequate
language for this
message if I had to repeat every paragraph in a different language because
virtually nobody (even not myself!) could understand what I'm saying?
(OK,
sometimes my English can be so obscure that this problem could actually
be real!).
Note that I'm talking about modeling. I understand that, in other
applications,
FORTRAN, C, C++,..., can be the best alternative. But, in modeling, often you
cannot evaluate the program just by the result. If you write a program to
display an image, you can easily detect an error in the code because
the display would be wrong. Or if you write a program to calculate
an FFT you can use a simple input and compare the result to your own
computation
or to the result produced by another FFT program: the result is predictable.
Instead, in modeling, the result is not predictable (yet): that's why
you make the model. Also, you can have a CORRECT result out of a WRONG model:
the result must be produced by processes that are physically, biologically,
ecologically... consistent, and this should be assessed by other scientists
being able to read the code. Which implies a simple syntax with, ideally,
one action per line.
Bernhard Reiter <bernhard@uwm.edu> has a different opinion:
This is pretty much a question of style. Good C programs a very readable.
(C++ is more difficult.)
I think that this could be true for very skilled C "writers" and "readers"
conforming to the same style (and not only to the same language!). I would
argue that the time devoted to the programming itself would be of the same
order of magnitude that the time devoted to think on the processes to be
modeled. Take the example of writing this message: I can concentrate
on the idea that I want to communicate and spend a minimum time on the
language itself (I know, most of you would prefer that I spend more
time on improving my language..., but you get the idea)
Issue 2: Are the scripting languages around convenient alternatives?
Bernhard Reiter <bernhard@uwm.edu>:
Any scripting language will do that. The shell does it.
I would recommend python. (www.python.org)
But you also mean GRASS functions.
It is clear that almost ANY scripting language (even the c-shell)
can be used for a simple flow of grass commands: most of us use this method
every day. The problem is when, within the model, you must
ANALYSE the result of a grass command and the subsequent
actions depend upon the result of this analysis.
Leonard Coop <coopl@ava.bcc.orst.edu>:
Here is a snippet from a perl script (I didn't write it but I use it)
running GRASS showing how you can use perl files as standard i/o to
write to GRASS functions, in this case r.mapcalc:
open RMAPCALC, "|r.mapcalc" or die "Can't launch r.mapcalc";
# STEP 5: ADD CORRECTIONS
print RMAPCALC "$corrname = ($basename * $rationame)/1000\n";
# STEPS 6: FORCE NEGATIVES TO ZERO
print RMAPCALC "$outname = max($corrname,0)\n";
close RMAPCALC;
Well, here we have 5 lines for what should be just one,
r.mapcalc "out = max( ($basename * $rationame)/1000, 0)"
...and not to tell about the annoying and redundant "$": if we write
a program, the default should be that the names of the variables represent
the variables, or should I sign this message as $AgustinLobo ? If I sign
as Agustin Lobo, would anybody understand that my name has written the
message?
Bernhard Reiter <bernhard@uwm.edu>:
Perl generally is a greater mess than "C". It is much harder to write
good structured programs in perl.
But,
"Roderick A. Anderson" <raanders@altoplanos.net>:
Despite what others may think or say perl is an excellent language for
simple to very complex projects. It is only as obscure as you want it to
be.
May be we could do the following: use a short model as an example and code
it in different scripting languages.
ISSUE 3. Are "high level" languages (i.e., Splus (R as free alternative),
Matlab (Octave as free alternative), IDL ...) adequate for GIS modeling?
Rich Shepard <rshepard@appl-ecosys.com>:
I've know of S-Plus and I just discovered R. I think that it
would be ideal to link GRASS and R for analytical purposes.
"Pete St. Onge" <pete@seul.org>
Alternatively, R has a batch mode that can be called from the shell. You
could actually build an R script programmatically from another app once
the data files have been created, then launch R to do batch processing
by running the script.
Yes, as with Splus and, probably, Matlab. The problem, as I said, is
that the communication between R and Grass would be through writing
and reading files: this is slow (remember a model can have thousands
of iterations) and uses more disk space (which is becoming a minor
problem, though).
Another problem with Splus (I think that R is better but don't know
how much better) is that it is very inefficient with FOR loops, as it
allocates all the memory at once. This is a big problem for simulations,
that typically have long loops.
ISSUE 4. The use of Grass in modeling
Bruce Byars <Bruce_Byars@baylor.edu>
What we have been very successful in is using grass
as a kind of "front-end" processor to develop/analyze/display data
for use in complex stand-alone models. In our experience this is
the best of both worlds. It is not really time-consuming to write
either scripts or C programs for this type of data development.
In this way, a user can use whatever model they are comfortable
with, using grass for data development and display.
For example, we use grass to develop input data into the SWAT
watershed hydrology model. SWAT is a very large and complex
model, but using grass we significantly cut down the time to develop
inputs and analyze results spatially.
Yes, this is an obvious application. But I think that Grass could
(should) be
used for the actual modeling as well.
Final comment: using C for writing is like making a toy out of raw
plastic material:
you can do whatever you want but it is difficult and, probably, the parts
will not
be used by others. Using grass commands within a script (either a shell
script
or Splus, Matlab etc) is more like using a LEGO: you have more constraints,
but the parts are standard, which implies that many others use them and can
detect errors.
Agus
Dr. Agustin Lobo
Instituto de Ciencias de la Tierra (CSIC)
Lluis Sole Sabaris s/n
08028 Barcelona SPAIN
tel 34 93409 5410
fax 34 93411 0012
alobo@ija.csic.es
http://pangea.ija.csic.es/alobo
