[GRASS5] Driver Update

[Glynn Clements]

Markus Neteler wrote:

> > Incidentally, this is one area where I could imagine a 256-level
> > ceiling being a real issue. Can someone with experience of satellite
> > (or similar) imagery confirm or deny whether data with more than 256
> > levels exists?
> 
> Yes, they do exist: For example the rather new ASTER satellite
> (better than LANDSAT-TM from the multispectral view, I think, data
> freely available, 15m/30m/90m resolution) provides several
> 12bit TIR (thermal infrared) bands:
> http://asterweb.jpl.nasa.gov/instrument/character.htm

One issue with handling this type of data at present is that raster
layers don't appear to have an associated "full intensity" value.

Consequently, programs which need to coerce the inputs to a unit
(zero-to-one) range (e.g. d.rgb, r.his, r.composite; probably others),
typically use the associated colour table. Unfortunately this only
gives 8 bits of resolution, even if the layer has more than that.

Might it be worthwhile adding a property similar to the range
(G_read_range etc) but which represents the conceptual "zero" and
"one" values?

> Another: POLDER
> http://www.eoc.nasda.go.jp/guide/satellite/sendata/polder_1_e.html
> 
> There should be some more and more to be expected in near future.
> 
> > Also, the core RGB<->HSV functionality already seems to be well
> > handled by the hsv.rgb.sh and rgb.hsv.sh scripts. These use floating
> > point, so there's no loss of intensity resolution due to quantisation. 
> 
> Thanks for pointing this out. The general problem in GRASS is
> the odd mixture of old and new code... as we all know already.

Having said that, all scripts suffer from the drawback that they don't
generally behave like other GRASS programs. I've recently been
thinking about creating a utility specifically for running scripts.

One possibility would be a modified tclsh which includes key libgis
functions (e.g. G_parser) as tcl commands. However, I don't know
whether tcl is sufficiently widely available to be able to justify
using it in place of the Bourne shell.

Another possibility would be a simple utility which could be invoked
by shell scripts to handle the G_parser() stuff before re-invoking the
script with a full argument list (unless "help" or "--int*-desc*" were
used). However, this could still leave incompatibilities between C
programs and scripts in other areas.

Comments?

-- 
Glynn Clements <glynn.clements at virgin.net>