[GRASS5] Porting list

GRASS GIS GRASS GIS developer
1

On 11/2/04 3:07 AM, "Radim Blazek" <blazek@itc.it> wrote:

Michael, thanks for cleaning up the list. It could be useful to have
a HTML table like we have for vectors/sites.

I guess it could be helpful in some ways to list all the 5.3/5.4 modules and
their current status (but see below). However, this is about 400 modules (I
counted them when I redid the GUI). As you say below, somehow we need to
know what is really useful across the broader user base rather than just
make 5.7 (and up) 5.3/4 with a new vector model. Perhaps the new survey will
give some indication.

------ some comments: ---------------

------------------------------------

'Missing' and missing modules cannot stop 5.8/6.0 release.
For me, it is important to get a short list of modules (functions)
realy missing in 5.7, with an explanation why it should be ported,
rather than a long comparison of bin directories.

I agree completely. Just because something was in GRASS historically, it no
reason--by itself--that it should be ported to 5.7.

Perhaps some functions are no longer necessary, and new functions should be
considered. [For example, I'd like to see an agent modeling routine, like
Mark Lake's Magical made more generic, given a better interface, and
implemented in GRASS 5.7+. Agent modeling is becoming increasingly important
for research on complex systems (like human social systems), but remains
largely inaccessible to researchers because it requires considerable,
specialized programming skills. Another example is the discussion about the
appropriateness of adding kriegging and geostatistics or leaving it to
another package.]

Overall, I'd personally like to see:
1) more generic tools and less very specific ones (e.g., a generic
anisotropic spreading module rather than just one specifically for
wildfires), and
2) an easier way for users to develop and add in specific tools to GRASS
-along the lines of a 'plugin' or an ArcView extension. (Except for
scripting, this currently requires programming in C and users compiling from
source to add a particular new function.) This way, users could more easily
tailor GRASS to their particular needs while development could focus on
powerful, generic tools that could be adapted to many specific uses.

Just my 2 cents/centimos worth.

Michael

______________________________
Michael Barton, Professor of Anthropology
School of Human, Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

> 'Missing' and missing modules cannot stop 5.8/6.0 release.
> For me, it is important to get a short list of modules (functions)
> realy missing in 5.7, with an explanation why it should be ported,
> rather than a long comparison of bin directories.

I agree completely. Just because something was in GRASS historically,
it no reason--by itself--that it should be ported to 5.7.

I agree too. One of the nice points about 5.7 is that is doesn't include
lots of old bloat. We should only spend time to port things that are
still useful: just because we can doesn't mean we should. Same goes for
adding every available command to the Tcl menus IMO.

[...]

Another example is the discussion about the appropriateness of adding
kriegging and geostatistics or leaving it to another package.]

If we can fix the bugs in s.surf.krig without too much trouble, sure why
not? We can always add a link the the help page pointing to the R
solution if the user wants something more serious. But because (probably
better) alternatives already exist it shouldn't be a high priority.

Overall, I'd personally like to see:
1) more generic tools and less very specific ones (e.g., a generic
anisotropic spreading module rather than just one specifically for
wildfires), and

2) an easier way for users to develop and add in specific tools to
GRASS-along the lines of a 'plugin' or an ArcView extension. (Except
for scripting, this currently requires programming in C and users
compiling from source to add a particular new function.) This way,
users could more easily tailor GRASS to their particular needs while
development could focus on powerful, generic tools that could be
adapted to many specific uses.

(1) provides (2) via shell scripting or with "simple" languages like
python or perl. If we provide generic low level commands (eg mapcalc),
then C isn't needed to get things done (it's just more efficient).
I think we already do this pretty well.

Hamish

3

Hamish,

You are right about shell scripting plus the mapcalc (and other GRASS
commands) offering a powerful development environment, with a built-in way
of getting a nice tcltk interface. Hill-shading, changing
mapset/location/gisdbase, and Brovey transforms are good examples of widely
useful and powerful scripts.

Python and perl provide even more versatility. But working in python or perl
requires that these languages be installed on user machines. (I am thinking
about people creating custom modules that others can use). While both are
freely available and are normally installed on Linux systems, python does
not come normally on Mac OSX (I think perl does, but I'm not sure since I
installed both on my systems along with other things quite awhile back), and
neither come with windows (though you can add them to cygwin). This can be a
significant installation step for people outside the Linux/Unix world.

Still there are some applications that still might really require that new
modules be written. In such cases now, anyone else using the module needs to
have a self-compiled version of GRASS so that they can compile the new
module against it. This really limits the number of people who can use it.

However, if the new module is a pre-compiled binary, can't it just be
inserted into the proper locations in a compiled GRASS binary distribution
(e.g., /bin, /included, and/or /lib)? This assumes, of course that it is
compiled for the OS properly (though I wonder how much this matters for a
module that is simply using the rest of the OS-specific compiled grass
code?). I guess what I'm asking is, 'is there any reason a module cannot be
compiled so that it can simply be added to an existing GRASS installation as
a binary, rather than needing to be compiled against it from source?'

Certainly for scripts, and possibly for other ways of creating modules, it
would then be very nice to have an easy way for users to add modules to the
menu system for easy use. Lorenzo Moretti has proposed an 'extension' menu
heading (and added QGIS to it as a test). But for this to work well, it
would be necessary to make a small installation/deinstallation routine that
in essence would add (or remove) a line to the tcltk code for the extension
menu exec-ing the module in question. I would think that the easiest way to
do this would be to have the extension menu code as a separate, editable
file that would be sourced from the main menu. Items added to it would show
up in the extension menu.

The goal, would be to get more people involved in writing scripts,
python/perl, or C modules that could be easily added to an existing GRASS
installation. I hope you can excuse my rambling here. I've been thinking
about this for awhile, but have never had time to put together a concrete
plan for doing this. So perhaps if I at least make the suggestion in a
schematic way it might generate some interest.

Cheers,
Michael

On 11/2/04 5:55 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Overall, I'd personally like to see:
1) more generic tools and less very specific ones (e.g., a generic
anisotropic spreading module rather than just one specifically for
wildfires), and

2) an easier way for users to develop and add in specific tools to
GRASS-along the lines of a 'plugin' or an ArcView extension. (Except
for scripting, this currently requires programming in C and users
compiling from source to add a particular new function.) This way,
users could more easily tailor GRASS to their particular needs while
development could focus on powerful, generic tools that could be
adapted to many specific uses.

(1) provides (2) via shell scripting or with "simple" languages like
python or perl. If we provide generic low level commands (eg mapcalc),
then C isn't needed to get things done (it's just more efficient).
I think we already do this pretty well.

____________________
C. Michael Barton, Professor of Anthropology
School of Human, Cultural, and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

4

Michael Barton wrote:

Still there are some applications that still might really require that new
modules be written. In such cases now, anyone else using the module needs to
have a self-compiled version of GRASS so that they can compile the new
module against it. This really limits the number of people who can use it.

Right; "make install" should install a complete set of libraries and
headers, not just libgis/libdatetime, as well as the Makefile
fragments in the mk (5.3) or include/Make (5.7) directories.

I guess what I'm asking is, 'is there any reason a module cannot be
compiled so that it can simply be added to an existing GRASS installation as
a binary, rather than needing to be compiled against it from source?'

The main problem is version compatibility. There is no simple way to
check whether a stand-alone module will be compatible with an existing
installation.

Given the number of people using CVS snapshots, providing add-ons only
for specific numbered versions is of limited benefit.

--
Glynn Clements <glynn@gclements.plus.com>

5

On Nov 3, 2004, at 10:58 PM, Michael Barton wrote:

Python and perl provide even more versatility. But working in python or perl
requires that these languages be installed on user machines. (I am thinking
about people creating custom modules that others can use). While both are
freely available and are normally installed on Linux systems, python does
not come normally on Mac OSX (I think perl does, but I'm not sure since I
installed both on my systems along with other things quite awhile back)

Both perl and python are included on Mac OSX as long as the developer tools are installed... which in all honesty should be installed if anyone is using GRASS.

Kirk R. Wythers
Dept. of Forest Resources
University of Minnesota
email: kwythers@umn.edu
tel: 612.625.2261
fax: 612.625.5212

6

Michael,

... please let me suggest to put the porting list
into the new WIKI. I wasn't able to properly decode
your attachment (strange carriage returns), so I didn't
insert it.

General comment:
Important (IMHO) is to focus on functionality, not
just to compare module names. We should try to merge
modules wherever possible to minimized replicated
code.

Thanks

Markus