improves indexes

01-introduction.Rmd

@@ -78,15 +78,15 @@ Further information on installing R on modern operating systems such as [Ubuntu
 Geocomputation is also more accessible because publicly accessible datasets are more widely available than ever before, as we will see in Chapter \@ref(read-write).
 Unlike early works in the field, all the work presented in this book is reproducible using code and example data supplied alongside the book, in R\index{R} packages such as **spData**, the installation of which is covered in Chapter \@ref(spatial-class).
 
-Geocomputation\index{geocomputation} is closely related to other terms including: Geographic Information Science (GIScience); Geomatics; Geoinformatics; Spatial Information Science; Geoinformation Engineering [@longley_geographic_2015]; and Spatial Data Science\index{Spatial Data Science} (SDS).
+Geocomputation\index{geocomputation} is closely related to other terms including: Geographic Information Science (GIScience); Geomatics; Geoinformatics; Spatial Information Science; Geoinformation Engineering [@longley_geographic_2015]; and Spatial Data Science\index{spatial data science}\index{geographical data science|see spatial data science} (SDS).
 Each term shares an emphasis on a 'scientific' (implying reproducible and falsifiable) approach influenced by GIS\index{GIS!definition}, although their origins and main fields of application differ.
 SDS, for example, emphasizes 'data science' skills and large datasets, while Geoinformatics tends to focus on data structures.
 But the overlaps between the terms are larger than the differences between them and we use geocomputation as a rough synonym encapsulating all of them:
 they all seek to use geographic data for applied scientific work.
 Unlike early users of the term, however, we do not seek to imply that there is any cohesive academic field called 'Geocomputation' (or 'GeoComputation' as Stan Openshaw called it).
 
 Geocomputation is a recent term but is influenced by old ideas.
-It can be seen as a part of Geography\index{Geography}, which has a 2000+ year history [@talbert_ancient_2014];
+It can be seen as a part of Geography\index{geography}, which has a 2000+ year history [@talbert_ancient_2014];
 and an extension of *Geographic Information Systems* (GIS\index{GIS}) [@neteler_open_2008], which emerged in the 1960s [@coppock_history_1991].
 
 Geography\index{geography} has played an important role in explaining and influencing humanity's relationship with the natural world long before the invention of the computer, however.
@@ -138,7 +138,7 @@ Furthermore, R facilitates access to other languages:
 the packages **Rcpp** and **reticulate** enable access to C++\index{C++} and Python\index{Python} code, for example.
 This means R can be used as a 'bridge' to a wide range of geospatial programs (see Section \@ref(software-for-geocomputation)).
 
-Another example showing R's flexibility and evolving geographic capabilities is interactive map making\index{map making!interactive}.
+Another example showing R's flexibility and evolving geographic capabilities is interactive map making\index{map making!interactive maps}.
 As we'll see in Chapter \@ref(adv-map), the statement that R has "limited interactive [plotting] facilities" [@bivand_applied_2013] is no longer true.
 This is demonstrated by the following code chunk, which creates Figure \@ref(fig:interactive) (the functions that generate the plot are covered in Section \@ref(interactive-maps)).
 
@@ -196,7 +196,7 @@ On the other hand, compiled languages such as C++\index{C++} and Java\index{Java
 
 C++\index{C++} provides the basis for many GIS packages such as [QGIS](https://www.qgis.org/en/site/)\index{QGIS}, [GRASS GIS](https://grass.osgeo.org/)\index{GRASS GIS} and [SAGA](https://saga-gis.sourceforge.io/)\index{SAGA} so it is a sensible starting point.
 Well-written C++\index{C++} is very fast, making it a good choice for performance-critical applications such as processing large geographic datasets, but is harder to learn than Python or R.
-C++\index{C++} has become more accessible with the **Rcpp** package, which provides a good 'way in' to C\index{C!language} programming for R users.
+C++\index{C++} has become more accessible with the **Rcpp** package, which provides a good 'way in' to C\index{C} programming for R users.
 Proficiency with such low-level languages opens the possibility of creating new, high-performance 'geoalgorithms' and a better understanding of how GIS software works (see Chapter \@ref(algorithms)).
 However, it is not necessary to learn C++\index{C++} to use R for geocomputation.
 

02-spatial-data.Rmd

@@ -151,7 +151,7 @@ This section introduces **sf** classes in preparation for subsequent chapters (C
 ### An introduction to simple features {#intro-sf}
 
 Simple features is an [open standard](http://portal.opengeospatial.org/files/?artifact_id=25355) developed and endorsed by the Open Geospatial Consortium (OGC), a not-for-profit organization whose activities we will revisit in a later chapter (in Section \@ref(file-formats)).
-\index{simple features |see {sf}}
+\index{simple features|see {sf}}
 Simple features is a hierarchical data model that represents a wide range of geometry types.
 Of 18 geometry types supported by the specification, only 7 are used in the vast majority of geographic research (see Figure \@ref(fig:sf-ogc));
 these core geometry types are fully supported by the R package **sf** [@pebesma_simple_2018].^[
@@ -194,7 +194,7 @@ vignette("sf6") # miscellaneous long-form documentation
 vignette("sf7") # spherical geometry operations
 ```
 
-As the first vignette explains, simple feature objects in R are stored in a data frame, with geographic data occupying a special column, usually named 'geom' or 'geometry'\index{geometry}.
+As the first vignette explains, simple feature objects in R are stored in a data frame, with geographic data occupying a special column, usually named 'geom' or 'geometry'\index{vector!geometry}.
 We will use the `world` dataset provided by **spData** [@R-spData], loaded at the beginning of this chapter, to show what `sf` objects are and how they work.
 `world` is an '`sf` data frame' containing spatial and attribute columns, the names of which are returned by the function `names()` (the last column in this example contains the geographic information).
 
@@ -935,7 +935,7 @@ On the other hand, the **raster** class system is popular and used by many other
 You can seamlessly translate between the two types of object to ensure backwards compatibility with older scripts and packages, for example, with the functions [`raster()`](https://rspatial.github.io/raster/reference/raster.html), [`stack()`](https://rspatial.github.io/raster/reference/stack.html), and `brick()` in the **raster** package (see the previous chapter for more on the evolution of R packages for working with geographic data).
 
 In addition to functions for raster data manipulation, **terra** provides many low-level functions that can form a foundation for developing new tools for working with raster datasets.
-\index{terra (package)|see {terra}}
+\index{terra (package)}
 **terra** also lets you work on large raster datasets that are too large to fit into the main memory.
 In this case, **terra** provides the possibility to divide the raster into smaller chunks, and processes these iteratively instead of loading the whole raster file into RAM.
 

03-attribute-operations.Rmd

@@ -657,7 +657,7 @@ The result is a raster object with 6 rows and 6 columns (specified by the `nrow`
 The `vals` argument sets the values that each cell contains: numeric data ranging from 1 to 36 in this case.
 
 \index{raster!manipulation}
-\index{categorical raster}
+\index{raster!categorical}
 Raster objects can also contain categorical values of class `logical` or `factor` variables in R.
 The following code creates the raster datasets shown in Figure \@ref(fig:cont-raster):
 
@@ -675,7 +675,7 @@ elev = rast(system.file("raster/elev.tif", package = "spData"))
 grain = rast(system.file("raster/grain.tif", package = "spData"))
 ```
 
-\index{categorical raster}
+\index{raster!categorical}
 \index{raster attribute table}
 The raster object stores the corresponding look-up table or "Raster Attribute Table" (RAT) as a list of data frames, which can be viewed with `cats(grain)` (see `?cats()` for more information).
 Each element of this list is a layer of the raster.

04-spatial-operations.Rmd

@@ -116,7 +116,7 @@ canterbury_height2 = nz_height[sel_logical, ]
 ```
 
 The above code chunk creates an object of class `sgbp` (a sparse geometry binary predicate, a list of length `x` in the spatial operation) and then converts it into a logical vector `sel_logical` (containing only `TRUE` and `FALSE` values, something that can also be used by **dplyr**'s filter function).
-\index{binary predicate|see also {topological relations}}
+\index{binary predicate|see {topological relations}}
 The function `lengths()` identifies which features in `nz_height` intersect with *any* objects in `y`.
 In this case 1 is the greatest possible value but for more complex operations one could use the method to subset only features that intersect with, for example, 2 or more features from the source object.
 
@@ -324,7 +324,7 @@ plot(p, add = TRUE)
 While the topological relations presented in the previous section are binary (a feature either intersects with another or does not) distance relations are continuous\index{distance relations}.
 The distance between two `sf` objects is calculated with `st_distance()`, which is also used behind the scenes in Section \@ref(non-overlapping-joins) for distance-based joins.
 This is illustrated in the code chunk below, which finds the distance between the highest point in New Zealand and the geographic centroid of the Canterbury region, created in Section \@ref(spatial-subsetting):
-\index{sf!distance relations}
+\index{vector!distance relations}
 
 ```{r 04-spatial-operations-31, warning=FALSE}
 nz_highest = nz_height |> slice_max(n = 1, order_by = elevation)

06-raster-vector.Rmd

@@ -26,7 +26,7 @@ The above concepts are demonstrated using data used in previous chapters to unde
 
 ## Raster cropping
 
-\index{raster cropping} 
+\index{raster!cropping} 
 Many geographic data projects involve integrating data from many different sources, such as remote sensing images (rasters) and administrative boundaries (vectors).
 Often the extent of input raster datasets is larger than the area of interest.
 In this case, raster **cropping** and **masking** are useful for unifying the spatial extent of input data.
@@ -54,7 +54,7 @@ This functionality is demonstrated in the command below, which generates Figure
 srtm_cropped = crop(srtm, zion)
 ```
 
-\index{raster masking} 
+\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)).
 
@@ -112,12 +112,12 @@ tmap_arrange(pz1, pz2, pz3, pz4, ncol = 4, asp = NA)
 
 ## Raster extraction
 
-\index{raster extraction} 
+\index{raster!extraction} 
 Raster extraction is the process of identifying and returning the values associated with a 'target' raster at specific locations, based on a (typically vector) geographic 'selector' object.
 The results depend on the type of selector used (points, lines or polygons) and arguments passed to the `terra::extract()` function.
 The reverse of raster extraction --- assigning raster cell values based on vector objects --- is rasterization, described in Section \@ref(rasterization).
 
-\index{raster extraction!points} 
+\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)). 
 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.
@@ -142,7 +142,7 @@ zion_points = cbind(zion_points, elevation)
 source("code/06-pointextr.R", print.eval = TRUE)
 ```
 
-\index{raster extraction!lines} 
+\index{raster!extraction lines} 
 Raster extraction also works with **line** selectors.
 Then, it extracts one value for each raster cell touched by a line.
 However, the line extraction approach is not recommended to obtain values along the transects as it is hard to get the correct distance between each pair of extracted raster values.
@@ -238,7 +238,7 @@ print(rast_poly_line, vp = viewport(layout.pos.row = 2, layout.pos.col = 1))
 print(plot_transect, vp = viewport(layout.pos.row = 2, layout.pos.col = 2))
 ```
 
-\index{raster extraction!polygons} 
+\index{raster!extraction polygons} 
 The final type of geographic vector object for raster extraction is **polygons**.
 Like lines, polygons tend to return many raster values per polygon.
 This is demonstrated in the command below, which results in a data frame with column names `ID` (the row number of the polygon) and `srtm` (associated elevation values):
@@ -312,7 +312,7 @@ rast_poly_nlcd = tm_shape(nlcd) +
 tmap_arrange(rast_poly_srtm, rast_poly_nlcd, ncol = 2)
 ```
 
-\index{raster extraction!exact fractions} 
+\index{raster!extraction fractions} 
 Although the **terra** package offers rapid extraction of raster values within polygons, `extract()` can still be a bottleneck when processing large polygon datasets.
 The **exactextractr** package offers a [significantly faster alternative](https://github.com/geocompx/geocompr/issues/813) for extracting pixel values through the `exact_extract()` function. 
 The `exact_extract()` function also computes, by default, the fraction of each raster cell overlapped by the polygon, which is more precise (see note below for details). 

07-reproj.Rmd

@@ -421,13 +421,13 @@ Additionally, you should not be attached just to one projection for every task.
 It is possible to use one projection for some part of the analysis, another projection for a different part, and even some other for visualization.
 Always try to pick the CRS that serves your goal best!
 
-When selecting **geographic CRSs**\index{geographic CRS}, the answer is often [WGS84](https://en.wikipedia.org/wiki/World_Geodetic_System#A_new_World_Geodetic_System:_WGS_84).
+When selecting **geographic CRSs**\index{CRS!geographic}, the answer is often [WGS84](https://en.wikipedia.org/wiki/World_Geodetic_System#A_new_World_Geodetic_System:_WGS_84).
 It is used not only for web mapping, but also because GPS datasets and thousands of raster and vector datasets are provided in this CRS by default.
 WGS84 is the most common CRS in the world, so it is worth knowing its EPSG code: 4326.^[
 Instead of `"EPSG:4326"`, you may also use `"OGC:CRS84"`. The former assumes that latitude is always ordered before longitude, while the latter is the standard representation used by GeoJSON, with coordinates ordered longitude before latitude.]
 This 'magic number' can be used to convert objects with unusual projected CRSs into something that is widely understood.
 
-What about when a **projected CRS**\index{projected CRS} is required?
+What about when a **projected CRS**\index{CRS!projected} is required?
 In some cases, it is not something that we are free to decide:
 "often the choice of projection is made by a public mapping agency" [@bivand_applied_2013].
 This means that when working with local data sources, it is likely preferable to work with the CRS in which the data was provided, to ensure compatibility, even if the official CRS is not the most accurate.
@@ -737,7 +737,7 @@ For instance, if we are interested in a density (points per grid cell or inhabit
 
 ## Custom map projections {#mapproj}
 
-\index{CRS!custom projections} 
+\index{CRS!custom} 
 Established CRSs captured by `AUTHORITY:CODE` identifiers such as `EPSG:4326` are well suited for many applications.
 However, it is desirable to use alternative projections or to create custom CRSs in some cases.
 Section \@ref(which-crs) mentioned reasons for using custom CRSs, and provided several possible approaches.

10-gis.Rmd

@@ -501,8 +501,8 @@ Our `saga` object contains connections to all of the available SAGA tools.
 It is organized as a list of libraries (groups of tools), and inside of a library it has a list of tools.
 We can access any tool with the `$` sign (remember to use TAB for autocompletion).
 
-The seeded region growing algorithm works\index{seeded region growing algorithm} in two main steps [@adams_seeded_1994;@bohner_image_2006].
-First, initial cells ("seeds") are generated by finding the cells with the smallest variance in local windows of a specified size.
+The seeded region growing algorithm works\index{segmentation!seeded region growing algorithm} in two main steps [@adams_seeded_1994;@bohner_image_2006].
+First, initial cells ("seeds") are generated by finding the cells with the smallest variance in local windows of a specified size\index{autocorrelation!spatial}.
 Second, the region growing algorithm is used to merge neighboring pixels of the seeds to create homogeneous areas.
 
 ```{r, eval=FALSE}
@@ -1024,15 +1024,15 @@ For more information about **sits** visit https://e-sensing.github.io/sitsbook/
 
 ### openEO
 
-OpenEO [@schramm_openeo_2021]\index{openEO} is an initiative to support interoperability among cloud services by defining a common language for processing the data. 
+OpenEO [@schramm_openeo_2021]\index{OpenEO} is an initiative to support interoperability among cloud services by defining a common language for processing the data. 
 The initial idea has been described in an [r-spatial.org blog post](https://r-spatial.org/2016/11/29/openeo.html) and aims at making it possible for users to change between cloud services easily with as little code changes as possible. 
 The [standardized processes](https://processes.openeo.org) use a multidimensional data cube model\index{data cube} as an interface to the data. 
 Implementations are available for eight different backends (see https://hub.openeo.org) to which users can connect with R, Python, JavaScript, QGIS, or a web editor and define (and chain) processes on collections. 
 Since the functionality and data availability differs among the backends, the **openeo** R package [@lahn_openeo_2021] dynamically loads available processes and collections from the connected backend. 
 Afterwards, users can load image collections, apply and chain processes, submit jobs, and explore and plot results. 
 
 The following code will connect to the [openEO platform backend](https://openeo.cloud/), request available datasets, processes, and output formats, define a process graph to compute a maximum NDVI image from Sentinel-2 data, and finally executes the graph after logging in to the backend. 
-The openEO\index{openEO} platform backend includes a free tier and registration is possible from existing institutional or internet platform accounts. 
+The openEO\index{OpenEO} platform backend includes a free tier and registration is possible from existing institutional or internet platform accounts. 
 
 ```{r 09-openeo-example, eval=FALSE}
 library(openeo)