Skip to content

Commit

Permalink
Merge pull request #280 from luukvdmeer/v1.0
Browse files Browse the repository at this point in the history
V1.0
  • Loading branch information
luukvdmeer authored Nov 17, 2024
2 parents bcad014 + 50a0de1 commit 7a5ec1a
Show file tree
Hide file tree
Showing 4 changed files with 6 additions and 6 deletions.
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,9 +18,9 @@ Geospatial networks are graphs embedded in geographical space. That means that b
We created {sfnetworks} to facilitate such an integrated workflow. It combines the forces of two popular R packages: {[sf](https://r-spatial.github.io/sf/)} for spatial data science and {[tidygraph](https://tidygraph.data-imaginist.com/index.html)} for standard graph analysis. The core of the package is a dedicated data structure for geospatial networks, that can be provided as input to both the graph analytical functions of {tidygraph} as well as the spatial analytical functions of {sf}, without the need for conversion. Additionally, we implemented a set of geospatial network specific functions, such as routines for shortest path calculation, network cleaning and topology modification. {sfnetworks} is designed as a general-purpose package suitable for usage across different application domains, and can be seamlessly integrated in [tidyverse](https://www.tidyverse.org/) workflows.

<picture>
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/luukvdmeer/sfnetworks/refs/heads/v1.0/vignettes/figures/dependencies-dark.png">
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/luukvdmeer/sfnetworks/refs/heads/v1.0/vignettes/figures/dependencies.png">
<img alt="sfnetworks dependencies and building blocks." src="https://github.com/luukvdmeer/sfnetworks/blob/v1.0/vignettes/figures/dependencies.png">
<source media="(prefers-color-scheme: dark)" srcset="https://raw.githubusercontent.com/luukvdmeer/sfnetworks/refs/heads/main/vignettes/figures/dependencies-dark.png">
<source media="(prefers-color-scheme: light)" srcset="https://raw.githubusercontent.com/luukvdmeer/sfnetworks/refs/heads/main/vignettes/figures/dependencies.png">
<img alt="sfnetworks dependencies and building blocks." src="https://raw.githubusercontent.com/luukvdmeer/sfnetworks/refs/heads/main/vignettes/figures/dependencies.png">
</picture>

## Installation
Expand Down
2 changes: 1 addition & 1 deletion vignettes/sfn02_create_represent.qmd
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ old_hooks = fansi::set_knit_hooks(
)
```

The `{sfnetworks}` contains the `sfnetwork` class to represent spatial networks in R. There are several ways in which you can create instances of this class. This vignette describes these ways, and provides more detail on the ins and outs of the data structure.
The `{sfnetworks}` package contains the `sfnetwork` class to represent spatial networks in R. There are several ways in which you can create instances of this class. This vignette describes these ways, and provides more detail on the ins and outs of the data structure.

```{r}
#| message: false
Expand Down
2 changes: 1 addition & 1 deletion vignettes/sfn04_join_filter.qmd
Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,7 @@ old_hooks = fansi::set_knit_hooks(
)
```

The integration with `{sf}` and addition of several spatial network specific functions in `sfnetworks` allow to easily filter information from a network based on spatial relationships, and to join new information into a network based on spatial relationships. This vignette presents several ways to do that.
The integration with `{sf}` and addition of several spatial network specific functions in `{sfnetworks}` allow to easily filter information from a network based on spatial relationships, and to join new information into a network based on spatial relationships. This vignette presents several ways to do that.

Both spatial filters and spatial joins use spatial predicate functions to examine spatial relationships. Spatial predicates are mathematically defined binary spatial relations between two simple feature geometries. Often used examples include the predicate *equals* (geometry x is equal to geometry y) and the predicate *intersects* (geometry x has at least one point in common with geometry y). For an overview of all available spatial predicate functions in `{sf}` and links to detailed explanations of the underlying algorithms, see [here](https://r-spatial.github.io/sf/reference/geos_binary_pred.html).

Expand Down
2 changes: 1 addition & 1 deletion vignettes/sfn05_routing.qmd
Original file line number Diff line number Diff line change
Expand Up @@ -172,7 +172,7 @@ purrr::walk(paths$graph, plot, cex = 4)

## Choosing a routing backend

As mentioned, `{sfnetwork}` does not implement the routing algorithms themselves. For that, it relies on other packages, which we call "routing backends" or "routers" for short. The default routing backend is `{igraph}`. The `st_network_paths()` function wraps, depending on argument settings, `igraph::shortest_paths()`, `igraph::all_shortest_paths()` and `igraph::k_shortest_paths()`. The `st_network_cost()` function wraps `igraph::distances()`. The benefits of this routing backend are: 1) it can compute all shortest paths, if there exists more than one; 2) it can compute the $k$ shortest paths with Yen's algorithm; 3) no internal conversion between data structures is needed. However, routing is only supported from a single origin. Hence, many-to-many routing is not possible.
As mentioned, `{sfnetworks}` does not implement the routing algorithms themselves. For that, it relies on other packages, which we call "routing backends" or "routers" for short. The default routing backend is `{igraph}`. The `st_network_paths()` function wraps, depending on argument settings, `igraph::shortest_paths()`, `igraph::all_shortest_paths()` and `igraph::k_shortest_paths()`. The `st_network_cost()` function wraps `igraph::distances()`. The benefits of this routing backend are: 1) it can compute all shortest paths, if there exists more than one; 2) it can compute the $k$ shortest paths with Yen's algorithm; 3) no internal conversion between data structures is needed. However, routing is only supported from a single origin. Hence, many-to-many routing is not possible.

The second routing backend that is currently supported is `{dodgr}`. This package implements a very fast routing algorithm in C++. This is exposed in `{sfnetworks}` by wrapping `dodgr::dodgr_paths()` in `st_network_paths()` and `dodgr::dodgr_dists()` in `st_network_cost()`. The benefits of this routing backend are: 1) it can route from multiple origins to multiple destinations, i.e. many-to-many routing; 2) it supports dual-weighted routing (see [here](#dual-weighted-routing)); 3) it is very fast also on large networks. However, there is currently no support for $k$ shortest paths routing, and some internal conversions are needed to bridge between the different data structures.

Expand Down

0 comments on commit 7a5ec1a

Please sign in to comment.