If you have used Reot before and tried to install it from CRAN recently, you may have noticed the following message:

Warning in install.packages : package ‘Reot’ is not available (for R version 3.0.2)

This is because the Reot package was abandoned due to a name change suggested by Huug van den Dool, the author of the EOT algorithm and also the reviewer of our JSS paper introducing the package (about which I am very happy). Here's what he said:

I am in slight doubt whether Reot is a good acronym. It looks in that spelling like REOF which often means rotated EOF. In case there is EOF in R, and there must be, how would that be called? Not Reof!?

I totally agree with his reservation about the acronym and therefore decided to rename the package remote which is short for R EMpirical Orthogonal TEleconections. So the name merely gained two letters. I thought it is quite clever as teleconnections imply forcing from some place not in the immediate vicinity of the observed phenomenon and therefore the term remote seems to fit quite well (think television remote control).

Apart from the name change, remote is really an enhanced version of Reot. Not in the sense that computational performance was improved, but in the sense that it is now coded in an object oriented way. This means that R's native plot() function will now work on objects returned by eot(). Furthermore, the package has gained a predict() function to use the identified linear models on new data not seen before by the model. This can be useful in many instances, e.g. to extend spatio-temporal data sets in time. In our paper (to which I will provide a link here as soon as it is published) we show one example using predict() to downscale NDVI images for the region of Mt. Kilimanjaro. Here I quickly want to show how easy it is to use this new functionality (taken from the example 0f ?remote::predict()). I would like to stress that this is solely to demonstrate the code, whether it is a valid application or not is another question.

library('remote')

### not very useful, but highlights the workflow
data(pacificSST)
data(australiaGPCP)

## train data using eot()
train <- eot(x = pacificSST[[1:10]],
             y = australiaGPCP[[1:10]],
             n = 1)

## 
## Calculating linear model ... 
## Locating 1. EOT ...
## Location: 271.5 11.5 
## Cum. expl. variance (%): 79.82

## predict using identified model
pred <- predict(train,
                newdata = pacificSST[[11:20]],
                n = 1)

## compare results
opar <- par(mfrow = c(1,2))
plot(australiaGPCP[[13]], main = "original", zlim = c(0, 10))
plot(pred[[3]], main = "predicted", zlim = c(0, 10))

Another enhancement is that remote has gained classes EotMode for a single mode and EotStack for an object of multiple modes. The latter can be subset()ed and names() can be set and retrieved.

All in all, the new functionalities introduced in remote should make the analyses much more pleasant and easier to code as the data handling functionalities should be more familiar, especially for people who have worked with the raster package before. As we say in our paper, we are hopeful that there will be manifold applications where remote may prove to be a useful tool.