On Sat, May 29, 2010 at 10:06 AM, Roger Bivand <roger.biv...@nhh.no> wrote:
> 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, They don't seem to work very well at all for Spatial*DataFrames. If I add coordinates to meuse to get a SpatialPointsDataFrame and head(that) I get all the 'rows' but with only the cadmium measurements. It's slicing it the wrong way. Odd. > 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! str is great if you need to know the str-ucture of an R object. But it doesn't even align the values so you can see across rows of your data, which is what I'd like print to do (by analogy with print.data.frame). Currently if I print a SpatialPolygonsDataFrame I get the structure. Print methods should do better than that - you're almost suggesting not having, for example, a print method for data frames and that we'd be better off having what print.default(anyDataFrame) gives us. So my proposal is that print of a SpatialPolygonsDataFrame class should print like a data frame but with some indicator of the geometry at the start of the row, such as POLYGON(...) - literally with dots, there's no need to spell it out. Similarly for Lines. Another suggestion is for head() and tail methods on Spatial*DataFrame objects - I think just subscripting [1:n,] from the object and returning would do it. I think currently head and tail treat these objects as lists and the results are not pretty. Barry _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
