[GRASSLIST:3490] Re: Geophysical/Potential field modules for GRASS?

[Benjamin Ducke]

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
  parameters.
  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.

Benjamin