Deploy commit: 1115 proofreading changes 3 (#1129)

* Be more specific and accurate: raster and vector datasets *used* in many fields

* as it -> , as it

* 3-d -> three-d*

* -0.1 -> $-0.1$

* (the Prime M...) -> (Prime M...)

* peninsular -> peninsula

* low level libraries -> low-level libraries

* Fix-up wording about importance of GDAL and friends

* Tweaks

* 2-d -> two-d

* Add missing comma

* in Sec -> Sec

* Remove hyperlink from the

* Time of writing,

* Update at the time of writing

* re-iterate -> reiterate

* CRSs abbreviation

* A spatial -> Spatial

* Shorten description of sticky

* CRSs

* this reason -> this reason,

* Neither has

* Fix grammar, mention border arg of plot()

* Basic maps

* A plot -> Plot

* Base plot limits

* Shift index entries

* 7 -> seven

* two-, three-, or four-dimensional space

* From scratch,

* Tweaks to 2.2.5

* Update hyperlink

* Examples, the

* Assorted typo fixes

* Assorted changes

* multilayered -> multi-layered and more

* the Zion -> Zion

* Mention fig:basic-new-raster-plot in the text

* multilayer -> multi-layer

* Tweaks to 2.4

* Spell-out UTM, finish c2

* Avoid superscript

* , but

* Italics

* Boolean

* 3 -> three

* Continent

* Complete fixes for c3

* Start on c4

* Fixes for c4

* Update 02-spatial-data.Rmd

Co-authored-by: Jakub Nowosad <Nowosad@users.noreply.github.com>

* Assorted changes

* Assorted changes to c4

* Tweak NDVI bit

* Clarify na.rm argument in c4

* Fixes for c4

---------

Co-authored-by: Jakub Nowosad <Nowosad@users.noreply.github.com> f72e44e

Author: Robinlovelace

01-introduction.md

@@ -228,7 +228,7 @@ There are many ways to handle geographic data in R, with dozens of packages\inde
 An overview of R's spatial ecosystem can be found in the CRAN\index{CRAN} Task View on the Analysis of Spatial Data
 (see https://cran.r-project.org/view=Spatial).
 ]
-In this book we endeavor to teach the state-of-the-art in the field whilst ensuring that the methods are future-proof.
+In this book, we endeavor to teach the state-of-the-art in the field whilst ensuring that the methods are future-proof.
 Like many areas of software development, R's spatial ecosystem is rapidly evolving (Figure \@ref(fig:cranlogs)).
 Because R is open source, these developments can easily build on previous work, by 'standing on the shoulders of giants', as Isaac Newton put it in [1675](https://digitallibrary.hsp.org/index.php/Detail/objects/9792).
 This approach is advantageous because it encourages collaboration and avoids 'reinventing the wheel'.
@@ -292,7 +292,7 @@ R's spatial capabilities have evolved substantially since then, but they still b
 Interfaces to GDAL\index{GDAL} and PROJ\index{PROJ}, for example, still power R's high-performance geographic data I/O and CRS\index{CRS} transformation capabilities, as outlined in Chapters \@ref(reproj-geo-data) and \@ref(read-write), respectively.
 
 **rgdal**, released in 2003, provided GDAL\index{GDAL} bindings for R which greatly enhanced its ability to import data from previously unavailable geographic data formats.
-The initial release supported only raster drivers, but subsequent enhancements provided support for coordinate reference systems (via the PROJ library), reprojections and import of vector file formats.
+The initial release supported only raster drivers, but subsequent enhancements provided support for CRSs (via the PROJ library), reprojections and import of vector file formats.
 Many of these additional capabilities were developed by Barry Rowlingson and released in the **rgdal** codebase in 2006, as described in @rowlingson_rasp:_2003 and the [R-help](https://stat.ethz.ch/pipermail/r-help/2003-January/028413.html) email list.
 
 The **sp** package, released in 2005, was a significant advancement in R's spatial capabilities.
@@ -341,7 +341,7 @@ Additional ways of representing and working with geographic data in R since 2018
 \index{lidR (package)}
 
 Such developments have been motivated by the emergence of new technologies, standards and software outside of the R environment [@bivand_progress_2021].
-Major updates to the PROJ library\index{PROJ} beginning in 2018 forced the replacement of 'proj-string' representations of coordinate reference systems with 'Well Known Text', as described in Section \@ref(crs-intro) and Chapter \@ref(reproj-geo-data).
+Major updates to the PROJ library\index{PROJ} beginning in 2018 forced the replacement of 'proj-string' representations of CRSs with 'Well Known Text', as described in Section \@ref(crs-intro) and Chapter \@ref(reproj-geo-data).
 
 \index{rayshader (package)}
 Since the publication of the first version of Geocomputation with R in 2018, several packages for spatial data visualization have been developed and improved.

02-spatial-data.md

@@ -39,7 +39,7 @@ Importantly it also shows how to 'polygonize' rasters and 'rasterize' vector dat
 ## Geometric operations on vector data {#geo-vec}
 
 This section is about operations that in some way change the geometry of vector (`sf`) objects.
-It is more advanced than the spatial data operations presented in the previous chapter (in Section \@ref(spatial-vec)), because here we drill down into the geometry:
+It is more advanced than the spatial data operations presented in the previous chapter (Section \@ref(spatial-vec)), because here we drill down into the geometry:
 the functions discussed in this section work on objects of class `sfc` in addition to objects of class `sf`.
 
 ### Simplification
@@ -802,7 +802,7 @@ The main resampling methods include:
 - Nearest neighbor: assigns the value of the nearest cell of the original raster to the cell of the target one. This is a fast simple technique that is usually suitable for resampling categorical rasters.
 - Bilinear interpolation: assigns a weighted average of the four nearest cells from the original raster to the cell of the target one (Figure \@ref(fig:bilinear)). This is the fastest method that is appropriate for continuous rasters.
 - Cubic interpolation: uses values of the 16 nearest cells of the original raster to determine the output cell value, applying third-order polynomial functions. Used for continuous rasters and results in a smoother surface compared to bilinear interpolation but is computationally more demanding.
-- Cubic spline interpolation: also uses values of the 16 nearest cells of the original raster to determine the output cell value but applies cubic splines (piece-wise third-order polynomial functions). Used for continuous rasters.
+- Cubic spline interpolation: also uses values of the 16 nearest cells of the original raster to determine the output cell value, but applies cubic splines (piece-wise third-order polynomial functions). Used for continuous rasters.
 - Lanczos windowed sinc resampling: uses values of the 36 nearest cells of the original raster to determine the output cell value. Used for continuous rasters.^[
 More detailed explanation of this method can be found at https://gis.stackexchange.com/a/14361/20955.
 ]

03-attribute-operations.md

@@ -57,7 +57,7 @@ srtm_cropped = crop(srtm, zion)
 
 \index{raster!masking} 
 Related to `crop()` is the **terra** function `mask()`, which sets values outside of the bounds of the object passed to its second argument to `NA`.
-The following command therefore masks every cell outside of the Zion National Park boundaries (Figure \@ref(fig:cropmask)(C)).
+The following command therefore masks every cell outside of Zion National Park boundaries (Figure \@ref(fig:cropmask)(C)).
 
 
 ``` r
@@ -95,7 +95,7 @@ The reverse of raster extraction --- assigning raster cell values based on vecto
 
 \index{raster!extraction points} 
 The basic example is of extracting the value of a raster cell at specific **points**.
-For this purpose, we will use `zion_points`, which contain a sample of 30 locations within the Zion National Park (Figure \@ref(fig:pointextr)). 
+For this purpose, we will use `zion_points`, which contain a sample of 30 locations within Zion National Park (Figure \@ref(fig:pointextr)). 
 The following command extracts elevation values from `srtm` and creates a data frame with points' IDs (one value per vector's row) and related `srtm` values for each point.
 Now, we can add the resulting object to our `zion_points` dataset with the `cbind()` function: 
 

04-spatial-operations.md

@@ -24,7 +24,7 @@ It demonstrates how to set and *transform* geographic data from one CRS to anoth
 \index{CRS!projected} 
 
 In many projects there is no need to worry about, let alone convert between, different CRSs.
-Nonetheless, it is important to know if your data is in a projected or geographic coordinate reference system, and the consequences of this for geometry operations.
+Nonetheless, it is important to know if your data is in a projected or geographic CRS, and the consequences of this for geometry operations.
 If you know this information, CRSs should *just work* behind the scenes: people often suddenly need to learn about CRSs when things go wrong.
 Having a clearly defined CRS that all project data is in, and understanding how and why to use different CRSs, can ensure that things don't go wrong.
 Furthermore, learning about coordinate systems will deepen your knowledge of geographic datasets and how to use them effectively.
@@ -500,7 +500,7 @@ london2 = st_transform(london_geo, "EPSG:27700")
 
 Now that a transformed version of `london` has been created, using the **sf** function `st_transform()`, the distance between the two representations of London can be found.^[
 An alternative to `st_transform()` is `st_transform_proj()` from the **lwgeom**, which enables transformations and which bypasses GDAL and can support projections not supported by GDAL.
-However, at the time of writing (2022) we could not find any projections supported by `st_transform_proj()` but not supported by `st_transform()`.
+However, at the time of writing (2024) we could not find any projections supported by `st_transform_proj()` but not supported by `st_transform()`.
 ]
 It may come as a surprise that `london` and `london2` are over 2 km apart!^[
 The difference in location between the two points is not due to imperfections in the transforming operation (which is in fact very accurate) but the low precision of the manually-created coordinates that created `london` and `london_proj`.

05-geometry-operations.md

@@ -386,7 +386,7 @@ It is fast and flexible, but it may be worth looking at other packages such as *
 ### Raster data {#raster-data-read}
 
 \index{raster!data input}
-Similar to vector data, raster data comes in many file formats with some supporting multilayer files.
+Similar to vector data, raster data comes in many file formats with some supporting multi-layerfiles.
 **terra**'s `rast()` command reads in a single layer when a file with just one layer is provided.
 
 
@@ -395,7 +395,7 @@ raster_filepath = system.file("raster/srtm.tif", package = "spDataLarge")
 single_layer = rast(raster_filepath)
 ```
 
-It also works in case you want to read a multilayer file.
+It also works in case you want to read a multi-layerfile.
 
 
 ``` r
@@ -680,7 +680,7 @@ usa_sf = ne_countries(country = "United States of America", returnclass = "sf")
 Country borders can be also accessed with other packages, such as **geodata**, **giscoR**, or **rgeoboundaries**.
 
 A second example downloads a series of rasters containing global monthly precipitation sums with spatial resolution of 10 minutes (~18.5 km at the equator) using the **geodata** package [@R-geodata].
-The result is a multilayer object of class `SpatRaster`.
+The result is a multi-layerobject of class `SpatRaster`.
 
 
 ``` r
@@ -799,7 +799,7 @@ Map image representations, such as tiles, can be accessed with the Web Map Servi
 Metadata is also covered by means of the Catalogue Service for the Web (CSW)\index{geographic web services!CSW}. 
 Finally, standard processing is handled through the Web Processing Service (WPS)\index{geographic web services!WPS} or the the Web Coverage Processing Service (WCPS)\index{geographic web services!WCPS}.
 
-Various open-source projects have adopted these protocols, such as [GeoServer](https://geoserver.org/) and [MapServer](https://mapserver.org/) for data handling, or [GeoNetwork](https://geonetwork-opensource.org/) and [PyCSW](https://pycsw.org/) for metadata handling, leading to standardization of queries. 
+Various open-source projects have adopted these protocols, such as [GeoServer](https://geoserver.org/) and [MapServer](https://mapserver.org/) for data-handling, or [GeoNetwork](https://geonetwork-opensource.org/) and [PyCSW](https://pycsw.org/) for metadata-handling, leading to standardization of queries. 
 Integrated tools for Spatial Data Infrastructures (SDI), such as [GeoNode](https://geonode.org/), [GeOrchestra](https://www.georchestra.org/) or [Examind](https://www.examind.com/) have also adopted these standard webservices, either directly or by using previously mentioned open-source tools.
 
 Like other web APIs, OWS APIs use a 'base URL', an 'endpoint' and 'URL query arguments' following a `?` to request data (see the [`best-practices-api-packages`](https://httr.r-lib.org/articles/api-packages.html) vignette in the **httr** package).

06-raster-vector.md

@@ -307,8 +307,8 @@ tm_shape(nz) + tm_polygons(fill = "Median_income",
 ```
 
 <div class="figure" style="text-align: center">
-<img src="figures/tmpal-1.png" alt="Illustration of color settings. The results show (from left to right): default settings, manual breaks, n breaks, and the impact of changing the palette." width="100%" />
-<p class="caption">(\#fig:tmpal)Illustration of color settings. The results show (from left to right): default settings, manual breaks, n breaks, and the impact of changing the palette.</p>
+<img src="figures/tmpal-1.png" alt="Color settings. The results show (from left to right): default settings, manual breaks, n breaks, and the impact of changing the palette." width="100%" />
+<p class="caption">(\#fig:tmpal)Color settings. The results show (from left to right): default settings, manual breaks, n breaks, and the impact of changing the palette.</p>
 </div>
 
 \BeginKnitrBlock{rmdnote}<div class="rmdnote">All of the above arguments (`breaks`, `n`, and `values`) also work for other types of visual variables.

07-reproj.md

@@ -4,7 +4,7 @@
 
 ## Prerequisites {-}
 
-This chapter has minimal software prerequisites as it primarily uses base R.
+This chapter has minimal software prerequisites, as it primarily uses base R.
 Only, the **sf**\index{sf} package is used to check the results of an algorithm we will develop to calculate the area of polygons.
 In terms of prior knowledge, this chapter assumes you have an understanding of the geographic classes introduced in Chapter \@ref(spatial-class) and how they can be used to represent a wide range of input file formats (see Chapter \@ref(read-write)).
 
@@ -192,8 +192,8 @@ C1 = (T1[1,] + T1[2,] + T1[3,]) / 3
 
 
 <div class="figure" style="text-align: center">
-<img src="figures/polymat-1.png" alt="Illustration of polygon centroid calculation problem." width="100%" />
-<p class="caption">(\#fig:polymat)Illustration of polygon centroid calculation problem.</p>
+<img src="figures/polymat-1.png" alt="Polygon centroid calculation problem." width="100%" />
+<p class="caption">(\#fig:polymat)Polygon centroid calculation problem.</p>
 </div>
 
 Step 3 is to find the area of each triangle, so a *weighted mean* accounting for the disproportionate impact of large triangles is accounted for. 
@@ -275,7 +275,7 @@ Algorithm\index{algorithm} development is hard.
 This should be apparent from the amount of work that has gone into developing a centroid\index{centroid} algorithm\index{algorithm} in base R\index{R} that is just one, rather inefficient, approach to the problem with limited real-world applications (convex polygons are uncommon in practice).
 The experience should lead to an appreciation of low-level geographic libraries such as GEOS\index{GEOS} and CGAL\index{CGAL} (the Computational Geometry Algorithms Library) which not only run fast but work on a wide range of input geometry types.
 A great advantage of the open source nature of such libraries is that their source code\index{source code} is readily available for study, comprehension and (for those with the skills and confidence) modification.^[
-The CGAL\index{CGAL} function `CGAL::centroid()` is in fact composed of 7 sub-functions as described at https://doc.cgal.org/latest/Kernel_23/group__centroid__grp.html allowing it to work on a wide range of input data types, whereas the solution we created works only on a very specific input data type.
+The CGAL\index{CGAL} function `CGAL::centroid()` is in fact composed of seven sub-functions as described at https://doc.cgal.org/latest/Kernel_23/group__centroid__grp.html allowing it to work on a wide range of input data types, whereas the solution we created works only on a very specific input data type.
 The source code underlying GEOS\index{GEOS} function `Centroid::getCentroid()` can be found at https://github.com/libgeos/geos/search?q=getCentroid.
 ]