[GRASSLIST:3490] Re: Geophysical/Potential field modules for
benducke at compuserve.de
Tue May 25 16:21:53 EDT 2004
Allright, this is getting to be a rather verbose discussion.
Just some short clarifications and comments:
- a "device driver" in our context would simply receive a stream
of bytes from the serial line/USB parallel port, whatever,
using Linux /dev/* entries. I don't know about MacOS and windows
but it surely is not much harder to do it in one of those
environments. On top of that, there would be a device-dependent
part which actually makes sense of the byte stream by applying
a vendor-specific protocol. This critical information can
really only be got from the manufacturer/manual. Other than that, I don't
think any OS-level programming would be necessary.
- I have used the term 'GRASS database element' several times.
This actually refers to a directory below the LOCATION/MAPSET
directory in GRASS terminology. E.g. 'fcell' is the element
(directory) that stores floating point raster maps.
The GRASS programming API has very convenient functions to
create/delete and read/write user-definable elements. I deem
this an easy and clean way to integrate all the additional
info and data into the grass location. If someone wants to
share his/her geophysical analysis with someone else, all
that is required is to zip the needed elements into a package
and copy them into the other user's location.
- I agree that XML is a very nice format to store the processing
list, as long as we use only GRASS modules/GUI to make any changes
to it. If we keep it XML, we can use the excellent cross-platform
open source 'libxml2' and won't have any trouble parsing module
A plain ASCII list would have the benefit of the user being able
to edit it with a simple text editor, but would ease file corruption
and mean a lot of additional work to parse module parameters when
reading the list.
- I don't think there will be too much vector programming involved
in the basic framework, so it does not really matter what
GRASS 5 version we use -- they all share the same raster API
I personally am using 5.3 right now but am slowly switching
over to 5.7. Site files are officially banned from GRASS 5.7 and
everything to do with them would have to be replaced with
vector points and the vector API.
Craig: I don't use relational DBs too often, so my creativity in
this field is a bit limitied: where would you envision the usefulness of
a DB connection in this framework?
- I would imagine a basic GUI in the same way Craig outlined it
- GRASS has color ramp tools, but these are -- well (cough).
We need something more convenient, that allows the user to easily
e.g. rescale 100 gray scale values to +/- 3 STD of the image data.
Well, that's all I can think of, right now.
More information about the grass-user