contour labelling [was "Re: [R] image ()"]

Rather than adding every capability known to science, improved interfaces
between R and other programs (e.g., GMT), would be a better investment
of resources.

Commercial packages (S-plus, Matlab) end up trying to incorporate every
application for which there is a market, and have no great incentive to
make it easier for people to work with external applications.

In contrast, free packages should strive to support flexible interfaces
between applications, although getting that to work smoothly outside unix
may not be feasible.

This principle is demonstrated by contrasting octave with matlab. Octave
provides a pipe routine and (as a script, popen2).  Although matlab and
octave support essentially the same interface for binary I/O on files,
octave has a few extras (popen, waitpid) that make all the difference. If
you want to pass data thru an external program in Matlab most people will
end up writing temporary files rather than fuss with named pipes.  One
technical issue that limits the utility of pipes outside unix is the
problem of DOS/Win/OS2 "text" mode.

My work involves remote sensing images where files are large enough that
I/O time is an issue and one must be careful about allocating space for
temporary files.  Octave makes a very useful "glue" tool for this work. In
R it appears to be necessary to do the I/O via temporary files, which is
inefficient and, for very large data sets, impractical.  Indeed, I often
use octave to format data from several binary files into temporary ASCII
files suitable for use with R's read.table, but R would be much more
useful if I could read directly from (multiple, binary, assorted format)
files.

It is certainly possible to add binary I/O capabilities to R via a
(binio?) library, although not a trivial project to support all the
data types and big/little endian conversions.  R and octave share 
similar limitations on the internal data types, so you would often
be reading, say "unsigned char" data into double precision arrays.

In practice, a binio library would probably need file handles so that
you can open a file and read or write arbitrary locations using arbitrary
data conversions.  Changes to current file I/O functions might be
useful, e.g., so read.table could be connected to the output of a
filter called via "popen2".

Returning to Bill's problem, many GMT routines can read from stdin and
will issue messages to stderr or stdout.  Most people write shell scripts
to run the series of GMT commands (programs) needed to perform an analysis
or generate a plot.  Such scripts often use awk or perl to perform some of
the calculations.  Currently, one could use R to save data to an ASCII
file and then run such scripts using "system".  For many problems,
however, translating the shell script to a series of popen2() commands
with data piped directly from R to a GMT program would save considerable
system resources and allow the use of R's computational capabilities.

--
George White <aa056 at chebucto.ns.ca>  tel: 902.426.8509
  Bedford Inst. of Oceanography, Nova Scotia, Canada.

include upgrading contour, image, persp etc.  In addition I hope that
he will also add some mapping facilities along the lines of GMT (using
their shoreline database).

Now would be a good time to make suggestions about desirable features.

OK this may be a long shot.
I often have to make a plot of like this: the heights (z) of trees in a
forest (whose locations are unif rand x,y) are recorded. Now we make a 3D
shaded surface plot of the (x,y,z) data. A triangular mesh is made by
finding the Delaunay triangulation (nearest neighbours are connected).
[...] 

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._