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