---
title: "dodgr: Distances on Directed Graphs in R"
output:
md_document:
variant: markdown_github
rmarkdown::html_vignette:
self_contained: no
---
```{r opts, echo = FALSE}
knitr::opts_chunk$set (
collapse = TRUE,
warning = TRUE,
message = TRUE,
width = 120,
comment = "#>",
fig.retina = 2,
fig.path = "README-"
)
```
[](https://github.com/UrbanAnalyst/dodgr/actions?query=workflow%3AR-CMD-check)
[](https://app.codecov.io/gh/UrbanAnalyst/dodgr)
[](https://www.repostatus.org/#active)
[](https://cran.r-project.org/package=dodgr)
[](https://cran.r-project.org/package=dodgr)
[](https://bestpractices.coreinfrastructure.org/projects/1396)
# dodgr: Distances on Directed Graphs in R
`dodgr` is an R package for efficient calculation of many-to-many pairwise
distances on dual-weighted directed graphs, for aggregation of flows throughout
networks, and for highly realistic routing through street networks (time-based
routing considering incline, turn-angles, surface quality, everything).
Note that most `dodgr` algorithms implement parallel computation with the
[`RcppParallel` library](https://rcppcore.github.io/RcppParallel/), and by
default use the maximal number of available cores or threads. If you do not
wish `dodgr`to use all available threads, please reduce the number manually by
first specifying a value via
```{r num_threads, eval = FALSE}
RcppParallel::setThreadOptions (numThreads = 1L) # or desired number
```
## What's so special?
Four aspects. First, while other packages exist for calculating distances on
directed graphs, notably [`igraph`](https://igraph.org/r/), even that otherwise
fabulous package does not (readily) permit analysis of *dual-weighted* graphs.
Dual-weighted graphs have two sets of weights for each edge, so routing can be
evaluated with one set of weights, while distances can be calculated with the
other. A canonical example is a street network, where *weighted distances* are
assigned depending on mode of transport (for example, weighted distances for
pedestrians on multi-lane vehicular roads are longer than equivalent distances
along isolated walking paths), yet the desired output remains direct,
unweighted distances. Accurate calculation of distances on street networks
requires a dual-weighted representation. In **R**, `dodgr` is currently the
only package that offers this functionality (without excessive data wrangling).
Second, while [`igraph`](https://igraph.org/r/) and almost all other routing
packages are primarily designed for one-to-one routing, `dodgr` is specifically
designed for many-to-many routing, and will generally outperform equivalent
packages in large routing tasks.
Third, `dodgr` goes beyond the functionality of comparable packages through
including routines to aggregate flows throughout a network, through specifying
origins, destinations, and flow densities between each pair of points.
Alternatively, flows can be aggregated according to a network dispersal model
from a set of origin points and associated densities, and a user-specified
dispersal model.
Fourth and finally, `dodgr` implements highly realistic and fully-customisable
profiles for routing through street networks with various modes of transport,
and using either distance- or time-based routing. Routing can include such
factors as waiting times at traffic lights, delays for turning across oncoming
traffic, access restrictions, and the effects of elevation on both cyclists and
pedestrians. See the dedicated vignette on [street networks and
time-based routing](https://UrbanAnalyst.github.io/dodgr/articles/times.html) for
more detail.
## Installation
You can install latest stable version of `dodgr` from CRAN with:
```{r cran-installation, eval = FALSE}
install.packages ("dodgr") # current CRAN version
```
Alternatively, current development versions can be installed using any of the
following options:
```{r gh-installation, eval = FALSE}
# install.packages("remotes")
remotes::install_git ("https://git.sr.ht/~mpadge/dodgr")
remotes::install_git ("https://codeberg.org/UrbanAnalyst/dodgr")
remotes::install_bitbucket ("UrbanAnalyst/dodgr")
remotes::install_gitlab ("UrbanAnalyst/dodgr")
remotes::install_github ("UrbanAnalyst/dodgr")
```
Then load with
```{r library}
library (dodgr)
packageVersion ("dodgr")
```
## Important Note
While `dodgr` works with any arbitrary networks, it also includes numerous
functions explicitly intended to be applied to geodesic coordinates, which are
identified whenever input data have columns labelled "longitude" and
"latitude", or similar. Coordinates for such data must be in the EPSG:4326
(WGS84) coordinate system. `dodgr` treats coordinates as numbers only, and it
is up to the user to ensure appropriate transformation to WGS84 coordinates
prior to submitting data to `dodgr` functions.
## Usage: Sample Data and `dodgr` networks
To illustrate functionality, the package includes an example data set
containing the Open Street Map network for [Hampi,
India](https://www.openstreetmap.org/#map=15/15.3368/76.4601) (a primarily
pedestrian village in the middle of a large World Heritage zone). These data
are in [Simple Features (`sf`)](https://cran.r-project.org/package=sf) format,
as a collection of `LINESTRING` objects. `dodgr` represents networks as
a simple rectangular graph, with each row representing an edge segment between
two points or vertices. `sf`-format objects can be converted to equivalent
`dodgr` representations with the `weight_streetnet()` function:
```{r hampi}
class (hampi)
dim (hampi)
graph <- weight_streetnet (hampi, wt_profile = "foot")
class (graph)
dim (graph)
```
The `sf`-format network contained `r nrow (hampi)` `LINESTRING` objects, with
the `weight_streetnet()` function decomposing these into `r format (nrow (graph),
big.mark = ",")` distinct edges, indicating that the `sf` representation had
around `r round (nrow (graph) / nrow (hampi))` edges or segments in each
`LINESTRING` object. The `dodgr` network then looks like this:
```{r hampi-net-fakey, eval = FALSE}
head (graph)
```
```{r hampi-net, echo = FALSE}
knitr::kable (head (graph))
```
The `geom_num` column maps directly onto the sequence of `LINESTRING` objects
within the `sf`-formatted data. The `highway` column is taken directly from
Open Street Map, and denotes the kind of "highway" represented by each edge. The
`component` column is an integer value describing which of the connected
components of the network each edge belongs to (with `1` always being the
largest component; `2` the second largest; and so on).
Note that the `d_weighted` values are often greater than the geometric
distances, `d`. In the example shown, `service` highways are not ideal for
pedestrians, and so weighted distances are slightly greater than actual
distances. Compare this with:
```{r hampi-net-faken2, eval = FALSE}
head (graph [graph$highway == "path", ])
```
```{r hampi-net2, echo = FALSE}
knitr::kable (head (graph [graph$highway == "path", ]))
```
A `"path"` offers ideal walking conditions, and so weighted distances are equal
to actual distances.
## Usage: Distances and Times
The many-to-many nature of `dodgr` means that the function to calculate
distances,
[`dodgr_distances()`](https://UrbanAnalyst.github.io/dodgr/reference/dodgr_distances.html)
or, for street networks, times,
[`dodgr_times()`](https://UrbanAnalyst.github.io/dodgr/reference/dodgr_times.html),
accepts two vectors or matrices of routing
points as inputs (describing origins and destinations), and returns
a corresponding matrix of pairwise distances. If an input graph has columns for
both distances and weighted distances, and/or times and weighted times, the
weighted versions are used to determine the effectively shortest or fastest
routes through a network, while actual distances or times are summed along the
routes to calculate final values. It is of course also possible to calculate
distances along fastest routes, times along shortest routes, or any combination
thereof, as detailed in the package vignette on [street networks and time-based
routing](https://UrbanAnalyst.github.io/dodgr/articles/times.html).
Routing points can, for example, be randomly selected from the vertices of a
graph. The vertices can in turn be extracted with the `dodgr_vertices()`
function:
```{r verts-fakey, eval = FALSE}
v <- dodgr_vertices (graph)
head (v)
```
```{r verts, echo = FALSE}
v <- dodgr_vertices (graph)
knitr::kable (head (v))
```
For OSM data extracted with the `osmdata` package (or, equivalently, via the
`dodgr::dodgr_streetnet()` function), each object (vertices, ways, and
high-level relations between these objects) is assigned a unique identifying
number. These are retained both in `osmdata` and `dodgr`, as the `way_id` column
in the above `graph`, and as the `id` column in the vertices. Random vertices
may be generated in this case through selecting `id` values:
```{r random-verts}
from <- sample (v$id, size = 20)
to <- sample (v$id, size = 50)
d <- dodgr_dists (graph = graph, from = from, to = to)
dim (d)
```
Alternatively, the points may be specified as matrices of geographic
coordinates:
```{r}
from_x <- min (graph$from_lon) + runif (20) * diff (range (graph$from_lon))
from_y <- min (graph$from_lat) + runif (20) * diff (range (graph$from_lat))
to_x <- min (graph$from_lon) + runif (50) * diff (range (graph$from_lon))
to_y <- min (graph$from_lat) + runif (50) * diff (range (graph$from_lat))
d <- dodgr_dists (graph = graph, from = cbind (from_x, from_y), to = cbind (to_x, to_y))
```
In this case, the random points will be mapped on to the nearest points on the
street network. This may, of course, map some points onto minor, disconnected
components of the graph. This can be controlled either by reducing the graph to
it's largest connected component only:
```{r large-comp, eval = FALSE}
graph <- graph [graph$component == 1, ]
nrow (graph)
```
or by explicitly using the `match_points_to_verts()` function with the option
`connected = TRUE`:
```{r}
from <- match_points_to_verts (v, cbind (from_x, from_y), connected = TRUE)
to <- match_points_to_verts (v, cbind (to_x, to_y), connected = TRUE)
```
This function returns an index into the result of `dodgr_vertices`, and so
points to use for routing must then be extracted as follows:
```{r}
from <- v$id [from] # or from <- v [from, c ("x", "y")]
to <- v$id [to]
d <- dodgr_dists (graph = graph, from = from, to = to)
```
## Usage: Flow Aggregation
Flow aggregation refers to the procedure of routing along multiple ways
according to specified densities of flow between defined origin and destination
points, and aggregating flows along each edge of the network. The procedure is
functionally similar to the above procedure for distances, with the addition of
a matrix specifying pairwise flow densities between the input set of origin
(`from`) and destination (`to`) points. The following example illustrates use
with a random "flow matrix":
```{r flows}
flows <- array (runif (length (from) * length (to)), dim = c (length (from), length (to)))
length (from)
length (to)
dim (flows)
f <- dodgr_flows_aggregate (graph = graph, from = from, to = to, flows = flows)
```
The result is simply the input `graph` with an additional column quantifying
the aggregate flows along each edge:
```{r flows-out-fakey, eval = FALSE}
head (f)
```
```{r flows-out, echo = FALSE}
knitr::kable (head (f))
```
An additional flow aggregation function can be applied in cases where only
densities at origin points are known, and movement throughout a graph is
dispersive:
```{r, eval = FALSE}
f <- dodgr_flows_disperse (graph = graph, from = from, dens = runif (length (from)))
```
## Further detail
For more detail, see the [main package
vignette](https://UrbanAnalyst.github.io/dodgr/articles/dodgr.html), and the second
vignette on [street networks and time-based
routing](https://UrbanAnalyst.github.io/dodgr/articles/times.html)
## Contributors
All contributions to this project are gratefully acknowledged using the [`allcontributors` package](https://github.com/ropensci/allcontributors) following the [allcontributors](https://allcontributors.org) specification. Contributions of any kind are welcome!
### Code
### Issue Authors
### Issue Contributors
