[GRASS5] The status of 5.0

[rgrmill at rt66.com]

I'm using an unusual mail client, so I hope this letter format isn't a 
mess...

Regarding customizations I've made:

Markus, most of my changes are things that I've talked about on the list 
before and some of them are modules that I've actually submitted.  One 
of them is a change I've been maintaining locally since beta 7.

1)  I made a number of changes to allow multiple users to run the same 
GRASS installation at the same time and to access files in the database 
without being the owner of the file.  Locking is done by mapset and 
permissions are granted on the basis of group membership.  This requires 
changes in Init.sh, mapset_msc.c and gisinit.c

2)  As I wrote a couple months ago, I have a "resource manager" that 
associates each monitor with a different geographic window and different 
gis environment, including mapset and location.  There is associated 
with that capability a module that allows the user to change the current 
mapset and location without leaving grass and (hopefully) without 
bothering anyone else working at the same time.  This allows one user to 
work in multiple locations/mapsets at the same time.  The manager also 
specifies certain types of system behavior; monitors are automatically 
erased when their region is changed and removed when the user exits 
grass.  The manager offers the kind of persistence and event-driven 
behavior that we sometimes talk about needing for future development.  
The manager, in one form or another, provides a lot of opportunities for 
future development.

I still have one bug left to work out.  When it's done I'll submit a 
description of the program and the working source code as a proposal.

It requires changes to put_window.c, get_window.c, env.c and d.mon.  
Switching between different locations or mapsets also means that the 
socket files have to be kept somewhere other than the mapset/.tmp 
directory.  Fortunately Eric Miller's socket functions allow that, but 
they have to be compiled in a non-default way.

3)  I've written or modified a number of modules:

r.out.ascii  I added an -s flag to print surfer ascii grids.  I gave you 
that change some time ago and it hasn't been included in the release.  I 
also have been getting a read error from r.in.ascii when using the -s 
option, and have to use a separate program to import some Surfer ascii 
files.

r.in.mf  This reads MODFLOW 2-D binary data into GRASS raster files

r.in.list  This reads MODFLOW list-formatted files into GRASS raster 
files

r.basin  (Probably needs a new name)  This creates masks of contiguous 
areas that meet one of several different logical criteria.  I used this 
to map a geomorphic surface as a continuous area with a slope below a 
given threshold.  It contains several tests other than the "less than or 
equal to" test that I used for that application.

r.proj, v.proj, s.proj  I've modified all of these to perform the 
NAD83<-->NAD27 conversions.  This also requires a version of the proj 
library later than 4, a new library function (pj_do_projA.c) and a place 
to store the conversion tables.  These need to be updated to a more 
recent version of the proj library.

I have a few other utilities that I keep that aren't built as GRASS 
modules, but probably should be.  One imports dxf files that can't be 
handled with v.in.dxf.  I promised several months ago that I would 
upgrade v.in.dxf and haven't had time to get to it yet.  One reads text 
from dxf files and writes GRASS paint label files and one reads text 
labels from site files and writes GRASS paint label files.  I use the 
paint label files in ps.map to label data points and surface features.  
I even have a utility that resamples output from MT3DMS output (3-D 
chemical transport and reaction in ground water) and produces vertically 
refined 3D grid files.  They let G3D produce some pretty stunning 
results.

I'm not trying to make a point that I've done a lot of work that should 
be included in GRASS but I do have to admit that it would reduce my 
workload if they were included in GRASS.

My point is that probably anyone who has kept a GRASS installation for 
production has modified their installation in one or more different 
ways.  As a result I find it really unlikely that a lot of old GRASS 
users (like Blacklands in Texas, for instance) are going to switch to 
GRASS 5. I also doubt that future GRASS 5 users are going to want to 
make frequent updates of their production installations.

Incidentally, have the old GRASS 4.x users been contacted to see if they 
intend to upgrade to 5?  Has anyone worked with them to include their 
modifications, or to see what capabilities they need?  It appears to me 
that if we could get even one big GRASS 4 installation to switch to 
GRASS 5 then their people could make big contributions to the ongoing 
development of GRASS 5.

Roger Miller