From d3a1f642d902d56d18ca6d6033e1e391da879072 Mon Sep 17 00:00:00 2001 From: Luuk van der Meer Date: Sun, 17 Nov 2024 21:45:21 +0100 Subject: [PATCH 1/2] docs: Tidy vignettes :books: --- vignettes/sfn02_create_represent.qmd | 2 +- vignettes/sfn04_join_filter.qmd | 2 +- vignettes/sfn05_routing.qmd | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/vignettes/sfn02_create_represent.qmd b/vignettes/sfn02_create_represent.qmd index ed2d365..7e746f7 100644 --- a/vignettes/sfn02_create_represent.qmd +++ b/vignettes/sfn02_create_represent.qmd @@ -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 diff --git a/vignettes/sfn04_join_filter.qmd b/vignettes/sfn04_join_filter.qmd index eb24924..ea6491e 100644 --- a/vignettes/sfn04_join_filter.qmd +++ b/vignettes/sfn04_join_filter.qmd @@ -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). diff --git a/vignettes/sfn05_routing.qmd b/vignettes/sfn05_routing.qmd index 7f25e80..cb2c01c 100644 --- a/vignettes/sfn05_routing.qmd +++ b/vignettes/sfn05_routing.qmd @@ -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. From 50a0de155588518bf6143aabb1cf567252e66a85 Mon Sep 17 00:00:00 2001 From: Luuk van der Meer Date: Sun, 17 Nov 2024 21:45:34 +0100 Subject: [PATCH 2/2] docs: Fix image link in README :books: --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index e05a711..93df2c9 100644 --- a/README.md +++ b/README.md @@ -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. - - - sfnetworks dependencies and building blocks. + + + sfnetworks dependencies and building blocks. ## Installation