From: Martin Maechler <maechler at stat.math.ethz.ch>
To: royle at bearmtn-e0.cgd.ucar.edu
CC: lgygax at access.unizh.ch, r-help at stat.math.ethz.ch
Subject: contour labelling [was "Re: [R] image ()"]
Mime-Version: 1.0 (generated by tm-edit 7.106)
"Jeffrey" == Jeffrey A Royle <royle at bearmtn-e0.cgd.ucar.edu> writes:
.....
Jeffrey> One other question: Contour does not appear to label contour
Jeffrey> lines. Was this a neglected detail, or a feature?
``neglected detail''.
I think we are glad for any volunteers to add this !
I have a paid ``volunteer'' who started work yesterday. His job will
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.
Ross
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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).
I am not talking about doing some form of interpolation (hence forcing the
data onto a regular grid).
Right now I make this type of plot with Mathematica, but it would be nice
to do this in R and get rid of Mma.
Thanks very much Ross for getting the persp() function into R.
Bill
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
I have a paid ``volunteer'' who started work yesterday. His job will
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).
Great!
Now would be a good time to make suggestions about desirable features.
- ability to save and re-plot contours (e.g., for doing contours with
annotation, or selecting different pieces of a contour "object")
- a good way to save the state of the last perspective used (in S-PLUS
3.3 and earlier you have to keep a "perspective" object around and pass it
with every call
- flexible ways of specifying 3-D objects to add to a perspective plot,
grids for back and sides of plot space, etc.
I always found the S-PLUS 3-D plotting routines klugey and fragile (for
example, you had to play around a lot with margins a lot in non-obvious
ways just to get things to show up on the plot) and it would/will be
lovely to have open, robust 3-D plotting primitives.
thanks,
Ben Bolker
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
I have a paid ``volunteer'' who started work yesterday. His job will
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).
Great!
Now would be a good time to make suggestions about desirable features.
- ability to save and re-plot contours (e.g., for doing contours with
annotation, or selecting different pieces of a contour "object")
- a good way to save the state of the last perspective used (in S-PLUS
3.3 and earlier you have to keep a "perspective" object around and pass it
with every call
- flexible ways of specifying 3-D objects to add to a perspective plot,
grids for back and sides of plot space, etc.
I always found the S-PLUS 3-D plotting routines klugey and fragile (for
example, you had to play around a lot with margins a lot in non-obvious
ways just to get things to show up on the plot) and it would/will be
lovely to have open, robust 3-D plotting primitives.
I assume that means S 3-D plotting routines: the last five years have
brought Trellis and Axum versions to S-PLUS. Interactive rotation of
perspective plots would be a great boon, as would shading options for
perspective plots, including contouring on such plots.
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272860 (secr)
Oxford OX1 3TG, UK Fax: +44 1865 272595
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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.
On Thu, 3 Dec 1998, Bill Simpson wrote:
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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).
I am not talking about doing some form of interpolation (hence forcing the
data onto a regular grid).
There is GPLed Delaunay triangulation code in Java (including a fast
approximate algorithm) as part of Visad
(http://www.ssec.wisc.edu/~billh/visad.html). There is an old C
implementation which may well have the same algorithms.
-thomas
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
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).
I am not talking about doing some form of interpolation (hence forcing the
data onto a regular grid).
There is GPLed Delaunay triangulation code in Java (including a fast
approximate algorithm) as part of Visad
(http://www.ssec.wisc.edu/~billh/visad.html). There is an old C
implementation which may well have the same algorithms.
There is Delaunay code in the R package tripack, and, implicitly, in
package akima which may well be helpful: if I understand Bill
correctly he wants to put a plane on each triangle to get a surface (which
is interpolation) and Akima was more sophisticated and used quintics
to achieve a smooth interpolated surface. We may be missing the crux
here: was it to have a means of displaying such surfaces?
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272860 (secr)
Oxford OX1 3TG, UK Fax: +44 1865 272595
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
There is Delaunay code in the R package tripack, and, implicitly, in
package akima which may well be helpful: if I understand Bill
correctly he wants to put a plane on each triangle to get a surface (which
is interpolation) and Akima was more sophisticated and used quintics
to achieve a smooth interpolated surface. We may be missing the crux
here: was it to have a means of displaying such surfaces?
Yes, bang on. I knew of the existence of the Delaunay code in the R
libraries. Yes I want to make a picture that places a planar facet on each
triangle. The resulting surface looks like the surface of a cut diamond
for example (assuming the cuts give triangular facets). So far as I know
there is no way to display such a 3D plot in R. persp uses rectangular
rather than triangular mesh.
From the description of the akima package, it sounded like it just did
some of the work required PRIOR to making the 3D plot. But that is useless
if I can't make the plot.
I think of it as the 3D version of the 2D
connect-the-dots-with-line-segments plot. Now the points are connected by
planes rather than lines.
Bill
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
George White writes:
> 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 is a pretty crucial point. The technology in R (and S and Octave
for that matter) is OLD, and is not well suited to what you propose.
However, I think that a number of new things are coming along which
will help.
The first of these is CORBA which allows very general communication
between computational processes, the other is Java. I'm not really a
Java fan, but I don't think that it can be ignored - it just has too
much momentum.
A number of us (including the current S authors) have been having
discussions about how we can use this new technology. I would expect
that the next couple of years will begin to see a new generation
software begin to emerge. And yes, it will be open software, although
with a BSD style licence rather than GPL.
> 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.
I guess I have a couple of problems with GMT. 1) It is postcript only
and 2) it is pretty rigid. But the authors have done an enormous
service in making their GSHHS database available. All I'm really
proposing is to provide a simple R interface to that.
For binary data, the latest R has an interface to the HDF (version 5)
library (provided by Marcus Daniels). This moves in the direction
of providing a standard means for binary data exchange.
Ross
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
In contrast, free packages should strive to support flexible interfaces
between applications, although getting that to work smoothly outside unix
may not be feasible.
We have a interface which provides a generic way for applications to read and
write objects to a database. (This is not a query interface.) I use it for
transferring time series data between S/R and Fame, but there is nothing which
makes it especially specific to S or R or Fame. The protocol is not specific to
time series, but the data format we use is. It handles endian problems and uses
RPC so it works over the Internet. It communicates directly and does not write
intermediate files. I work in Unix but a commercial vendor has implemented a
Windows version and also a version for Matlab. (I have not used these.) There
should be no cross-platform problem. Details and the code are available at
<http://www.bank-banque-canada.ca/pgilbert>. (I have a version of the code which
works with R but it is not on the web site yet. If you want that please contact
me.)
There appears to be some overlap between what we have done and HDF or NetCDF but
I am not too familiar with these. (If someone knowledgeable would be prepared to
brief me I would appreciate that.)
I expect someday CORBA will be the way to go. There is an ongoing effort to by
an OMG "Special Interest Group/ Domain Task Force" to define statistical objects
and they currently have an RFP/RFI for which I believe they are hoping to have
reponses by Dec. 19. (A few more details are attached below. I can provide more
information if anyone is interested, please email me directly rather than
through the list.) I believe this is being co-ordinated with the UN/EDIFACT
"generalized statistical message" (GESMES) effort.
Paul Gilbert
______
Descriptions and schedules for all RFPs and RFIs in progress are
available for viewing on the OMG Web site at
http://www.omg.org/techprocess/meetings/schedule.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._