On Fri, 28 May 2010, Barry Rowlingson wrote:
On Fri, May 28, 2010 at 5:18 PM, Roger Bivand <roger.biv...@nhh.no> wrote:
On Fri, 28 May 2010, Etienne Bellemare Racine wrote:
I taught I could add my two cents.
Nice suggestion!
I agree !
No. Only for SpatialPointDataFrame objects, which is what it does already.
Please, understand that str() is a *much* better choice in effectively all
cases where summary() isn't used. For the Spatial* objects, set a
max.level=2 or similar, and you can *see* what is in it. The proposed
print() method for a big multiband raster will also run away with you. Do
str(), not print()!!!
I'm not sure what you're saying 'No' to here, Roger. Neither str(xx)
nor summary(xx) present the object as a data frame. Conceptually its a
data frame where one of the columns is a geometry, and seeing it print
as such is a good thing (imho). I'd like to never have to use x...@data
again!
Just pragmatics, since things which have rushed off the top of my screen
really are not much help, I find.
I use as(xx, "data.frame") when needed, but most often subset both
observations and variables by "[". I'm not sure where displaying all the
data gets you for more than a trivial number of observations and
variables, though? The output will still swamp the console/terminal
buffer. I'm thinking of a multi-band raster, but even standard
show(meuse.grid) as a data.frame only leaves rows 2605-3103 on screen for
a standard gnome-terminal. The data editor I see doesn't have a scroll
bar, so to scroll, one would need an external viewer, I think.
In other software systems (octave, Stata, ...), one can turn on and off a
more/less screen-by-screen displayer (not scrolling upwards, just
chunking), but I'm not aware of an equivalent in R/S. I'm not sure how
head() and tail() work in R, and personally use str() by default. If I
need to access the coordinates of a particular line or polygon, I print()
just that list element (Line or Polygon object).
I can see what you mean, but feel that users will benefit much more by
using str(), which is a real gem!
Roger
I'm not sure trying to truncate the coordinates for nice formatting
is a good idea though, but some indication when printing a
Spatial*DataFrame that its a dataframe with geometries seems a good
idea.
Barry
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
