[GRASS5] Porting list

[Michael Barton]

On 11/2/04 3:07 AM, "Radim Blazek" <blazek at 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