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

Hamish hamish_nospam at yahoo.com
Wed May 26 09:26:13 EDT 2004


> - 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'm not sure this is really something that should be part of the GIS.
The GIS should be able to import flat x,y,z,data1,data2,string1,string2
style data in a generic sense. Any hardware drivers should in turn be
generic and dump their data into a flat ascii file which many programs
can access. The two should run concurrently but independently.
?

For ideas, see how the 'gpsd' GPS interface can talk to GRASS in real
time:  http://op.gfz-potsdam.de/GRASS-List/Archive/msg10661.html

It isn't wonderful, but it works. Note NMEA is a fairly generic
standard,
so this was pretty easy to do.

I'm sure someone would be happy to host a repository for add-on Free
software somewhere though.. who knows, maybe it should be added to our
giant pile of code.



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

such as 'r.colors color=grey.eq'?
Specific suggestions for improvements are welcome.



Hamish




More information about the grass-user mailing list