# 1 Introduction

This book is about harnessing the power of modern computers to do things with geographic data. It teaches a range of spatial skills, including: reading, writing and manipulating geographic data; making static and interactive maps; applying geocomputation to solve real-world problems; and modeling geographic phenomena. By demonstrating how various spatial operations can be linked, in reproducible ‘code chunks’ that intersperse the prose, the book also teaches a transparent and thus scientific workflow. Learning how to use the wealth of geospatial tools available from the R command line can be exciting but creating new ones can be truly liberating, by removing constraints on your creativity imposed by software. By the end of the book you should be able to create new tools for geocomputation in the form of shareable R scripts and functions.

Over the last few decades free and open source software for geospatial data (‘FOSS4G’) has progressed at an astonishing rate (see foss4g.org). Thanks to FOSS4G and the wider open source movement geospatial analysis is no longer the preserve of those with expensive hardware and software: anyone can now download high performance spatial libraries on their computer. Open source Geographic Information Systems (GIS) such as QGIS (see qgis.org) have greatly reduced the ‘barrier to entry’. Furthermore many GIS programs provide a command-line interface, either from the system command line (the Unix terminal on Linux and Mac or Windows Powershell) via application programming interfaces (APIs) (see Chapter 10) and console windows (such as the Python Console in QGIS) to supplement the main graphical user interface (GUI). Still, many GIS programs and teaching materials focus on the GUI, which can have the unintended consequence of discouraging reproducibility (see Table 1.1). Motivated by the importance of reproducibility for scientific research and other advantages of typing commands rather than pointing and clicking, this book focuses on R’s Command Line Interface (CLI) for GIS operations. The reproducible and ‘computational’ workflows enabled by R’s CLI can also help unleash its statistical capabilities on geographic data (see section 1.2).

Table 1.1: Differences in emphasis between software packages (Graphical User Interface (GUI) of Geographic Information Systems (GIS) and R).
Attribute Desktop GIS (GUI) R
Home disciplines Geography Computing, Statistics
Software focus Graphical User Interface Command line
Reproducibility Minimal Maximal

Reproducibility is a major advantage of command-line interfaces, but what does it mean in practice? We define it as follows:

A process is reproducible only if the same results can be generated by others using publicly accessible code.

This may sound simple and easy to achieve (which it is if you carefully maintain your R code in script files) but has profound implications for teaching and the scientific process (Pebesma, Nüst, and Bivand 2012).

A major aim of this book is to make geographic data analysis more accessible as part of a reproducible workflow. R is a flexible language that allows access to many spatial software libraries (see section 1.2). Before going into the details of the software, however, it is worth taking a step back and thinking about what we mean by geocomputation.

## 1.1 What is geocomputation?

Geocomputation is a relatively young field with a ~30 year history, dating back to the first conference on the subject in 1996.1 What distinguishes geocomputation from the older quantitative geography, is its emphasis on “creative and experimental” GIS applications (Longley et al. 1998). Additionally, it is also about developing new, research-driven methods (Openshaw and Abrahart 2000):

GeoComputation is about using the various different types of geodata and about developing relevant geo-tools within the overall context of a ‘scientific’ approach.

This book aims to go beyond teaching methods and code: by the end of it you should be able use your geocomputational skills, to do “practical work that is beneficial or useful” (Openshaw and Abrahart 2000).

Our approach differs from early adopters such as Stan Openshaw in one important way, however. At the turn of the 21st Century it was unrealistic to expect readers to be able to reproduce code examples, due to barriers preventing access to the necessary hardware, software and data. Fast-forward two decades and things have progressed rapidly. Anyone with access to a laptop with ~4GB RAM can realistically expect to be able to install and run software for geocompuation on publicly accessible datasets, which are more widely available than ever before (as we will see in Chapter 6).2 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 packages such as spData, the installation of which is covered in Chapter 2.

Geocomputation is closely related to other terms including Geographic Information Science (GIScience), Geomatics, Geoinformatics, Spatial Information Science, Geoinformation Engineering (Longley et al. 2015), and the fledgling Geographic Data Science (GDS). Each term shares an emphasis on a ‘scientific’ (implying reproducible and falsifiable) approach building on GIS software, although their origins and main fields of application differ. GDS, for example, emphasizes ‘data science’ skills and large datasets, and can be used as a synonym for Geocomputation. A distinguishing feature of Geocomputation, as advocated in this book, is its focus on applied geographic analysis and the application and development of new methods.

Geocomputation is young, but it builds on older fields. It can be seen as a part of Geography, which has a 2000+ year history (Talbert 2014); and an extension of Geographic Information Systems (GIS) (Neteler and Mitasova 2008), which emerged in the 1960s (Coppock and Rhind 1991).

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. Alexander von Humboldt’s travels to South America in the early 1800s illustrates this role: not only did the resulting observations lay the foundations for the traditions of physical and plant geography, they also paved the way towards policies to protect the natural world (Wulf 2015). This book aims to contribute to the ‘Geographic Tradition’ (Livingstone 1992) by harnessing the power of modern computers and open source software.

The book’s links to older disciplines were reflected in suggested titles for the book: Geography with R and R for GIS. Each has advantages. The former conveys the message that it comprises much more than just spatial data: non-spatial attribute data are inevitably interwoven with geometry data, and Geography is about more than where something is on the map. The latter communicates that this is a book about using R as a GIS, to perform spatial operations on geographic data (Bivand, Pebesma, and Gómez-Rubio 2013). However, the term GIS conveys some connotations (see Table 1.1) which simply fail to communicate one of R’s greatest strengths: its console-based ability to seamlessly switch between geographic and non-geographic data processing, modeling and visualization tasks. By contrast, the term geocomputation implies reproducible and creative programming. Of course, (geocomputational) algorithms are powerful tools that can become highly complex. However, all algorithms are composed of smaller parts. By teaching you its foundations and underlying structure, we aim to empower you to create your own innovative solutions to geographic data problems.

## 1.2 Why Geocomputation with R?

Early geographers used a variety of tools including barometers, compasses and sextants to advance knowledge about the world (Wulf 2015). It was only with the invention of the marine chronometer in 1761 that it became possible to calculate longitude at sea, enabling ships to take more direct routes and accurate maps of the world.

Nowadays such lack of geographic data is hard to imagine. Every smartphone has a global positioning (GPS) receiver and a multitude of sensors on devides ranging from satellites and semi-autonomous vehicles to citizen scientists incessantly measure every part of the world. The rate of data produced is overwhelming. An autonomous vehicle, for example, can generate 100 GB of data per day (The Economist 2016). Remote sensing data from satellites has become too large to analyze the corresponding data with a single computer, leading to initiatives such as OpenEO.

This ‘geodata revolution’ drives demand for high performance computer hardware and efficent, scalable software to handle and extract signal from the noise to understand and perhaps change the world. ‘Geodatabases’ enable storage and generation of manageble subsets from the vast geographic data stores, making interfaces for gaining knowledge from them vital tools for the future. R is one such tool, with advanced analysis, modelling and visualization capabilities. In this context the focus of the book is not on the language itself (see Wickham 2014). Instead we use R as a ‘tool for the trade’ for understanding the world, similar to Humboldt’s use of tools to gain a deep understanding of nature in all its complexity and interconnections Wulf (2015). Although programming can seem like a reductionist activity, the aim is to teach Geocomputation with R not only for fun, but for understanding the world.

R is a multi-platform, open source language and environment for statistical computing and graphics (r-project.org/). With a wide range of packages R also supports advanced geospatial statistics, modeling and visualization.3 At its core R is an object-oriented, functional programming language (Wickham 2014), and was specifically designed as an interactive interface to other software (Chambers 2016). The latter also includes many ‘bridges’ to a treasure trove of GIS software, ‘geolibraries’ and functions (see Chapter 10). It is thus ideal for quickly creating ‘geo-tools’, without needing to master lower level languages (compared to R) such as C, FORTRAN or Java (see section 1.3). This can feel like breaking free from the metaphorical ‘glass ceiling’ imposed by GUI-based proprietary geographic information systems (see Table 1.1 for a definition of GUI) without having to setup a complex IDE environment needed for some languages. What is more, advanced users might even extend R with the power of other languages (e.g., C++ through Rcpp or Python through reticulate; see also section 1.3).

An example showing R’s flexibility and evolving geographic capabilities is leaflet (Cheng, Karambelkar, and Xie 2018). We’ll see in Chapter 9 how this interactive mapping package has been extended: there are now many ways to generate interactive geographic data visualizations from the R command line. Thanks to these developments the statement that R has “limited interactive [plotting] facilities” (Bivand, Pebesma, and Gómez-Rubio 2013) is no longer true. This is demonstrated by the following code chunk (which creates Figure 1.1).

library(leaflet)
popup = c("Robin", "Jakub", "Jannes")
leaflet() %>%
lat = c(52, 53, 49),
popup = popup)

Figure 1.1: Where the authors are from. The basemap is a tiled image of the Earth at Night provided by NASA. Interact with the online version at robinlovelace.net/geocompr, for example by zooming-in and clicking on the popups.

It would have been difficult to produce Figure 1.1 using R a few years ago, let alone as an interactive map. This illustrates R’s flexibility and how, thanks to developments such as knitr and leaflet, it can be used as an interface to other software, a theme that will recur throughout this book. The use of R code, therefore, enables teaching geocomputation with reference to reproducible examples such as that provided in 1.1 rather than abstract concepts.

## 1.3 Software for geocomputation

R is a powerful language for geocomputation but there are many other options for spatial data analysis. Awareness of these will help situate R in the wider geospatial ecosystem, and identify when a different tool may be more appropriate for a specific task. Over time R developers have added various R interfaces (or ‘bridges’ as we call them in Chapter 13) to other software. Therefore knowing what else is out there can also be useful from an R-spatial perspective because a) there may already be a bridge to something that adds the functionality you need and b) if there’s not already a bridge there may be one on the horizon. With this motivation in mind this section briefly introduces the languages C++, Java and Python for geocomputation, with reference to R.

A natural choice for geocomputation would be C++ since major GIS packages (e.g., GDAL, QGIS, GRASS, SAGA, and even ArcGIS) often rely in great parts on it. This is because well-written C++ can be very fast, which makes it a good choice for performance-critical applications such as the processing of large spatial data. Usually, people find it harder to learn than Python or R. It is also likely that you have to invest a lot of time to code things that are readily available in R. Therefore, we would recommend to learn R, and subsequently to learn C++ through Rcpp if a need for performance optimization arises. Subsequently, you could even implement geoalgorithms you are missing from the most common desktop GIS with the help of Rcpp.4

Java is another important (and versatile) language used in GIScience. For example, the open-source desktop GIS gvSig, OpenJump and uDig are written in Java. There are also many open source add-on libraries available for Java, including GeoTools and the Java Topology Suite.5 Furthermore, many server-based applications use Java including among others Geoserver/Geonode, deegree and 52°North WPS.

Java’s object-oriented syntax is similar to that of C++ but its memory management, at least from a user’s perspective, is simpler and more robust. Java is rather unforgiving regarding class, object and variable declarations, which encourages well-designed programming structure, useful in large projects with thousands of lines of codes placed in numerous files. Following the write once, run anywhere principle, Java is platform-independent (which is unusual for a compiled language) and has excellent performance on large-scale systems. This makes Java a suitable language for complex architecture projects such as RStudio, the Integrated Development Environment (IDE) in which this book was written!

Java is less suitable for statistical modeling and visualization than Python or R. Although Java can be used for data science (Brzustowicz 2017), it has relatively few statistical libraries, especially compared with R. Furthermore Java is hard to use interactively. Interpreted languages (such as R and Python) are better suited for the type of interactive workflow used in many geographic workflows than compiled languages (such as Java and C++). Unlike Java (and most other languages) R has native support for data frames and matrices, making it especially well suited for (geographic) data analysis.

Python is the final language for geocomputation that deserves attention in this section. Like R, Python has gained recent popularity as a tool for data science although it is a more general purpose language, as explored in an article on ‘The Impressive Growth of R’ on the programming question and answer site StackOverflow. Both languages are object-oriented, and have many areas of overlap, leading to initiatives such as the reticulate package that facilitates access to Python from R and the Ursa Labs initiative to support portable libraries of benefit to the entire open source data science ecosystem.

In practice both languages have their strengths and to some extent which you use is less important than the domain of application and communication of results. Learning either will provide a head-start in learning the other. However, there are major advantages of R over Python for geocomputation which explains its prominence in this book. R has unparalleled support for statistics, including spatial statistics, with hundreds of packages (unmatched by Python) supporting thousands of statistical methods.

The major advantage of Python is that it is a general-purpose programming language. It is well-suited to many applications, including desktop software, computer games, websites and data science. R, by contrast, was originally developed for statistics.6 This also explains Python’s larger user base compared with R’s. Python is often the only shared language between different (geocomputation) communities, explaining why it has become the ‘glue’ that holds many GIS programs together. Many geoalgorithms, including those in QGIS and ArcMap, can be accessed from the Python command line, making it well-suited as a starter language for command-line GIS.7

For spatial statistics and predictive modeling, however, R is second-to-none. This does not mean you must chose either R or Python: Python supports most common statistical techniques (though R tends to support new developments in spatial statistics earlier) and many concepts learned from Python can be applied to the R world. Like R Python also supports spatial data analysis and manipulation with packages such as osgeo, Shapely, NumPy and PyGeoProcessing (Garrard 2016).

## 1.4 R’s spatial ecosystem

There are many ways to handle spatial data in R, with dozens of packages in the area.8 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. 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. This approach is advantageous because it encourages collaboration and avoids ‘reinventing the wheel’. The package sf (covered in Chapter 2), for example, builds on its predecessor sp.

A surge in development time (and interest) in ‘R-Geo’ has followed the award of a grant by the R Consortium for the development of support for Simple Features, an open-source standard and model to store and access vector geometries. This resulted in the sf package (covered in 2.1.1). Multiple places reflect the immense interest in sf. This is especially true for the R-sig-Geo Archives, a long-standing open access email list containing much R-spatial wisdom accumulated over the years. Many posts on the list now discuss sf and related packages, suggesting that R’s spatial software developers are using the package and, therefore, it is here to stay.

We even propose that the release of sf heralds a new era for spatial data analysis and geocomputation in R. This era9 clearly has the wind in its sails and is set to dominate future developments in R’s spatial ecosystem for years to come. So time invested in learning the ‘new ways’ of handling spatial data, and reading this book, is well spent!

It is noteworthy that shifts in the wider R community, as exemplified by the data processing package dplyr (released in 2014) influenced shifts in R’s spatial ecosystem. Alongside other packages that have a shared style and emphasis on ‘tidy data’ (including e.g., ggplot2), dplyr was placed in the tidyverse ‘metapackage’ in late 2016. The tidyverse approach, with its focus on long-form data and fast intuitively named functions, has become immensely popular. This has led to a demand for ‘tidy spatial data’ which has been partly met by sf and other approaches such as tabularaster. An obvious feature of the tidyverse is the tendency for packages to work in harmony. Although an equivalent geoverse is presently missing, there is an on-going discussion of harmonizing R’s many spatial packages10 and a growing number of actively developed packages which are designed to work in harmony with sf (Table 1.2).

Table 1.2: The top 5 most downloaded packages that depend on sf, in terms of average number of downloads per day over the previous month. As of 2018-05-17 there are 72 packages which import sf.
plotly 2145
raster 2008
spData 1776
leaflet 1217
spdep 1104

## 1.5 The history of R-spatial

There are many benefits of using recent spatial packages such as sf, but it also important to be aware of the history of R’s spatial capabilities: many functions, use-cases and teaching material are contained in older packages. These can still be useful today, provided you know where to look.

R’s spatial capabilities originated in early spatial packages in the S language (Bivand and Gebhardt 2000). The 1990s saw the development of numerous S scripts and a handful of packages for spatial statistics. R packages arose from these and by 2000 there were R packages for various spatial methods “point pattern analysis, geostatistics, exploratory spatial data analysis and spatial econometrics”, according to an article presented at GeoComputation2000 (Bivand and Neteler 2000) Some of these, notably spatial, sgeostat and splancs are still available on CRAN (Rowlingson and Diggle 1993, 2017; Venables and Ripley 2002; Majure and Gebhardt 2016).

A subsequent article in R News (the predecessor of The R Journal) contained an overview of spatial statistical software in R at the time, much of which was based on previous code written for S/S-PLUS (Ripley 2001). This overview described packages for spatial smoothing and interpolation, including akima and geoR (Akima and Gebhardt 2016; Jr and Diggle 2016), and point pattern analysis, including splancs (Rowlingson and Diggle 2017) and spatstat, which remains dominant in the field of spatial point pattern analysis (Baddeley, Rubak, and Turner 2015).

The following R News issue (Volume 1/3) put spatial packages in the spotlight again, with an introduction to splancs and a commentary on future prospects regarding spatial statistics (Bivand 2001). Additionally, the issue introduced two packages for testing spatial autocorrelation that eventually became part of spdep (Bivand 2017). Notably, the commentary mentions the need for standardization of spatial interfaces, efficient mechanisms for exchanging data with GIS, and handling of spatial metadata such as coordinate reference systems (CRS).

maptools (written by Nicholas Lewin-Koh; Bivand and Lewin-Koh 2017) is another important package from this time. Initially maptools just contained a wrapper around shapelib and permitted the reading of ESRI Shapefiles into geometry nested lists. The corresponding and nowadays obsolete S3 class called “Map” stored this list alongside an attribute data frame. The work on the “Map” class representation was nevertheless important since it directly fed into sp prior to its publication on CRAN.

In 2003, Bivand (2003) published an extended review of spatial packages. Around this time the development of R’s spatial capabilities increasingly supported interfaces to external libraries, especially to GDAL and PROJ.4. These interfaces facilitated geographic data I/O (meaning input output and covered in chapter 6) and CRS transformations, respectively. Bivand (2003) proposed a spatial data class system, including support for points, lines, polygons and grids based on GDAL’s support for a wide range of spatial data formats. All these ideas contributed to the packages rgdal and sp, which became the foundational packages for spatial data analysis with R (Bivand, Pebesma, and Gómez-Rubio 2013).

rgdal provided GDAL bindings for R which greatly extended R’s spatial capabilities in terms of access to previously unavailable spatial data formats. Initially, Tim Keitt released it in 2003 with support for raster drivers. But soon, rgdal also enabled storing information about coordinate reference system (building on top of the PROJ.4 library), allowed map projections, datum transformations and OGR vector reading. Many of these additional capabilities were thanks to Barry Rowlingson who folded them into the rgdal codebase in March 2006.11

sp, released in 2005, overcame R’s inability to distinguish spatial and non-spatial objects (Pebesma and Bivand 2005). It grew from a workshop before, and a session at the 2003 DSC conference in Vienna, gathering input from most interested package developers. At the same time, sourceforge was chosen for development collaboration (migrated to R-Forge five years later) and the R-sig-geo mailing list was started.

Prior to 2005, spatial coordinates were generally treated as any other number. This changed with sp as it provided generic classes and methods for spatial data. The sophisticated class system supported points, lines, polygons and grids, with and without attribute data.

Making use of the S4 class system, sp stores each piece of ‘spatially specific’ information (such as bounding box, coordinate reference system, attribute table) in slots, which are accessible via the @ symbol. For instance, sp-classes store attribute data in the data slot as a data.frame. This enables non-spatial data operations to work alongside spatial operations (see section 2.1.2). Additionally, sp implemented generic methods for spatial data types for well-known functions such as summary() and plot() .

In the following, sp classes rapidly became the go-to standard for spatial data in R, resulting in a proliferation of packages that depended on it from around 20 in 2008 and over 100 in 2013 (Bivand, Pebesma, and Gómez-Rubio 2013). Now more than 450 packages rely on sp, making it an important part of the R ecosystem.

Prominent R packages using sp include: gstat, for spatial and spatio-temporal geostatistics; geosphere, for spherical trigonometry; and adehabitat used for the analysis of habitat selection by animals (E. Pebesma and Graeler 2018; Calenge 2006; Hijmans 2016).

While rgdal and sp solved many spatial issues, R was still lacking geometry calculation abilities. Therefore, Colin Rundel started to develop a package that interfaces GEOS, an open-source geometry library, during a Google Summer of Coding project in 2010. The resulting rgeos package (first released in 2010; Bivand and Rundel 2017) brought geometry calculations to R by allowing functions and operators from the GEOS library to manipulate sp objects. Another limitation of sp was its limited support of raster data. The raster-package (first released in 2010; Hijmans 2017) overcame this by providing Raster* classes and functions for creating, reading and writing raster data. A key feature of raster is its ability to work with datasets that are too large to fit into the main memory (RAM), thereby overcoming one of R’s major limitations when working on large raster data.12

In parallel with or partly even preceding the development of spatial classes and methods came the support for R as an interface to dedicated GIS software. The GRASS package (R. S. Bivand 2000) and follow-on packages spgrass6 and rgrass7 (for GRASS GIS 6 and 7, respectively) were prominent examples in this direction (Bivand 2016b, 2016a). Other examples of bridges between R and GIS include RSAGA (Brenning, Bangs, and Becker 2018, first published in 2008), ArcGIS (A. Brenning 2012a, first published in 2008), and RQGIS (Muenchow, Schratz, and Brenning 2017, first published in 2016). Chapter 10 will give a thorough introduction to open-source R/GIS bridges.

Map making was not a focus of R’s early spatial capabilities. But soon sp provided methods for advanced map making using both the base and lattice plotting system. Despite this, a demand for the layered grammar of graphics was growing especially after the release of ggplot2 in 2007. ggmap extended ggplot2’s spatial capabilities (Kahle and Wickham 2013). However, its main purpose was the easy access of several APIs to automatically download map tiles (among others, Google Maps and OpenStreetmap) and subsequent plotting of these as a basemap. Though ggmap facilitated map-making with ggplot2, one main limitation remained. To make spatial data work with the ggplot2 system, one needed to fortify spatial objects. Basically, this means, you need to combine the coordinates and attribute slots of a spatial class object into one data frame. While this works well in the case of points, it duplicates the same information over and over again in the case of polygons, since each coordinate (vertex) of a polygon receives the attribute data of the polygon. This is especially disadvantageous if you need to deal with tens of thousands of polygons. With the introduction of simple features to R this limitation disappears, and it seems likely that this will make ggplot2 the standard tool for the visualization of vector data. This might be different regarding the visualization of raster data. Raster visualization methods received a boost with the release of rasterVis (Lamigueiro 2014) which builds on top of the lattice system. More recently, new packages aim at easing the creation of complex, high-quality maps with minimal code. The tmap package (released in 2014) might serve as an archetype for this kind of development (Tennekes 2018a). It facilitates the user-friendly creation of thematic maps with an intuitive command-line interface (see also mapmisc) . tmap is a sophisticated yet user friendly mapping package which works in harmony with the leaflet package (released in 2015) for interactive map making (Cheng, Karambelkar, and Xie 2018). Similarly, the mapview package builds also on top of leaflet (Appelhans et al. 2018) for interactive mapping based on sp or sf objects. mapview allows the access of a wide range of background maps, scale bars and more.

However, it is noteworthy that among all the recent developments described above, the support for simple features (sf; E. Pebesma 2018) has been without doubt the most important evolution in R’s spatial ecosystem. Naturally, this is the reason why we will describe sf in detail in Chapter 2.

## 1.6 Exercises

1. Think about the terms ‘GIS’, ‘GDS’ and ‘Geocomputation’ described above. Which is your favorite, and why?

2. Provide three reasons for using a scriptable language such as R for geocomputation instead of using an established GIS program such as QGIS.

3. Name two advantages and two disadvantages of using mature packages compared with ‘cutting edge’ packages for spatial data (for example sp vs sf).

### References

Pebesma, Edzer, Daniel Nüst, and Roger Bivand. 2012. “The R Software Environment in Reproducible Geoscientific Research.” Eos, Transactions American Geophysical Union 93 (16): 163–63. https://doi.org/10.1029/2012EO160003.

Longley, Paul A., Sue M. Brooks, Rachael McDonnell, and Bill MacMillan, eds. 1998. Geocomputation: A Primer. 1 edition. Chichester, Eng. ; New York: Wiley.

Openshaw, Stan, and Robert J. Abrahart, eds. 2000. Geocomputation. 1 edition. London ; New York: CRC Press.

Longley, Paul, Michael Goodchild, David Maguire, and David Rhind. 2015. Geographic Information Science & Systems. Fourth edition. Hoboken, NJ: Wiley.

Talbert, Richard J. A. 2014. Ancient Perspectives: Maps and Their Place in Mesopotamia, Egypt, Greece, and Rome. University of Chicago Press.

Neteler, Markus, and Helena Mitasova. 2008. Open Source GIS: A GRASS GIS Approach. 3. ed. New York, NY: Springer.

Coppock, J Terry, and David W Rhind. 1991. “The History of GIS.” Geographical Information Systems: Principles and Applications, Vol. 1. 1 (1): 21–43.

Wulf, Andrea. 2015. The Invention of Nature: Alexander von Humboldt’s New World. First American Edition. New York: Alfred A. Knopf.

Livingstone, David N. 1992. The Geographical Tradition: Episodes in the History of a Contested Enterprise. Oxford, UK ; Cambridge, USA: John Wiley & Sons Ltd.

Bivand, Roger S., Edzer Pebesma, and Virgilio Gómez-Rubio. 2013. Applied Spatial Data Analysis with R. 2nd ed. 2013 edition. New York: Springer.

The Economist. 2016. “The Autonomous Car’s Reality Check.” The Economist.

Chambers, John M. 2016. Extending R. CRC Press.

Cheng, Joe, Bhaskar Karambelkar, and Yihui Xie. 2018. Leaflet: Create Interactive Web Maps with the Javascript ’Leaflet’ Library. https://CRAN.R-project.org/package=leaflet.

Brzustowicz, Michael R. 2017. Data Science with Java: [Practical Methods for Scientists and Engineers]. First edition. Beijing Boston Farnham: OReilly.

Garrard, Chris. 2016. Geoprocessing with Python. Shelter Island, NY: Manning Publications.

Bivand, Roger, and Albrecht Gebhardt. 2000. “Implementing Functions for Spatial Statistical Analysis Using the Language.” Journal of Geographical Systems 2 (3): 307–17.

Bivand, Roger, and Markus Neteler. 2000. “Open Source Geocomputation: Using the R Data Analysis Language Integrated with GRASS GIS and PostgreSQL Data Base Systems.” In Proceedings of the 5th International Conference on GeoComputation, edited by Markus Neteler and Roger S. Bivand.

Rowlingson, B. S, and P. J Diggle. 1993. “Splancs: Spatial Point Pattern Analysis Code in S-Plus.” Computers & Geosciences 19 (5): 627–55. https://doi.org/10.1016/0098-3004(93)90099-Q.

Rowlingson, Barry, and Peter Diggle. 2017. Splancs: Spatial and Space-Time Point Pattern Analysis.

Venables, W. N., and B. D. Ripley. 2002. Modern Applied Statistics with S. Fourth. New York: Springer.

Majure, James J., and Albrecht Gebhardt. 2016. Sgeostat: An Object-Oriented Framework for Geostatistical Modeling in S+.

Ripley, Brian D. 2001. “Spatial Statistics in R.” R News 1 (2): 14–15.

Akima, Hiroshi, and Albrecht Gebhardt. 2016. Akima: Interpolation of Irregularly and Regularly Spaced Data.

Jr, Paulo J. Ribeiro, and Peter J. Diggle. 2016. geoR: Analysis of Geostatistical Data.

Baddeley, Adrian, Ege Rubak, and Rolf Turner. 2015. Spatial Point Patterns: Methodology and Applications with R. CRC Press.

Bivand, Roger. 2001. “More on Spatial Data Analysis.” R News 1 (3): 13–17.

Bivand, Roger. 2017. Spdep: Spatial Dependence: Weighting Schemes, Statistics and Models.

Bivand, Roger, and Nicholas Lewin-Koh. 2017. Maptools: Tools for Reading and Handling Spatial Objects.

Bivand, Roger. 2003. “Approaches to Classes for Spatial Data in R.” In Proceedings of DSC, edited by Kurt Hornik, Friedrich Leisch, and Achim Zeileis.

Pebesma, Edzer J., and Roger S. Bivand. 2005. “Classes and Methods for Spatial Data in R.” R News 5 (2): 9–13.

Pebesma, Edzer, and Benedikt Graeler. 2018. Gstat: Spatial and Spatio-Temporal Geostatistical Modelling, Prediction and Simulation. https://CRAN.R-project.org/package=gstat.

Calenge, C. 2006. “The Package Adehabitat for the R Software: Tool for the Analysis of Space and Habitat Use by Animals.” Ecological Modelling 197: 1035.

Hijmans, Robert J. 2016. Geosphere: Spherical Trigonometry.

Bivand, Roger, and Colin Rundel. 2017. Rgeos: Interface to Geometry Engine - Open Source (’Geos’). https://CRAN.R-project.org/package=rgeos.

Hijmans, Robert J. 2017. Raster: Geographic Data Analysis and Modeling. https://CRAN.R-project.org/package=raster.

Bivand, Roger S. 2000. “Using the R Statistical Data Analysis Language on GRASS 5.0 GIS Database Files.” Computers & Geosciences 26 (9): 1043–52.

Bivand, Roger. 2016b. Spgrass6: Interface Between GRASS 6 and R.

Bivand, Roger. 2016a. Rgrass7: Interface Between GRASS 7 Geographical Information System and R.

Brenning, Alexander, Donovan Bangs, and Marc Becker. 2018. RSAGA: SAGA Geoprocessing and Terrain Analysis. https://github.com/r-spatial/RSAGA.

Brenning, Alexander. 2012a. ArcGIS Geoprocessing in R via Python.

Muenchow, Jannes, Patrick Schratz, and Alexander Brenning. 2017. “RQGIS: Integrating R with QGIS for Statistical Geocomputing.” The R Journal 9 (2): 409–28.

Kahle, David, and Hadley Wickham. 2013. “Ggmap: Spatial Visualization with Ggplot2.” The R Journal 5 (1): 144–61.

Lamigueiro, Óscar Perpiñán. 2014. Displaying Time Series, Spatial, and Space-Time Data with R. CRC Press.

Tennekes, Martijn. 2018a. Tmap: Thematic Maps. https://github.com/mtennekes/tmap.

Appelhans, Tim, Florian Detsch, Christoph Reudenbach, and Stefan Woellauer. 2018. Mapview: Interactive Viewing of Spatial Data in R. https://github.com/r-spatial/mapview.

Pebesma, Edzer. 2018. Sf: Simple Features for R. https://github.com/r-spatial/sf/.

1. The conference took place at the University of Leeds, where one of the authors (Robin) is currently based and where the 21st GeoComputation was hosted in 2017 (see geocomputation.org).

2. A laptop with 4GB running a modern operating system such as Ubuntu 16.04 onwards should also be able to reproduce the contents of this book. A laptop with this specification or above can be acquired second-hand for ~US\$100 in many countries nowadays, reducing the financial/hardware barrier to geocomputation far below the levels in operation in the early 2000s, when high-performance computers were unaffordable for most people.

3. The integrated development environment (IDE) RStudio deserves mention here from a user perspective as it has made the interactive use of R more accessible

4. Though, in that case we would recommend to contribute the C++ code to one of the open-source GIS packages since this would make the geoalgorithm available to a wider audience. In turn, you could access the GIS software via one of the available R-GIS interfaces (Chapter 10)

5. Please note, that GEOS is a C++ port of the Java Topology Suite.

6. R has been extended in various directions, notably in shiny, a package for developing interactive we applications in R.

7. Python modules providing access to geoalgorithms include grass.script for GRASS (https://grasswiki.osgeo.org/wiki/GRASS_and_Python), saga-python for SAGA-GIS (http://saga-python.readthedocs.io/en/latest/), processing for QGIS and arcpy for ArcGIS.

8. An overview of R’s spatial ecosystem can be found in the CRAN Task View on the Analysis of Spatial Data (see cran.r-project.org/web/views/Spatial.html).

9. We refrain from labeling it the geoverse with any seriousness awaiting a better name!

10. See the r-spatial organisation and conversations in the discussion repo for more on this.

11. A presentation at the 2003 DSC conference in Vienna gives the background as he saw it then (Rowlingson et al. 2003); see also his announcement of the Rmap package on R-help in early 2003.

12. The raster package also provided tools for raster algebra, general raster functions and the development of more additional raster functions.