On Sun, 15 Jul 2007, Tim Keitt wrote: > On 7/14/07, Roger Bivand <[EMAIL PROTECTED]> wrote: >> On Sat, 14 Jul 2007, Michal Gallay wrote: >> >> > Dear R Users, >> > >> > could you please advise me on doing map algebra with spatial grids? It's >> > the first time I am using spatial objects in R. I have imported an ascii >> > grid file and wanted to round the values in it or sum with a value, but >> > it >> > gives an error message: >> > >> > > require(maptools) >> > > x <- readAsciiGrid(fname="xxxx.asc") >> > > x+3 >> > Error in x + 3 : non-numeric argument to binary operator >> > > round(x,2) >> > Error in round(x, digits) : Non-numeric argument to mathematical >> > function >> > >> >> Arithmetic operations are not defined for SpatialGridDataFrame operations, >> as the columns of the data frame (here a single column) may contain data >> of different classes. Do the operations on the columns directly: >> >> names(x) >> >> If there is a column called "band1", then >> >> x$band1 + 3 >> >> will print "band1" + 3, and >> >> x$band1 <- x$band1 + 3 >> >> will add 3 to the "band1" column. Think what would happen if band1 was >> categorical or logical to see why doing arithmetic directly isn't such a >> good idea. > > Roger, > > While I agree that arithmetic directly on S?DF objects does not make a > lot of sense, I have always taken the view that if the name of a type > includes "data frame", then you are implicitly promising that the > object is substitutable for any other data.frame class object in a > function call. So if S?DF is meant to inherit (formally or informally) > from data.frame, one should be able to use a S?DF anywhere you could > use an ordinary data.frame object without changing the result. Of > course, I realize that S?DF is not mean to inherit directly from > data.frame (so it is clear from the programming standpoint, ie there > is no "inherits" relationship between data.frame and S?DF). Perhaps it > would be more clear to users if a different naming scheme were used?
Tim, While there is something in your suggestion, my understanding of the White Book (1992) introduction of data frames is that they are lists of vectors of varying types but of equal lengths, and that they should play well with formulae. The current Spatial*DataFrame do indeed do this, and you can use them with model.frame() inside for example lm(), gstat(), and generally almost everywhere a real data frame is needed as a data= argument. I cannot recall ever using an arithmetic operation on a data frame myself, although I may be an exception (I coerse to matrix). Rather than trying to inherit from data.frame, the methods ($,[, [[, and assignment versions) provide data.frame operability. Certainly I can see that there are differences of approach here, especially if remote sensing data are never going to have factors (unlike say GIS integration, where categorical data do occur). The exchange on the list earlier today (about why read.table() returns a data.frame and by default converts a character vector to a factor) seems to back me up (from my point of view, of course!). Best wishes, Roger > > THK > >> >> Hope this helps, >> >> Roger >> >> > Thank you for any suggestions. >> > >> > Best wishes, >> > >> > Michal >> > >> > >> > >> > >> >> -- >> 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: [EMAIL PROTECTED] >> >> _______________________________________________ >> R-sig-Geo mailing list >> R-sig-Geo@stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo >> > > > -- 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: [EMAIL PROTECTED] _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
