sp-raster.qmd

# Older R Spatial Packages {#sec-older}

## Retiring **rgdal** and **rgeos** {#sec-retire}
\index{rgdal!retirement}
\index{rgeos!retirement}

R users who have been around a bit longer, in particular before
packages like **sf** and **stars** were developed, may be more familiar
with older packages like **maptools**, **sp**, **rgeos**, and **rgdal**. A
fair question is whether they should migrate existing code and/or
existing R packages depending on these packages.  The answer is: yes.

Packages **maptools**, **rgdal**, and **rgeos** will retire during
2023. Retirement means that maintenance will halt, and that as a
consequence the packages will be archived on CRAN. The source code
repositories on R-Forge will remain as long as R-Forge does itself.
One reason for retirement is that their maintainer has retired,
a more important reason that their role has been superseded by the newer packages.
We hold it most unlikely that a new maintainer will take over the 
R-Forge repositories, in part because much of the code of these packages 
has gradually evolved along with developments in the GEOS,
GDAL, and PROJ libraries, and contains numerous constructs that
are outdated and make it forbidding to read.

Before **rgeos** and **rgdal** retire, existing ties that package **sp**
has to **rgdal** and **rgeos** can and will be replaced by ties to
package **sf**. This involves for example validation of coordinate reference
system identifiers, and checking whether rings are holes or exterior
rings. Chosen **maptools** functions may also be moved to **sp**.

## Links and differences between sf and sp
\index{sp!differences from sf}

There are a number of differences between **sf** and **sp**. The most
notable is that **sp** classes are formal, S4 classes where **sf** uses
the (more) informal S3 class hierarchy. **sf** objects are derived from
data.frames or tibbles and because of that are more readily interfaceable
with much of the existing R ecosystem, especially with the tidyverse
package family. `sf` objects keep geometry in a list-column, meaning
that a geometry is _always_ a list element. Package **sp** used data
structures much less strictly, and for instance all coordinates of
`SpatialPoints` or `SpatialPixels` are kept in matrices, which is
much more performant for certain problems but is not possible with 
a list-column. Conversion from an `sf` object `x` to its **sp**
equivalent is done by
```{r eval=FALSE}
library(sp)
y = as(x, "Spatial")
```
and the conversion the other way around is done by
```{r eval=FALSE}
x0 = st_as_sf(y)
```

There are some limitations to conversions like this:

* **sp** does not distinguish between `LINESTRING` and
`MULTILINESTRING` geometries, or between `POLYGON` or `MULTIPOLYGON`.
For example, a `LINESTRING` will after conversion to `sp` come back as a
`MULTILINESTRING`
* **sp** does not have a representation for `GEOMETRYCOLLECTION`
geometries, or `sf` objects with geometry types _not_ in the "big seven" (@sec-seven)
* `sf` or `sfc` objects of geometry type `GEOMETRY`, with mixed
geometry types, cannot be converted into `sp` objects
* attribute-geometry relationship attributes get lost when converting
  to **sp**
* `sf` objects with more than one geometry list-column will, when
converting to **sp**, lose their secondary list-column(s).


## Migration code and packages
\index{sf!migration from sp}

The wiki page of the GitHub site for **sf**, found at
<https://github.com/r-spatial/sf/wiki/Migrating> contains a list of
methods and functions in **rgeos**, **rgdal**, and **sp** and the
corresponding **sf** method or function. This may help converting
existing code or packages.

A simple approach to migrate code is when only `rgdal::readOGR` is
used to read `file`. As an alternative, one might use
```{r, eval = FALSE}
x = as(sf::read_sf("file"), "Spatial")
```
however possible arguments to `readOGR`, when used, would need more
care.
An effort by us is underway to convert all code of our earlier book
_Applied Spatial Data Analysis with R_ (with Virgilio Gómez-Rubio,
@asdar) to run entirely without **rgdal**, **rgeos**, and **maptools** and
where possible without **sp**. The scripts are found at
<https://github.com/rsbivand/sf_asdar2ed>.

## Package raster and terra
\index{raster}
\index{terra}

Package **raster** has been a workhorse package for analysing raster
data with R since 2010, and has since grown into a package for
"Geographic Data Analysis and Modeling" [@R-raster], indicating that
it is used for all kinds of spatial data. The **raster** package uses
**sp** objects for vector data, and **terra** to read and write data to
formats served by the GDAL library. Its successor package **terra**,
for "Spatial Data Analysis" [@R-terra], "is very similar to the
`raster` package; but [...] can do more, is easier to use, and
[...]  is faster". The **terra** package comes with its own classes
for vector data, but accepts many **sf** objects, with similar
restrictions as listed above for conversion to **sp**.  Package **terra**
has its own direct links to GDAL, GEOS, and PROJ, so, no longer needs
other packages for that. 

Raster maps, or stacks of them from package **raster** or **terra**
can be converted to `stars` objects using `st_as_stars()`. Package
**sf** contains an `st_as_sf()` method for `SpatVector` objects
from package **terra**. 

The online book _Spatial Data Science with R_, written by
Robert Hijmans and found at <https://rspatial.org/terra> details
the **terra** approach to spatial data analysis. Package **sf**
and **stars** and several other r-spatial packages discussed in
this book reside on the `r-spatial` GitHub organisation (note the
hyphen between `r` and `spatial`, which is absent on Hijmans'
organisation), which has a blog site, with links to this book,
found at <https://r-spatial.org/book>.

Packages **sf** and **stars** on one hand and **terra** on the other
have many goals in common, but try to reach them in slightly
different ways, emphasising different aspects of data analysis,
software engineering, and community management. Although this may
confuse some users, we believe that these differences enrich the
R package ecosystem, are beneficial to users, encourage diversity
and choice, and hopefully work as an encouragement for others to
continue trying out new ideas when using R for spatial data problems,
and to help carrying the R spatial flag.

{{< include ga.qmd >}}