-
Notifications
You must be signed in to change notification settings - Fork 89
/
sp-raster.qmd
133 lines (116 loc) · 6.17 KB
/
sp-raster.qmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
# 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**. These users need to migrate existing code and/or
existing R packages depending on these packages.
Packages **maptools**, **rgdal**, and **rgeos** retired in
2023. Retirement means that maintenance halts, and that as a
consequence the packages has been 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 have refrained from seeking new maintainers
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.
With retirement of **rgeos** and **rgdal**, existing ties that package **sp**
had to **rgdal** and **rgeos** has been replaced by ties to
package **sf**. This involved for example validation of coordinate reference
system identifiers, and checking whether rings are holes or exterior
rings. Chosen **maptools** functions were 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>.
## Packages 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 and "terra"_, 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.