5 What’s not included

While terra has a very large amount of functionality, it doesn’t have everything. This section covers functionality you will have to look elsewhere for.

• tidyverse integration
• spatial dependency and regression
• data downloading
• Native R classes

5.1 Tidyverse compatability

The sf package is the preeminent package for working with vector data in R. It plays nicely with the tidyverse packages, and has built-in ggplot2 support. Sf supports wide to long spatial data transformations, something which definitely has more applicability for vector data than raster raster data.

If you are tied to tidyverse syntax and plotting but also need terra speed, there is a package called tidyterra which can provide some of that functionality. Most notably tidyterra provides ggplot2 geom and autoplot methods for both spatRasters and spatVectors. However, it may make more sense to transition any spatVectors to simple features using the functions below if you want tidyverse integration.

• terra to sf: st_as_sf()
• sf to terra: vect()

5.1.1 What about rasters?

The stars package provides tidyverse support for rasters. In general, it is not as well documented and does not provide as much user guidance as terra. Additionally, stars does not automatically handle data sets that are too large to to be read into memory. You have to know that your data set is too big and then make changes to your code detailed here. It does have some additional flexibility in terms of data types and grid schema, but these seem more like edge cases than something to change packages over. Stars also may be faster in some cases, but that depends on the task/function. There is a comparison between the two paradigms here, but unfortunately it uses raster instead of terra so a lot of the method names are wrong or missing.

5.2 Spatial Dependency and Regression

The most commonly used packages for spatial dependency analysis and spatial regression (spdep and spatialreg) both use simple features objects (from sf). Thankfully the st_as_sf() function works very well for transitioning from spatVectors to simple features, and if you are only working with vector data you can probably forgo the spatVectors altogether.

5.3 Where’s the data? geodata!

Another one of raster’s more useful features was getData(), a function that automated data downloading for a variety of online data sources. Unfortunately, getData() was poorly documented, to the point where using it required its own tutorial. In particular, because there was only one function for all of the data sources, it was always a guessing game as to which arguments were required for which data sources. It was even difficult to find a list of data sources available. It was not particularly well publicized either, to the point where people who used raster for years, did not know it existed.

These problems have now been solved by migrating the functionality of getData to its own package: geodata. Every data source (listed below) has one or more functions, each of which is well documented.

One notable change is that you must specify where the data should be downloaded. This can be done either in the function call itself or for a given R session using the function geodata_path.

• Marine data from Bio-ORACLE
• Current and future climate data from WorldClim
• Political boundaries and adminstrative data from GADM
• Elevation data from SRTM and GTOP30 at high latitudes
• Crop distribution and yield data from Monfreda et al. 2008, SPAM, ESA Worldcover, GLAD, and QED (for Africa)
• Crop calendars from Sacks et al. 2010
• Landcover data from ESA Worldcover
• Last of the Wild Human Footprint map from NASA’s Socioeconomic Data and Applications Center (SEDAC)
• Open Street Map
• Human Population density from SEDAC
• Soils data from ISRIC, iSDA
• Species occurrence data from the Global Biodiversity Information Facility
• Travel times to cities and ports from Nelson et al. 2019

5.4 So about C++…

As mentioned previously, spatRasters, spatVectors, and spatExtents (spat* objects) are all implemented in C++ instead of directly in R. This greatly improves processing speeds, as demonstrated above, but it does come with some costs. For most people, the only change will be that you can no longer recover spat* objects in from your workspace .RData files. This problem is easily solved by writing the data to a disk using writeRaster, which is considered best practices anyway.

The other issue is only relevant to people who use computing clusters. Because of the way terra classes are implemented (using a C++ pointer), they cannot be passed directly to a computing cluster. They first need to be packaged up using the wrap function (documented here) which creates a Packed* version of the class. This can be transferred to the cluster and then converted back using unwrap.