diff --git a/NAMESPACE b/NAMESPACE index f30348ae..810b4d6e 100644 --- a/NAMESPACE +++ b/NAMESPACE @@ -53,6 +53,7 @@ export(line2pointsn) export(line2vertices) export(line_bearing) export(line_breakup) +export(line_cast) export(line_midpoint) export(line_segment) export(line_via) @@ -89,6 +90,9 @@ export(rnet_breakup_vertices) export(rnet_duplicated_vertices) export(rnet_get_nodes) export(rnet_group) +export(rnet_join) +export(rnet_split_lines) +export(rnet_subset) export(route) export(route_average_gradient) export(route_dodgr) diff --git a/R/data.R b/R/data.R index 7768f15b..2af721fe 100644 --- a/R/data.R +++ b/R/data.R @@ -125,7 +125,7 @@ NULL #' @format A spatial lines dataset with 49 rows and 15 columns NULL -#' spatial lines dataset representing a route network +#' Spatial lines dataset representing a route network #' #' #' The flow of commuters using different segments of the road network represented in the @@ -138,6 +138,19 @@ NULL #' @format A spatial lines dataset 80 rows and 1 column NULL +#' Spatial lines dataset representing a small route network +#' +#' +#' The flow between randomly selected vertices on the `osm_net_example`. +#' See `data-raw/route_network_small.R` for details. +#' +#' @family data +#' @docType data +#' @keywords datasets +#' @name route_network_small +#' @format A spatial lines dataset with one column: flow +NULL + #' Example of OpenStreetMap road network #' @docType data #' @keywords datasets diff --git a/R/rnet_join.R b/R/rnet_join.R new file mode 100644 index 00000000..33c8fe30 --- /dev/null +++ b/R/rnet_join.R @@ -0,0 +1,146 @@ +#' Join route networks +#' +#' This is a spatial join function that is enables adding columns to a +#' 'target' route network from a 'source' route +#' network that contains the base geometry, e.g. from OSM +#' +#' The output is an sf object containing polygons representing +#' buffers around the route network in `rnet_x`. +#' The examples below demonstrate how to join attributes from +#' a route network object created with the function [overline()] onto +#' OSM geometries. +#' +#' Note: The main purpose of this function is to join an ID from `rnet_x` +#' onto `rnet_y`. Subsequent steps, e.g. with [dplyr::inner_join()] +#' are needed to join the attributes back onto `rnet_x`. +#' There are rarely 1-to-1 relationships between spatial network geometries +#' so we take care when using this function. +#' +#' See [#505](https://github.com/ropensci/stplanr/issues/505) for details +#' and a link to an interactive example of inputs and outputs shown below. +#' +#' @param rnet_x Target route network, the output will have the same geometries +#' as features in this object. +#' @param rnet_y Source route network. Columns from this route network object will +#' be copied across to the new network. +#' @param dist The buffer width around rnet_y in meters. 1 m by default. +#' @param length_y Add a new column called `length_y`? Useful when joining based on +#' length of segments (e.g. weighted mean). `TRUE` by default. +#' @param key_column The index of the key (unique identifier) column in `rnet_x`. +#' @param subset_x Subset the source route network by the target network before +#' creating buffers? This can lead to faster and better results. Default: +#' `TRUE`. +#' @param dist_subset The buffer distance in m to apply when breaking up the +#' source object `rnet_y`. Default: 5. +#' @param split_y Should the second route network be split at the start and +#' end points of LINESTRING features in the first? `TRUE` by default. +#' @param ... Additional arguments passed to `rnet_subset`. +#' @examples +#' library(sf) +#' library(dplyr) +#' # Uncomment for interactive examples: +#' plot(route_network_small["flow"]) +#' plot(osm_net_example$geometry, lwd = 5, col = "grey") +#' plot(route_network_small["flow"], add = TRUE) +#' rnetj = rnet_join(osm_net_example, route_network_small, dist = 9) +#' # library(mapview) +#' # mapview(rnetj, zcol = "flow") + +#' # mapview(route_network_small, zcol = "flow") +#' plot(rnetj["flow"]) +#' plot(route_network_small["flow"], add = TRUE) +#' rnetj_summary = rnetj %>% +#' sf::st_drop_geometry() %>% +#' group_by(osm_id) %>% +#' summarise( +#' flow = weighted.mean(flow, length_y, na.rm = TRUE), +#' ) +#' osm_joined_rnet = left_join(osm_net_example, rnetj_summary) +#' plot(route_network_small["flow"]) +#' plot(osm_joined_rnet[c("flow")]) +#' # Improve fit between geometries and performance by subsetting rnet_x +#' osm_subset = rnet_subset(osm_net_example, route_network_small, dist = 5) +#' osm_joined_rnet = left_join(osm_subset, rnetj_summary) +#' plot(route_network_small["flow"]) +#' plot(osm_joined_rnet[c("flow")]) +#' # mapview(joined_network) + +#' # mapview(route_network_small) +#' @export +rnet_join = function(rnet_x, rnet_y, dist = 5, length_y = TRUE, key_column = 1, + subset_x = TRUE, dist_subset = 5, split_y = TRUE, ...) { + if (subset_x) { + rnet_x = rnet_subset(rnet_x, rnet_y, dist = dist_subset, ...) + } + rnet_x_buffer = geo_buffer(rnet_x, dist = dist, nQuadSegs = 2) + if (split_y) { + rnet_y = rnet_split_lines(rnet_y, rnet_x, dist = dist_subset) + } + if (length_y) { + rnet_y$length_y = as.numeric(sf::st_length(rnet_y)) + } + rnetj = sf::st_join(rnet_x_buffer[key_column], rnet_y, join = sf::st_contains) + rnetj +} + +#' Subset one route network based on overlaps with another +#' +#' @param rnet_x The route network to be subset +#' @param rnet_y The subsetting route network +#' @param dist The buffer width around y in meters. 1 m by default. +#' @param crop Crop `rnet_x`? `TRUE` is the default +#' @param min_x Segments shorter than this multiple of dist +#' *and* which were longer +#' before the cropping process will be removed. 3 by default. +#' @export +rnet_subset = function(rnet_x, rnet_y, dist = 1, crop = TRUE, min_x = 3) { + rnet_x$length_x_original = as.numeric(sf::st_length(rnet_x)) + rnet_y_union = sf::st_union(rnet_y) + rnet_y_buffer = stplanr::geo_buffer(rnet_y_union, dist = dist, nQuadSegs = 2) + if(crop) { + rnet_x = sf::st_intersection(rnet_x, rnet_y_buffer) + rnet_x = line_cast(rnet_x) + rnet_x$length_x_cropped = as.numeric(sf::st_length(rnet_x)) + min_length = dist * min_x + sel_short = rnet_x$length_x_cropped < min_length & + rnet_x$length_x_original > min_length + rnet_x = rnet_x[!sel_short, ] + } else { + rnet_x[rnet_y_buffer, , op = sf::st_within] + } + rnet_x +} +#' Split lines in a route network based points +#' +#' If the object passed to the second argument has LINSTRING geometries +#' the start and end points of linestrings are used. +#' +#' @param rnet_x The route network to be broken into smaller pieces +#' @param geo_y The geographic object used to break up the route network +#' @param dist The width of the buffer used when breaking up the route network. +#' For imprecise data it may be worth increasing this above 1 m, the default. +#' @export +rnet_split_lines = function(rnet_x, geo_y, dist = 1) { + if (all(grepl(pattern = "LINE", x = sf::st_geometry_type(rnet_x)))) { + geo_y = c( + lwgeom::st_startpoint(geo_y), + lwgeom::st_endpoint(geo_y) + ) + } + # speed-up subsequent steps: + points = sf::st_union(geo_y) + points_buffer = stplanr::geo_buffer(points, dist = dist) + rnet_split = sf::st_difference(rnet_x, points_buffer) + rnet_split_lines = line_cast(rnet_split) + rnet_split_lines$length_osm_cast = as.numeric(sf::st_length(rnet_split_lines)) + # rnet_split_lines[rnet_split_lines$length_osm_cast > min_lenth, ] + rnet_split_lines +} + +#' Convert multilinestring object into linestrings +#' +#' Without losing vertices +#' +#' @param x Linestring object +#' @export +line_cast = function(x) { + sf::st_cast(sf::st_cast(x, "MULTILINESTRING"), "LINESTRING") +} diff --git a/_pkgdown.yml b/_pkgdown.yml index 9902bbde..45b28760 100644 --- a/_pkgdown.yml +++ b/_pkgdown.yml @@ -12,6 +12,7 @@ reference: - title: Work with (desire) lines contents: - has_concept("lines") + - starts_with("line") - title: Work with and analyse routes contents: - has_concept("route_funs") diff --git a/data-raw/route_network_small.R b/data-raw/route_network_small.R new file mode 100644 index 00000000..c5e7b0fe --- /dev/null +++ b/data-raw/route_network_small.R @@ -0,0 +1,25 @@ +## code to prepare `route_network_small` dataset goes here + +# Create route network focussed on OSM data +library(tidyverse) +osm_vertices = sf::st_cast(osm_net_example, to = "POINT") +plot(osm_vertices$geometry) +set.seed(2022) +osm_vertices_random = osm_vertices %>% + sample_n(size = 9) + +desire_lines = od::points_to_odl(p = osm_vertices_random) +plot(desire_lines) +desire_lines$length = sf::st_length(desire_lines) %>% as.numeric() +summary(desire_lines$length) +desire_lines_long = desire_lines %>% + filter(length > 100) + +routes = route(l = desire_lines_long, route_fun = stplanr::route_osrm) +routes$flow = seq(nrow(routes)) +route_network_small = overline(routes, attrib = "flow") +plot(osm_net_example$geometry, lwd = 5, col = "grey") +route_network_small %>% + select(flow) %>% + plot(add = TRUE) +usethis::use_data(route_network_small, overwrite = TRUE) diff --git a/data/osm_net_example.rda b/data/osm_net_example.rda index c3b63d4d..e3d01652 100644 Binary files a/data/osm_net_example.rda and b/data/osm_net_example.rda differ diff --git a/data/route_network_small.rda b/data/route_network_small.rda new file mode 100644 index 00000000..4b3f6c09 Binary files /dev/null and b/data/route_network_small.rda differ diff --git a/docs/CONDUCT.html b/docs/CONDUCT.html index 2f90a1a2..95f45336 100644 --- a/docs/CONDUCT.html +++ b/docs/CONDUCT.html @@ -1,145 +1,60 @@ - - - - - - - -Contributor Code of Conduct • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Contributor Code of Conduct

+
+

Contributor Code of Conduct

+ Source: CONDUCT.md
@@ -149,73 +64,56 @@

Contributor Code of Conduct

Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.

-

This Code of Conduct is adapted from the Contributor Covenant (http:contributor-covenant.org), version 1.0.0, available at http://contributor-covenant.org/version/1/0/0/

-
- -
- - - +

This Code of Conduct is adapted from the Contributor Covenant (http:contributor-covenant.org), version 1.0.0, available at http://contributor-covenant.org/version/1/0/0/

+
-
+ - - + + diff --git a/docs/LICENSE-text.html b/docs/LICENSE-text.html index 5393e5b2..2c023e23 100644 --- a/docs/LICENSE-text.html +++ b/docs/LICENSE-text.html @@ -1,215 +1,113 @@ - - - - - - - -License • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

License

+
+

License

+ 
YEAR: 2016
 COPYRIGHT HOLDER: Robin Lovelace and Richard Ellison
-
- - - -
- +
-
+ - - + + diff --git a/docs/articles/index.html b/docs/articles/index.html index ff6b0e43..ab831dd1 100644 --- a/docs/articles/index.html +++ b/docs/articles/index.html @@ -1,222 +1,125 @@ - - - - - - - -Articles • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Articles

+
+

Articles

All vignettes

-
-
Origin-destination data with stplanr
-
-
stplanr: A Package for Transport Planning
-
-
Parallel routing and performance with stplanr
-
-
Route networks with stplanr
-
-
Transport routing with stplanr
-
-
Introducing stplanr
-
-
-
-
-
- - -
+ + + -
- + + - - + + diff --git a/docs/articles/stplanr-paper.html b/docs/articles/stplanr-paper.html index 86c3e77e..0323563a 100644 --- a/docs/articles/stplanr-paper.html +++ b/docs/articles/stplanr-paper.html @@ -4,266 +4,559 @@ - + + stplanr: A Package for Transport Planning • stplanr - + - - - - - - - + + + + + - - + + - -
-
-
-
-
-

stplanr: A Package for Transport Planning

-

Robin Lovelace

+ + +
+
+

stplanr: A Package for Transport Planning

+

Robin +Lovelace

- University of Leeds
+ University of +Leeds
-

Richard Ellison

+

Richard +Ellison

- University of Sydney
+ University of +Sydney
- Source: ../../vignettes/stplanr-paper.Rmd - - + Source: vignettes/stplanr-paper.Rmd +
stplanr-paper.Rmd

Abstract

-

Tools for transport planning should be flexible, scalable and transparent. The stplanr package demonstrates and provides a home for such tools, with an emphasis on spatial transport data and non-motorized modes. stplanr facilitates common transport planning tasks including: downloading and cleaning transport datasets; creating geographic ‘desire lines from origin-destination (OD) data; route assignment, via the SpatialLinesNetwork class and interfaces to routing services such as CycleStreets.net; calculation of route segment attributes such as bearing and aggregate flow; and `travel watershed’ analysis. This paper demonstrates this functionality using reproducible examples on real transport datasets. More broadly, the experience shows open source software can form the basis of a reproducible transport planning workflow. stplanr, alongside other packages and open source projects, could provide a more transparent and democratically accountable alternative to the current approach which is heavily reliant on proprietary and technically and financially inaccessible software.

+

Tools for transport planning should be flexible, scalable and + transparent. The stplanr package demonstrates and + provides a home for such tools, with an emphasis on spatial + transport data and non-motorized modes. stplanr + facilitates common transport planning tasks including: downloading + and cleaning transport datasets; creating geographic ‘desire lines + from origin-destination (OD) data; route assignment, via the + SpatialLinesNetwork class and interfaces to routing + services such as CycleStreets.net; calculation of route segment + attributes such as bearing and aggregate flow; and `travel + watershed’ analysis. This paper demonstrates this functionality + using reproducible examples on real transport datasets. More + broadly, the experience shows open source software can form the + basis of a reproducible transport planning workflow. + stplanr, alongside other packages and open source + projects, could provide a more transparent and democratically + accountable alternative to the current approach which is heavily + reliant on proprietary and technically and financially + inaccessible software.

-
-

-Note

-

This paper has now been peer reviewed and published by the R Journal. Please see the published version at journal.r-project.org and cite it as Lovelace and Ellison (2018).

-
-
-

-Introduction

-

Transport planning can broadly be defined as the process of designing and evaluating transport interventions (de Dios Ortuzar and Willumsen 2011) usually with the ultimate aim of improving transport systems from economic, social and environmental perspectives. This inevitably involves a degree of subjective judgment and intuition. With the proliferation of new transport datasets — and the increasing availability of hardware and software to make sense of them — there is great potential for the discipline to become more evidence-based and scientific (Balmer, Rieser, and Nagel 2009). Transport planners have always undertaken a wide range computational activities (Boyce and Williams 2015), but with the digital revolution the demands have grown beyond the capabilities of a single, monolithic product. The diversity of tasks , and need for democratic accountability in public decision making, suggests that future-proof transport planning software should be:

+
+

Note +

+

This paper has now been peer reviewed and published by the R Journal. +Please see the published version at journal.r-project.org +and cite it as Lovelace and Ellison +(2018).

+

The code presented in this paper requires stplanr 0.8.5 or earlier, +which can be installed as follows:

+
+remotes::install_github("ropensci/stplanr", ref = "v0.8.5")
+
+
+

Introduction +

+

Transport planning can broadly be defined as the process of designing +and evaluating transport interventions (de Dios +Ortuzar and Willumsen 2011) usually with the ultimate aim of +improving transport systems from economic, social and environmental +perspectives. This inevitably involves a degree of subjective judgment +and intuition. With the proliferation of new transport datasets — and +the increasing availability of hardware and software to make sense of +them — there is great potential for the discipline to become more +evidence-based and scientific (Balmer, Rieser, +and Nagel 2009). Transport planners have always undertaken a wide +range computational activities (Boyce and +Williams 2015), but with the digital revolution the demands have +grown beyond the capabilities of a single, monolithic product. The +diversity of tasks , and need for democratic accountability in public +decision making, suggests that future-proof transport planning software +should be:

  • flexible, able to handle a wide range of data formats

    • -

  • scalable, able to work at multiple geographic levels from single streets to large cities and regions

    • -

  • robust and reliable, tested on a range of datasets and able to work ’out of the box’ in a range of real-world projects

    • -

  • open source and reproducible, ensuring transparency and encouraging citizen science

    • +

  • scalable, able to work at multiple geographic levels from single +streets to large cities and regions

    • +

  • robust and reliable, tested on a range of datasets and able to +work ’out of the box’ in a range of real-world projects

    • +

  • open source and reproducible, ensuring transparency and +encouraging citizen science

-

This paper sets out to demonstrate that open source software with a command-line interface (CLI) can provide a foundation for transport planning software that meets each of these criteria. R provides a strong basis for progress in this direction because it already contains functionality used in common transport planning workflows. , and greatly improved R’s spatial abilities (Bivand, Pebesma, and G’omez-Rubio 2013), work that is being consolidated and extended in the recent package.

-

Building on these foundations a number of spatial packages have been developed for applied domains including: disease mapping and modelling, with packages such as and (Kim and Wakefield 2016; Brown and Zhou 2016); spatial ecology, with the adehabitat family of packages (Calenge 2006); and visualisation, with packages such as SpatialEpi, diseasemapping and Brown (2016). However, there has been little prior work to develop R functionality designed specifically for transport planning, with the notable exceptions of TravelR (a package on R-Forge last updated in 2012) and gtfsr (a package for handling General Transit Feed Specification (GTFS) data).

-

The purpose of stplanr is to provide a toolbox rather than a specific solution for transport planning, with an emphasis on spatial data and active modes. This emphasis is timely given the recent emphasis on sustainability (Banister 2008) and ‘Big Data’ (Zheng et al. 2016) in the wider field of transport planning. A major motivation was the lack of R packages, and open source software in general, for transport applications. This may be surprising given the uqiquity of transport problems;1 R’s proficiency at handling spatial, temporal and travel survey data that describe transport systems; and the growing popularity of R in applied domains (Jalal et al. 2017; Moore and Hutchinson 2017). Another motivation is the growth in open access datasets: the main purpose of early versions of the package was to process open origin-destination data (Lovelace et al. 2017).

-

R is already used in transport applications, as illustrated by recent research that applies packages from other domains to transport problems. For instance, Efthymiou and Antoniou (2012) use R to analyse the data collected from an online survey focused on car-sharing, bicycle-sharing and electric vehicles. Efthymiou and Antoniou (2012) also used R to collect and analyse transport-related data from Twitter using packages including , and . These packages were used to download, parse and plot the Twitter data using a method that can be repeated and the results reproduced or updated. More general statistical analyses have also been conducted on transport-related datasets using packages including and (Diana 2012; Cerin et al. 2013). Despite the rising use of R for transport research, there has yet been to be a package for transport planning.

-

The design of the R language, with its emphasis on flexibility, data processing and statistical modelling, suggests it can provide a powerful environment for transport planning research. There are many quantitative methods in transport planning, many of which fit into the classic ‘four stage’ transport model which involves the following steps (de Dios Ortuzar and Willumsen 2011): (1) trip generation to estimate trip freqency from origins; (2) distribution of trips to destinations; (3) modal split of trips between walking, cycling, buses etc.; (4) assignment of trips to the transport route network. To this we would like to add two more stages for the big data age: (0) data processing and exploration; and (5) validation. This sequence is not the only way of transport modelling and some have argued that its dominance has reduced innovation. However it is certainly a common approach and provides a useful schema for classifying the kinds of task that stplanr can tackle:

+

This paper sets out to demonstrate that open source software with a +command-line interface (CLI) can provide a foundation for transport +planning software that meets each of these criteria. R provides a strong +basis for progress in this direction because it already contains +functionality used in common transport planning workflows. , and greatly +improved R’s spatial abilities (Bivand, Pebesma, +and G’omez-Rubio 2013), work that is being consolidated and +extended in the recent package.

+

Building on these foundations a number of spatial packages have been +developed for applied domains including: disease mapping and modelling, +with packages such as and (Kim and Wakefield +2016; Brown and Zhou 2016); spatial ecology, with the +adehabitat family of packages (Calenge 2006); and visualisation, with packages +such as SpatialEpi, diseasemapping and +Brown (2016). However, there has been +little prior work to develop R functionality designed specifically for +transport planning, with the notable exceptions of TravelR (a +package on R-Forge last updated in 2012) and tidytransit (a +package for handling General Transit Feed Specification (GTFS) +data).

+

The purpose of stplanr is to provide a toolbox +rather than a specific solution for transport planning, with an emphasis +on spatial data and active modes. This emphasis is timely given the +recent emphasis on sustainability (Banister +2008) and ‘Big Data’ (Zheng et al. +2016) in the wider field of transport planning. A major +motivation was the lack of R packages, and open source software in +general, for transport applications. This may be surprising given the +ubiquity of transport problems;1 R’s proficiency at handling spatial, +temporal and travel survey data that describe transport systems; and the +growing popularity of R in applied domains (Jalal +et al. 2017; Moore and Hutchinson 2017). Another motivation is +the growth in open access datasets: the main purpose of early versions +of the package was to process open origin-destination data (Lovelace et al. 2017).

+

R is already used in transport applications, as illustrated by recent +research that applies packages from other domains to transport problems. +For instance, Efthymiou and Antoniou +(2012) use R to analyse the data collected from an online survey +focused on car-sharing, bicycle-sharing and electric vehicles. Efthymiou and Antoniou (2012) also used R to +collect and analyse transport-related data from Twitter using packages +including , and . These packages were used to download, parse and plot +the Twitter data using a method that can be repeated and the results +reproduced or updated. More general statistical analyses have also been +conducted on transport-related datasets using packages including and +(Diana 2012; Cerin et al. 2013). Despite +the rising use of R for transport research, there has yet been to be a +package for transport planning.

+

The design of the R language, with its emphasis on flexibility, data +processing and statistical modelling, suggests it can provide a powerful +environment for transport planning research. There are many quantitative +methods in transport planning, many of which fit into the classic ‘four +stage’ transport model which involves the following steps (de Dios Ortuzar and Willumsen 2011): (1) trip +generation to estimate trip freqency from origins; (2) +distribution of trips to destinations; (3) modal split +of trips between walking, cycling, buses etc.; (4) assignment +of trips to the transport route network. To this we would like to add +two more stages for the big data age: (0) data processing and +exploration; and (5) validation. This sequence is not the only way of +transport modelling and some have argued that its dominance has reduced +innovation. However it is certainly a common approach and provides a +useful schema for classifying the kinds of task that +stplanr can tackle:

    -

  • Accessing and processing of data on transport infrastructure and behaviour (stage 0)

    • +

  • Accessing and processing of data on transport infrastructure and +behaviour (stage 0)

  • Analysis and visualisation of the transport network (0)

    • -

  • Analysis of origin-destination (OD) data and the visualisation of resulting ‘desire lines’

    • -

  • The allocation of desire lines to roads and other guideways via routing services

    • -

  • The aggregation of routes to estimate total levels of flow on segments throughout the transport network

    • -

  • Development of models to estimate transport behaviour currently and under various scenarios of change

    • -

  • The calculation of ‘catchment areas’ affected by transport infrastructure

    • +

  • Analysis of origin-destination (OD) data and the visualisation of +resulting ‘desire lines’

    • +

  • The allocation of desire lines to roads and other guideways via +routing services

    • +

  • The aggregation of routes to estimate total levels of flow on +segments throughout the transport network

    • +

  • Development of models to estimate transport behaviour currently +and under various scenarios of change

    • +

  • The calculation of ‘catchment areas’ affected by transport +infrastructure

-

The automation of such tasks can assist researchers and practitioners to create evidence for decision making. If the data processing and analysis stages are fast and painless, more time can be dedicated to visualisation and decision making. This should allow researchers to focus on problems, rather than on clunky graphical user interfaces (GUIs), and ad-hoc scripts that could be generalised. Furthermore, if the process can be made reproducible and accessible (e.g. via online visualisation packages such as shiny), this could help transport planning move away from reliance on ‘black boxes’ (Waddell 2002) and empower citizens to challenge decisions made by transport planning authorities based on the evidence (Hollander 2016). There are many advantages of using a scriptable, interactive and open source language such as R for transport planning. Such an approach enables: reproducible research; the automation and sharing of code between researchers; reduced barriers to innovation as anyone can create new features for the benefit of all planners; easier interaction with non domain experts (who will lack dedicated software); and integration with other software systems, as illustrated by the use of to generate JavaScript for sharing interactive maps for transport planning, as used in the publicly accessible Propensity to Cycle Tool (Lovelace et al. 2017). Furthermore, R has a strong user community which can support newcomers (stplanr was peer reviewed thanks to the community surrounding ROpenSci). The advantages of using R specifically to develop the functionality described in this paper are that it has excellent geo-statistical capabilities (Pebesma et al. 2015), visualisation packages (e.g. tmap, ggplot2), support for logit models (which are useful for modelling modal shift), and support for the many formats that transport datasets are stored in (e.g. via the haven and rio packages).

+

The automation of such tasks can assist researchers and practitioners +to create evidence for decision making. If the data processing and +analysis stages are fast and painless, more time can be dedicated to +visualisation and decision making. This should allow researchers to +focus on problems, rather than on clunky graphical user interfaces +(GUIs), and ad-hoc scripts that could be generalised. Furthermore, if +the process can be made reproducible and accessible (e.g. via online +visualisation packages such as shiny), this could help +transport planning move away from reliance on ‘black boxes’ (Waddell 2002) and empower citizens to challenge +decisions made by transport planning authorities based on the evidence +(Hollander 2016). There are many +advantages of using a scriptable, interactive and open source language +such as R for transport planning. Such an approach enables: reproducible +research; the automation and sharing of code between researchers; +reduced barriers to innovation as anyone can create new features for the +benefit of all planners; easier interaction with non domain experts (who +will lack dedicated software); and integration with other software +systems, as illustrated by the use of to generate JavaScript for sharing +interactive maps for transport planning, as used in the publicly +accessible Propensity to Cycle Tool (Lovelace et +al. 2017). Furthermore, R has a strong user community which can +support newcomers (stplanr was peer reviewed thanks to the +community surrounding ROpenSci). The advantages of using R specifically +to develop the functionality described in this paper are that it has +excellent geo-statistical capabilities (Pebesma +et al. 2015), visualisation packages (e.g. tmap, +ggplot2), support for logit models (which are useful +for modelling modal shift), and support for the many formats that +transport datasets are stored in (e.g. via the haven +and rio packages).

-
-

-Package structure and functionality

-

The package can be installed and loaded in the usual way (see the package’s README for dependencies and access to development versions):

-
-install.packages("stplanr")
+
+

Package structure and functionality +

+

The package can be installed and loaded in the usual way (see the +package’s README for +dependencies and access to development versions):

-

As illustrated by the message emitted when stplanr is loaded, it depends on . This means that the spatial data classes commonly used in the package will work with generic R functions such as summary, aggregate and, as illustrated in the figures below, plot .

-
-

-Core functions and classes

-

The package’s core functions are structured around 3 common types of spatial transport data:

+install.packages("stplanr")
+ +

As illustrated by the message emitted when stplanr +is loaded, it depends on . This means that the spatial data classes +commonly used in the package will work with generic R functions such as +summary, aggregate and, as illustrated in the +figures below, plot .

+
+

Core functions and classes +

+

The package’s core functions are structured around 3 common types of +spatial transport data:

    -
  • Origin-destination (OD) data, which report the number of people travelling between origin-destination pairs. This type of data is not explicitly spatial (OD datasets are usually represented as data frames) but represents movement over space between points in geographical space. An example is provided in the flow dataset.
    • -
  • Line data, one dimensional linear features on the surface of the Earth. These are typically stored as a SpatialLinesDataFrame.
    • -
  • Route data are special types of lines which have been allocated to the transport network. Routes typically result from the allocation of a straight ‘desire line’ allocated to the route network with a route_ function. Route network represent many overlapping routes. All are typically stored as SpatialLinesDataFrame.
    • +
  • Origin-destination (OD) data, which report the number of people +travelling between origin-destination pairs. This type of data is not +explicitly spatial (OD datasets are usually represented as data frames) +but represents movement over space between points in geographical space. +An example is provided in the flow dataset.
    • +
  • Line data, one dimensional linear features on the surface of the +Earth. These are typically stored as a +SpatialLinesDataFrame.
    • +
  • Route data are special types of lines which have been allocated to +the transport network. Routes typically result from the allocation of a +straight ‘desire line’ allocated to the route network with a +route_ function. Route network represent many overlapping +routes. All are typically stored as +SpatialLinesDataFrame.
-

For ease of use, functions focussed on each data type have been developed with names prefixed with od_, line_ and route_ respectively. A selection of these is presented in Table 1. Additional ‘core functions’ could be developed, such as those prefixed with rn_ (for working with route network data) and g_ functions for geographic operations such as buffer creation on lat/lon projected data (this function is currently named buff_geo). We plan to elicit feedback on such changes before implementing them.

-

With a tip of the hat to the concept of type stability (e.g. as implemented in ), we also plan to make the core functions of stplanr more type-stable in future releases. Core functions, which begin with the prefixes listed above, could follow ’s lead and return only objects with the same class as that of the input. However there are limitations to this approach: it will break existing functionality and mean that output objects have a larger size than necessary (line_bearing, for example, does not need to duplicate the spatial data contained in its input). Instead, we plan to continue to name functions around the type of input data they take, but are open minded about function input-output data class conventions, especially in the context of the new class system implemented in .

-

A class system has not been developed for each data type (this option is discussed in the final section). The most common data types used in stplanr are assumed to be data frames and spatial datasets.

-

Transport datasets are very diverse. There are therefore many other functions which have more ad-hock names. Rather attempt a systematic description of each of stplanr’s functions (which can be gleaned from the online manual) it is more illuminating to see how they work together, as part of a transport planning workflow. As with most workflows, this begins with data access and ends with visualisation.

-
-
-

-Accessing and processing transport data

-

Gaining access to data is often the first stage in transport research. This is often a long and protracted process which is thankfully becoming easier thanks to the ‘open data’ movement and packages such as tigris for making data access from within R easier .

-

stplanr provides a variety of different functions that facilitate importing common data formats used for transport analysis into R. Although transport analysis generally requires some transport-specific datasets, it also typically relies heavily on common sources of data including census data. This being the case, stplanr also includes functions that may be useful to those not involved in transport research. This includes the read_table_builder function for importing data from the Australian Bureau of Statistics (ABS) and the UK’s Stats19 road traffic casualty dataset. A brief example of the latter is demonstrated below, which begins with downloading the data (warning this downloads ~100 MB of data):

-
-dl_stats19() # download and extract stats19 road traffic casualty data
-
#> [1] "Data saved at: /tmp/RtmpppF3E2/Accidents0514.csv"
-#> [2] "Data saved at: /tmp/RtmpppF3E2/Casualties0514.csv"
-#> [3] "Data saved at: /tmp/RtmpppF3E2/Vehicles0514.csv"
-

Once the data has been saved in the default directory, determined by tempdir(), it can be read-in and cleaned with the read_stats19_ functions (note these call format_stats19_ functions internally to clean the datasets and add correct labels to the variables):

-
-ac <- read_stats19_ac()
-ca <- read_stats19_ca()
-ve <- read_stats19_ve()
-

The resulting datasets (representing accident, casualty and vehicle level data, respectively) can be merged and made geographic, as illustrated below:

+

For ease of use, functions focussed on each data type have been +developed with names prefixed with od_, line_ +and route_ respectively. A selection of these is presented +in Table 1. Additional ‘core functions’ could be developed, such as +those prefixed with rn_ (for working with route network +data) and g_ functions for geographic operations such as +buffer creation on lat/lon projected data (this function is currently +named buff_geo). We plan to elicit feedback on such changes +before implementing them.

+

With a tip of the hat to the concept of type stability (e.g. as +implemented in ), we also plan to make the core functions of +stplanr more type-stable in future releases. Core +functions, which begin with the prefixes listed above, could follow ’s +lead and return only objects with the same class as that of the input. +However there are limitations to this approach: it will break existing +functionality and mean that output objects have a larger size than +necessary (line_bearing, for example, does not need to +duplicate the spatial data contained in its input). Instead, we plan to +continue to name functions around the type of input data they +take, but are open minded about function input-output data class +conventions, especially in the context of the new class system +implemented in .

+

A class system has not been developed for each data type (this option +is discussed in the final section). The most common data types used in +stplanr are assumed to be data frames and spatial +datasets.

+

Transport datasets are very diverse. There are therefore many other +functions which have more ad-hock names. Rather attempt a systematic +description of each of stplanr’s functions (which can +be gleaned from the online manual) it is more illuminating to see how +they work together, as part of a transport planning workflow. As with +most workflows, this begins with data access and ends with +visualisation.

+
+
+

Accessing and processing transport data +

+

Gaining access to data is often the first stage in transport +research. This is often a long and protracted process which is +thankfully becoming easier thanks to the ‘open data’ movement and +packages such as tigris for making data access from +within R easier .

+

stplanr provides a variety of different functions +that facilitate importing common data formats used for transport +analysis into R. Although transport analysis generally requires some +transport-specific datasets, it also typically relies heavily on common +sources of data including census data. This being the case, +stplanr also includes functions that may be useful to +those not involved in transport research. This includes the +read_table_builder function for importing data from the +Australian Bureau of Statistics (ABS) and the UK’s Stats19 road traffic +casualty dataset. A brief example of the latter is demonstrated below, +which begins with downloading the data (warning this downloads ~100 MB +of data):

+
+dl_stats19() # download and extract stats19 road traffic casualty data
+
#> [1] "Data saved at: /tmp/RtmpppF3E2/Accidents0514.csv"
+#> [2] "Data saved at: /tmp/RtmpppF3E2/Casualties0514.csv"
+#> [3] "Data saved at: /tmp/RtmpppF3E2/Vehicles0514.csv"
+

Once the data has been saved in the default directory, determined by +tempdir(), it can be read-in and cleaned with the +read_stats19_ functions (note these call +format_stats19_ functions internally to clean the datasets +and add correct labels to the variables):

-library(dplyr)
-ca_ac <- inner_join(ca, ac)
-ca_cycle <- ca_ac %>%
-  filter(Casualty_Severity == "Fatal" & !is.na(Latitude)) %>%
-  select(Age = Age_of_Casualty, Mode = Casualty_Type, Longitude, Latitude)
-ca_sp <- SpatialPointsDataFrame(coords = ca_cycle[3:4], data = ca_cycle[1:2])
-

Now that this casualty data has been cleaned, subsetted (to only include serious cycle crashes) and converted into a spatial class system, we can analyse them using geographical datasets of the type commonly used by stplanr. The following code, for example, geographically subsets the dataset to include only crashes that occured within the bounding box of a route network dataset provided by stplanr (from version 0.1.7 and beyond) using the function bb2poly, which converts a spatial dataset into a box, represented as a rectangular SpatialPolygonsDataFrame:

+ac <- read_stats19_ac() +ca <- read_stats19_ca() +ve <- read_stats19_ve()
+

The resulting datasets (representing accident, casualty and vehicle +level data, respectively) can be merged and made geographic, as +illustrated below:

-data("route_network") # devtools::install_github("ropensci/splanr")version 0.1.7
-proj4string(ca_sp) <- proj4string(route_network)
-bb <- bb2poly(route_network)
-proj4string(bb) <- proj4string(route_network)
-ca_local <- ca_sp[bb, ]
-

The above code chunk shows the importance of understanding geographical data when working with transport data. It is only by converting the casualty data into a spatial data class, and adding a coordinate reference system (CRS), that transport planners and researchers can link this important dataset back to the route network. We can now perform GIS operations on the results. The next code chunk, for example, finds all the fatalities that took place within 100 m of the route network, using the function buff_geo:

+library(dplyr) +ca_ac <- inner_join(ca, ac) +ca_cycle <- ca_ac %>% + filter(Casualty_Severity == "Fatal" & !is.na(Latitude)) %>% + select(Age = Age_of_Casualty, Mode = Casualty_Type, Longitude, Latitude) +ca_sp <- SpatialPointsDataFrame(coords = ca_cycle[3:4], data = ca_cycle[1:2])
+

Now that this casualty data has been cleaned, subsetted (to only +include serious cycle crashes) and converted into a spatial class +system, we can analyse them using geographical datasets of the type +commonly used by stplanr. The following code, for +example, geographically subsets the dataset to include only crashes that +occured within the bounding box of a route network dataset provided by +stplanr (from version 0.1.7 and beyond) using the +function bb2poly, which converts a spatial dataset into a +box, represented as a rectangular +SpatialPolygonsDataFrame:

-rnet_buff_100 <- geo_buffer(route_network, width = 100)
-ca_buff <- ca_local[rnet_buff_100, ]
-

These can be visualised using base R graphics, extended by , as illustrated in Figure . This provides a good start for analysis but for publication-quality plots and interactive plots, designed for public engagement, we recommend using dedicated visualisation packages that work with spatial data such as .

+data("route_network") # devtools::install_github("ropensci/splanr")version 0.1.7 +proj4string(ca_sp) <- proj4string(route_network) +bb <- bb2poly(route_network) +proj4string(bb) <- proj4string(route_network) +ca_local <- ca_sp[bb, ]
+

The above code chunk shows the importance of understanding +geographical data when working with transport data. It is only by +converting the casualty data into a spatial data class, and adding a +coordinate reference system (CRS), that transport planners and +researchers can link this important dataset back to the route network. +We can now perform GIS operations on the results. The next code chunk, +for example, finds all the fatalities that took place within 100 m of +the route network, using the function buff_geo:

-plot(bb, lty = 4)
-plot(rnet_buff_100, col = "grey", add = TRUE)
-points(ca_local, pch = 4)
-points(ca_buff, cex = 3)
-
-
-

-Creating geographic desire lines

-

Perhaps the most common type of aggregate-level transport information is origin-destination (‘OD’) data. This can be presented either as a matrix or (more commonly) a long table of OD pairs. An example of this type of raw data is provided below (see ?flow to see how this dataset was created).

+rnet_buff_100 <- geo_buffer(route_network, width = 100) +ca_buff <- ca_local[rnet_buff_100, ]
+

These can be visualised using base R graphics, extended by , as +illustrated in Figure \(\ref{fig:fats}\). This provides a good +start for analysis but for publication-quality plots and interactive +plots, designed for public engagement, we recommend using dedicated +visualisation packages that work with spatial data such as .

-data("flow", package = "stplanr")
-head(flow[c(1:3, 12)])
-

Although the flow data displayed above describes movement over geographical space, it contains no explicitly geographical information. Instead, the coordinates of the origins and destinations are linked to a separate geographical dataset which also must be loaded to analyse the flows. This is a common problem solved by the function od2line. The geographical data is a set of points representing centroids of the origin and destinations, saved as a SpatialPointsDataFrame. Geographical data in R is best represented as such Spatial* objects, which use the S4 object engine. This explains the close integration of stplanr with R’s spatial packages, especially sp, which defines the S4 spatial object system.

+plot(bb, lty = 4) +plot(rnet_buff_100, col = "grey", add = TRUE) +points(ca_local, pch = 4) +points(ca_buff, cex = 3)
+
+
+

Creating geographic desire lines +

+

Perhaps the most common type of aggregate-level transport information +is origin-destination (‘OD’) data. This can be presented either as a +matrix or (more commonly) a long table of OD pairs. An example of this +type of raw data is provided below (see ?flow to see how +this dataset was created).

-data("cents", package = "stplanr")
-as.data.frame(cents[1:3, -c(3, 4)])
-

We use od2line to combine flow and cents, to join the former to the latter. We will visualise the l object created below in the next section.

+data("flow", package = "stplanr") +head(flow[c(1:3, 12)])
+

Although the flow data displayed above describes movement over +geographical space, it contains no explicitly geographical information. +Instead, the coordinates of the origins and destinations are linked to a +separate geographical dataset which also must be loaded to analyse the +flows. This is a common problem solved by the function +od2line. The geographical data is a set of points +representing centroids of the origin and destinations, saved as a +SpatialPointsDataFrame. Geographical data in R is best +represented as such Spatial* objects, which use the +S4 object engine. This explains the close integration of +stplanr with R’s spatial packages, especially +sp, which defines the S4 spatial object +system.

-l <- od2line(flow = flow, zones = cents)
-

The data is now in a form that is much easier to analyse. We can plot the data with the command plot(l), which was not possible before. Because the SpatialLinesDataFrame object also contains data per line, it also helps with visualisation of the flows, as illustrated in Figure .

-
-
-

-Allocating flows to the transport network

-

A common problem faced by transport researchers is network allocation: converting the ‘as the crow flies’ lines illustrated in the figure above into routes. These are the complex, winding paths that people and animals make to avoid obstacles such as buildings and to make the journey faster and more efficient (e.g. by following the route network).

-

This is difficult (and was until recently near impossible using free software) because of the size and complexity of transport networks, the complexity of realistic routing algorithms and need for context-specificity in the routing engine. Inexperienced cyclists, for example, would take a very different route than a heavy goods vehicle. stplanr tackles this issue by using 3rd party APIs to provide route-allocation.

-

Route allocation is undertaken by functions such as and . These allocate a single OD pair, represented as a text string to be ‘geo-coded,’ a pair of of coordinates, or two SpatialPoints objects, representing origins and destinations. This is illustrated below with route_cyclestreet, which uses the CycleStreets.net API, a routing service “by cyclists for cyclists” that offers a range route strategies (primarily ‘fastest,’ ‘quietest’ and ‘balanced’) that are based on a detailed analysis of cyclist wayfinding:2

+data("cents", package = "stplanr") +as.data.frame(cents[1:3, -c(3, 4)])
+

We use od2line to combine flow and +cents, to join the former to the latter. We will visualise +the l object created below in the next section.

-route_bl <- route_cyclestreets(from = "Bradford", to = "Leeds")
-route_c1_c2 <- route_cyclestreets(cents[1, ], cents[2, ])
-

The raw output from routing APIs is usually provided as a JSON or GeoJSON text string. By default, route_cyclestreet saves a number of key variables (including length, time, hilliness and busyness variables generated by CycleStreets.net) from the attribute data provided by the API. If the user wants to save the raw output, the save_raw argument can be used:

+l <- od2line(flow = flow, zones = cents)
+

The data is now in a form that is much easier to analyse. We can plot +the data with the command plot(l), which was not possible +before. Because the SpatialLinesDataFrame object also +contains data per line, it also helps with visualisation of the flows, +as illustrated in Figure \(\ref{fig:lines_routes}\).

+
+
+

Allocating flows to the transport network +

+

A common problem faced by transport researchers is network +allocation: converting the ‘as the crow flies’ lines illustrated in the +figure above into routes. These are the complex, winding paths that +people and animals make to avoid obstacles such as buildings and to make +the journey faster and more efficient (e.g. by following the route +network).

+

This is difficult (and was until recently near impossible using free +software) because of the size and complexity of transport networks, the +complexity of realistic routing algorithms and need for +context-specificity in the routing engine. Inexperienced cyclists, for +example, would take a very different route than a heavy goods vehicle. +stplanr tackles this issue by using 3rd party APIs to +provide route-allocation.

+

Route allocation is undertaken by functions such as and . These +allocate a single OD pair, represented as a text string to be +‘geo-coded’, a pair of of coordinates, or two SpatialPoints +objects, representing origins and destinations. This is illustrated +below with route_cyclestreet, which uses the CycleStreets.net API, a +routing service “by cyclists for cyclists” that offers a range route +strategies (primarily ‘fastest’, ‘quietest’ and ‘balanced’) that are +based on a detailed analysis of cyclist wayfinding:2

-route_bl_raw <- route_cyclestreets(from = "Bradford", to = "Leeds", save_raw = TRUE)
-

Additional arguments taken by the route_ functions depend on the routing function in question. By changing the plan argument of route_cyclestreet to fastest, quietest or balanced, for example, routes favouring speed, quietness or a balance between speed and quietness will be saved, respectively.

-

To automate the creation of route-allocated lines over many desire lines, the line2route function loops over each line, wrapping any route_ function as an input. The output is a SpatialLinesDataFrame with the same number of dimensions as the input dataset (see the right panel in Figure ).

-
routes_fast <- line2route(l = l, route_fun = route_cyclestreet)
-

The result of this ‘batch routing’ exercise is illustrated in Figure . The red lines in the left hand panel are very different from the hypothetical straight ‘desire lines’ often used in transport research, highlighting the importance of this route-allocation functionality.

-
-plot(route_network, lwd = 0)
-plot(l, lwd = l$All / 10, add = TRUE)
-lines(routes_fast, col = "red")
-routes_fast$All <- l$All
-rnet <- overline(routes_fast, "All", fun = sum)
-rnet$flow <- rnet$All / mean(rnet$All) * 3
-plot(rnet, lwd = rnet$flow / mean(rnet$flow))
-

To estimate the amount of capacity needed at each segment on the transport network, the overline function demonstrated above, is used to divide line geometries into unique segments and aggregate the overlapping values. The results, illustrated in the right-hand panel of Figure , can be used to estimate where there is most need to improve the transport network, for example informing the decision of where to build new bicycle paths.

-

Limitations with the route_cyclestreet routing API include its specificity, to one mode (cycling) and a single region (the UK and part of Europe). To overcome these limitations, additional routing APIs were added with the functions route_graphhopper, route_transportapi_public and viaroute. These interface to Graphhopper, TransportAPI and the Open Source Routing Machine (OSRM) routing services, respectively. The great advantage of OSRM is that it allows you to run your own routing services on a local server, greatly increasing the rate of route generation.

-

A short example of finding the route by car and bike between New York and Oaxaca demonstrates how route_graphhopper can collect geographical and other data on routes by various modes, anywhere in the world. The output, shown in Table , shows that the function also saves time, distance and (for bike trips) vertical distance climbed for the trips.

+route_bl <- route_cyclestreets(from = "Bradford", to = "Leeds") +route_c1_c2 <- route_cyclestreets(cents[1, ], cents[2, ])
+

The raw output from routing APIs is usually provided as a JSON or +GeoJSON text string. By default, route_cyclestreet saves a +number of key variables (including length, time, hilliness and busyness +variables generated by CycleStreets.net) from the attribute data +provided by the API. If the user wants to save the raw output, the +save_raw argument can be used:

+
+route_bl_raw <- route_cyclestreets(from = "Bradford", to = "Leeds", save_raw = TRUE)
+

Additional arguments taken by the route_ functions +depend on the routing function in question. By changing the +plan argument of route_cyclestreet to +fastest, quietest or balanced, +for example, routes favouring speed, quietness or a balance between +speed and quietness will be saved, respectively.

+

To automate the creation of route-allocated lines over many desire +lines, the line2route function loops over each line, +wrapping any route_ function as an input. The output is a +SpatialLinesDataFrame with the same number of dimensions as +the input dataset (see the right panel in Figure \(\ref{fig:lines_routes}\)).

+
routes_fast <- line2route(l = l, route_fun = route_cyclestreet)
+

The result of this ‘batch routing’ exercise is illustrated in Figure +\(\ref{fig:lines_routes}\). The red +lines in the left hand panel are very different from the hypothetical +straight ‘desire lines’ often used in transport research, highlighting +the importance of this route-allocation functionality.

-ny2oaxaca1 <- route_graphhopper("New York", "Oaxaca", vehicle = "bike")
-ny2oaxaca2 <- route_graphhopper("New York", "Oaxaca", vehicle = "car")
-rbind(ny2oaxaca1@data, ny2oaxaca2@data)
+plot(route_network, lwd = 0) +plot(l, lwd = l$All / 10, add = TRUE) +lines(routes_fast, col = "red") +routes_fast$All <- l$All +rnet <- overline(routes_fast, "All", fun = sum) +rnet$flow <- rnet$All / mean(rnet$All) * 3 +plot(rnet, lwd = rnet$flow / mean(rnet$flow)) +

To estimate the amount of capacity needed at each segment on the +transport network, the overline function demonstrated +above, is used to divide line geometries into unique segments and +aggregate the overlapping values. The results, illustrated in the +right-hand panel of Figure \(\ref{fig:lines_routes}\), can be used to +estimate where there is most need to improve the transport network, for +example informing the decision of where to build new bicycle paths.

+

Limitations with the route_cyclestreet routing API +include its specificity, to one mode (cycling) and a single region (the +UK and part of Europe). To overcome these limitations, additional +routing APIs were added with the functions +route_graphhopper, route_transportapi_public +and viaroute. These interface to Graphhopper, TransportAPI +and the Open Source Routing Machine (OSRM) routing services, +respectively. The great advantage of OSRM is that it allows you to run +your own routing services on a local server, greatly increasing the rate +of route generation.

+

A short example of finding the route by car and bike between New York +and Oaxaca demonstrates how route_graphhopper can collect +geographical and other data on routes by various modes, anywhere in the +world. The output, shown in Table \(\ref{tab:xtnyoa}\), shows that the function +also saves time, distance and (for bike trips) vertical distance climbed +for the trips.

+
+ny2oaxaca1 <- route_graphhopper("New York", "Oaxaca", vehicle = "bike")
+ny2oaxaca2 <- route_graphhopper("New York", "Oaxaca", vehicle = "car")
+rbind(ny2oaxaca1@data, ny2oaxaca2@data)
@@ -285,292 +578,528 @@

time
-
-

-Modelling travel catchment areas

-

Accessibility to transport services is a particularly important topic when considering public transport or active travel because of the frequent steep reduction in use as distances to access services (or infrastructure) increase. As a result, the planning for transport services and infrastructure frequently focuses on several measures of accessibility including distance, but also travel times and frequencies and weighted by population. The functions in stplanr are intended to provide a method of estimating these accessibility measures as well as calculating the population that can access specific services (i.e., estimating the catchment area).

-

Catchment areas in particular are a widely used measure of accessibility that attempts to both quantify the likely target group for a particular service, and visualise the geographic area that is covered by the service. For instance, passengers are often said to be willing to walk up to 400 metres to a bus stop, or 800 metres to a railway station . Although these distances may appear relatively arbitrary and have been found to underestimate the true catchment area of bus stops and railway stations they nonetheless represent a good, albeit somewhat conservative, starting point from which catchment areas can be determined.

-

In many cases, catchment areas are calculated on the basis of straight-line (or “as the crow flies”) distances. This is a simplistic, but relatively appealing approach because it requires little additional data and is straight-forward to understand. stplanr provides functionality that calculates catchment areas using straight-line distances with the calc_catchment function. This function takes a SpatialPolygonsDataFrame that contains the population (or other) data, typically from a census, and a Spatial* layer that contains the geometry of the transport facility. These two layers are overlayed to calculate statistics for the desired catchments including proportioning polygons to account for the proportion located within the catchment area.

-

To illustrate how catchment areas can be calculated, stplanr contains some sample datasets stored in ESRI Shapefile format (a commonly used format for distributing GIS layers) that can together be used to calculate sample catchment areas. One of these datasets (smallsa1) contains population data for Statistical Area 1 (SA1) zones in Sydney, Australia. The second contains hypothetical cycleways aligned to streets in Sydney. The code below unzips the datasets and reads in the shapefiles.

-
-data_dir <- system.file("extdata", package = "stplanr")
-unzip(file.path(data_dir, "smallsa1.zip"))
-unzip(file.path(data_dir, "testcycleway.zip"))
-sa1income <- as(sf::read_sf("smallsa1.shp"), "Spatial")
-testcycleway <- as(sf::read_sf("testcycleway.shp"), "Spatial")
-# Remove unzipped files
-file.remove(list.files(pattern = "^(smallsa1|testcycleway).*"))
-

Calculating the catchment area is straightforward and in addition to specifying the required datasets, only a vector containing column names to calculate statistics and a distance is required. Since proportioning the areas assumes projected data, unprojected data are automatically projected to either a common projection (if one is already projected) or a specified projection. It should be emphasised that the choice of projection is important and has an effect on the results meaning setting a local projection is recommended to achieve the most accurate results.

+
+

Modelling travel catchment areas +

+

Accessibility to transport services is a particularly important topic +when considering public transport or active travel because of the +frequent steep reduction in use as distances to access services (or +infrastructure) increase. As a result, the planning for transport +services and infrastructure frequently focuses on several measures of +accessibility including distance, but also travel times and frequencies +and weighted by population. The functions in stplanr +are intended to provide a method of estimating these accessibility +measures as well as calculating the population that can access specific +services (i.e., estimating the catchment area).

+

Catchment areas in particular are a widely used measure of +accessibility that attempts to both quantify the likely target group for +a particular service, and visualise the geographic area that is covered +by the service. For instance, passengers are often said to be willing to +walk up to 400 metres to a bus stop, or 800 metres to a railway station +. Although these distances may appear relatively arbitrary and have been +found to underestimate the true catchment area of bus stops and railway +stations they nonetheless represent a good, albeit somewhat +conservative, starting point from which catchment areas can be +determined.

+

In many cases, catchment areas are calculated on the basis of +straight-line (or “as the crow flies”) distances. This is a simplistic, +but relatively appealing approach because it requires little additional +data and is straight-forward to understand. stplanr +provides functionality that calculates catchment areas using +straight-line distances with the calc_catchment function. +This function takes a SpatialPolygonsDataFrame that +contains the population (or other) data, typically from a census, and a +Spatial* layer that contains the geometry of the transport +facility. These two layers are overlayed to calculate statistics for the +desired catchments including proportioning polygons to account for the +proportion located within the catchment area.

+

To illustrate how catchment areas can be calculated, +stplanr contains some sample datasets stored in ESRI +Shapefile format (a commonly used format for distributing GIS layers) +that can together be used to calculate sample catchment areas. One of +these datasets (smallsa1) contains population data for +Statistical Area 1 (SA1) zones in Sydney, Australia. The second contains +hypothetical cycleways aligned to streets in Sydney. The code below +unzips the datasets and reads in the shapefiles.

-catch800m <- calc_catchment(
-  polygonlayer = sa1income,
-  targetlayer = testcycleway,
-  calccols = c("Total"),
-  distance = 800,
-  projection = "austalbers",
-  dissolve = TRUE
-)
-

By looking at the data.frame associated with the SpatialPolygonsDataFrame that is returned from the calc_catchment function, the total population within the catchment area can be seen to be nearly 40,000 people. The catchment area can also be plotted as with any other Spatial* object using the plot function using the code below with the result shown in Figure .

+data_dir <- system.file("extdata", package = "stplanr") +unzip(file.path(data_dir, "smallsa1.zip")) +unzip(file.path(data_dir, "testcycleway.zip")) +sa1income <- as(sf::read_sf("smallsa1.shp"), "Spatial") +testcycleway <- as(sf::read_sf("testcycleway.shp"), "Spatial") +# Remove unzipped files +file.remove(list.files(pattern = "^(smallsa1|testcycleway).*"))
+

Calculating the catchment area is straightforward and in addition to +specifying the required datasets, only a vector containing column names +to calculate statistics and a distance is required. Since proportioning +the areas assumes projected data, unprojected data are automatically +projected to either a common projection (if one is already projected) or +a specified projection. It should be emphasised that the choice of +projection is important and has an effect on the results meaning setting +a local projection is recommended to achieve the most accurate +results.

-plot(sa1income, col = "light grey")
-plot(catch800m, col = rgb(1, 0, 0, 0.5), add = TRUE)
-plot(testcycleway, col = "green", add = TRUE)
-

This simplistic catchment area is useful when the straight-line distance is a reasonable approximation of the route taken to walk (or cycle) to a transport facility. However, this is often not the case. The catchment area in Figure initially appears reasonable but the red-shaded catchment area includes an area that requires travelling around a bay to access from the (green-coloured) cycleway. To allow for more realistic catchment areas for most situations, stplanr provides the calc_network_catchment function that uses the same principle as calc_catchment but also takes into account the transport network.

-

To use calc_network_catchment, a transport network needs to be prepared that can be used in conjunction with the previous datasets. Preparation of the dataset involves using the SpatialLinesNetwork function to create a network from a SpatialLinesDataFrame. This function combines a SpatialLinesDataFrame with a graph network (using the package) to provide basic routing functionality. The network is used to calculate the shortest actual paths within the specific catchment distance. This process involves the following code:

+remotes::install_github("ropensci/stplanr") +catch800m <- calc_catchment( + polygonlayer = sa1income, + targetlayer = testcycleway, + calccols = c("Total"), + distance = 800, + projection = "austalbers", + dissolve = TRUE +)
+

By looking at the data.frame associated with the +SpatialPolygonsDataFrame that is returned from the +calc_catchment function, the total population within the +catchment area can be seen to be nearly 40,000 people. The catchment +area can also be plotted as with any other Spatial* object +using the plot function using the code below with the +result shown in Figure \(\ref{fig:catchmentplot}\).

-unzip(file.path(data_dir, "sydroads.zip"))
-sydroads <- as(sf::read_sf(".", "roads"), "Spatial")
-file.remove(list.files(pattern = "^(roads).*"))
-sydnetwork <- SpatialLinesNetwork(sydroads)
-

The network catchment is then calculated using a similar method as with calc_catchment but with a few minor changes. Specifically these are including the SpatialLinesNetwork, and using the maximpedance parameter to define the distance, with distance being the additional distance from the network. In contrast to the distance parameter that is based on the straight-line distance in both the calc_catchment and calc_network_catchment functions, the maximpedance parameter is the maximum value in the units of the network’s weight attribute. In practice this is generally distance in metres but can also be travel times, risk or other measures.

+plot(sa1income, col = "light grey") +plot(catch800m, col = rgb(1, 0, 0, 0.5), add = TRUE) +plot(testcycleway, col = "green", add = TRUE) +

This simplistic catchment area is useful when the straight-line +distance is a reasonable approximation of the route taken to walk (or +cycle) to a transport facility. However, this is often not the case. The +catchment area in Figure \(\ref{fig:catchmentplot}\) initially appears +reasonable but the red-shaded catchment area includes an area that +requires travelling around a bay to access from the (green-coloured) +cycleway. To allow for more realistic catchment areas for most +situations, stplanr provides the +calc_network_catchment function that uses the same +principle as calc_catchment but also takes into account the +transport network.

+

To use calc_network_catchment, a transport network needs +to be prepared that can be used in conjunction with the previous +datasets. Preparation of the dataset involves using the +SpatialLinesNetwork function to create a network from a +SpatialLinesDataFrame. This function combines a +SpatialLinesDataFrame with a graph network (using the +package) to provide basic routing functionality. The network is used to +calculate the shortest actual paths within the specific catchment +distance. This process involves the following code:

-netcatch800m <- calc_network_catchment(
-  sln = sydnetwork,
-  polygonlayer = sa1income,
-  targetlayer = testcycleway,
-  calccols = c("Total"),
-  maximpedance = 800,
-  distance = 100,
-  projection = "austalbers"
-)
-

Once calculated, the network catchment area can be used just as the straight-line network catchment. This includes extracting the catchment population of 128,000 and plotting the original catchment area together with the original area with the results shown in Figure :

+unzip(file.path(data_dir, "sydroads.zip")) +sydroads <- as(sf::read_sf(".", "roads"), "Spatial") +file.remove(list.files(pattern = "^(roads).*")) +sydnetwork <- SpatialLinesNetwork(sydroads) +

The network catchment is then calculated using a similar method as +with calc_catchment but with a few minor changes. +Specifically these are including the SpatialLinesNetwork, +and using the maximpedance parameter to define the +distance, with distance being the additional distance from the network. +In contrast to the distance parameter that is based on the straight-line +distance in both the calc_catchment and +calc_network_catchment functions, the +maximpedance parameter is the maximum value in the units of +the network’s weight attribute. In practice this is generally distance +in metres but can also be travel times, risk or other measures.

-plot(sa1income, col = "light grey")
-plot(catch800m, col = rgb(1, 0, 0, 0.5), add = TRUE)
-plot(netcatch800m, col = rgb(0, 0, 1, 0.5), add = TRUE)
-plot(testcycleway, col = "green", add = TRUE)
- - -
-

-Modelling and visualisation

-
-

-Modelling mode choice

-

Route-allocated lines allow estimation of route distance and cirquity (route distance divided by Euclidean distance). These variables can help model the rate of flow between origins and destination, as illustrated in the left-hand panel of Figure . The code below demonstrates how objects generated by stplanr can be used to undertake such analysis, with the line_length function used to find the distance, in meters, of lat/lon data.

-
l$d_euclidean <- line_length(l)
-l$d_rf <- routes_fast@data$length
-plot(l$d_euclidean, l$d_rf,
-  xlab = "Euclidean distance", ylab = "Route distance")
-abline(a = 0, b = 1)
-abline(a = 0, b = 1.2, col = "green")
-abline(a = 0, b = 1.5, col = "red")
-

The left hand panel of Figure shows the expected strong correlation between Euclidean (\(d_E\)) and fastest route (\(d_{Rf}\)) distance. However, some OD pairs have a proportionally higher route distance than others, as illustrated by distance from the black line in the above plot: this represents : the ratio of network distance to Euclidean distance :

+netcatch800m <- calc_network_catchment( + sln = sydnetwork, + polygonlayer = sa1income, + targetlayer = testcycleway, + calccols = c("Total"), + maximpedance = 800, + distance = 100, + projection = "austalbers" +)
+

Once calculated, the network catchment area can be used just as the +straight-line network catchment. This includes extracting the catchment +population of 128,000 and plotting the original catchment area together +with the original area with the results shown in Figure \(\ref{fig:netcatchplot}\):

+
+plot(sa1income, col = "light grey")
+plot(catch800m, col = rgb(1, 0, 0, 0.5), add = TRUE)
+plot(netcatch800m, col = rgb(0, 0, 1, 0.5), add = TRUE)
+plot(testcycleway, col = "green", add = TRUE)
+
+ +
+

Modelling and visualisation +

+
+

Modelling mode choice +

+

Route-allocated lines allow estimation of route distance and +cirquity (route distance divided by Euclidean distance). These +variables can help model the rate of flow between origins and +destination, as illustrated in the left-hand panel of Figure \(\ref{fig:euclidfastest}\). The code below +demonstrates how objects generated by stplanr can be +used to undertake such analysis, with the line_length +function used to find the distance, in meters, of lat/lon data.

+
l$d_euclidean <- line_length(l)
+l$d_rf <- routes_fast@data$length
+plot(l$d_euclidean, l$d_rf,
+  xlab = "Euclidean distance", ylab = "Route distance")
+abline(a = 0, b = 1)
+abline(a = 0, b = 1.2, col = "green")
+abline(a = 0, b = 1.5, col = "red")
+

The left hand panel of Figure \(\ref{fig:euclidfastest}\) shows the +expected strong correlation between Euclidean (\(d_E\)) and fastest route (\(d_{Rf}\)) distance. However, some OD pairs +have a proportionally higher route distance than others, as illustrated +by distance from the black line in the above plot: this represents : the +ratio of network distance to Euclidean distance :

\[ - Q = \frac{d_{Rf}}{d_E} +Q = \frac{d_{Rf}}{d_E} \]

-

An extension to the concept of cirquity is the ‘quietness diversion factor’ (\(QDF\)) of a desire line , the ratio of the route distance of a quiet route option (\(d_{Rq}\)) to that of the fastest:

+

An extension to the concept of cirquity is the ‘quietness diversion +factor’ (\(QDF\)) of a desire line , +the ratio of the route distance of a quiet route option (\(d_{Rq}\)) to that of the fastest:

\[ - QDF = \frac{d_{Rq}}{d_{Rf}} +QDF = \frac{d_{Rq}}{d_{Rf}} \]

-

Thanks to the ‘quietest’ route option provided by route_cyclestreet, we can estimate average values for both metrics as follows:

-
-routes_slow <- line2route(l, route_cyclestreet, plan = "quietest")
+

Thanks to the ‘quietest’ route option provided by +route_cyclestreet, we can estimate average values for both +metrics as follows:

-l$d_rq <- routes_slow$length # quietest route distance
-Q <- mean(l$d_rf / l$d_euclidean, na.rm = TRUE)
-QDF <- mean(l$d_rq / l$d_rf, na.rm = TRUE)
-Q
-QDF
-

The results show that cycle paths are not particularly direct in the study region by international standards . This is hardly surprisingly given the small size of the sample and the short distances covered: \(Q\) tends to decrease at a decaying rate with distance. What is surprising is that \(QDF\) is close to unity, which could imply that the quiet routes are constructed along direct, and therefore sensible routes. We should caution against such assumptions, however: It is a small sample of desire lines and, when time is explored, we find that the ‘quietness diversion factor with respect to time’ (\(QDF_t\)) is slightly larger:

+routes_slow <- line2route(l, route_cyclestreet, plan = "quietest")
-(QDFt <- mean(routes_slow$time / routes_fast$time, na.rm = TRUE))
-
-
-

-Models of travel behaviour

-

There are many ways of estimating flows between origins and destinations, including spatial interaction models, the four-stage transport model and gravity models (‘distance decay’). stplanr aims eventually to facilitate creation of many types of flow model.

-

At present there are no functions for modelling distance decay, but this is something we would like to add in future versions of stplanr. Distance decay is an especially important concept for sustainable transport planning due to physical limitations on the ability of people to walk and cycle large distances .

-

We can explore the relationship between distance and the proportion of trips made by walking, using the same object l generated by stplanr.

+l$d_rq <- routes_slow$length # quietest route distance +Q <- mean(l$d_rf / l$d_euclidean, na.rm = TRUE) +QDF <- mean(l$d_rq / l$d_rf, na.rm = TRUE) +Q +QDF
+

The results show that cycle paths are not particularly direct in the +study region by international standards . This is hardly surprisingly +given the small size of the sample and the short distances covered: +\(Q\) tends to decrease at a decaying +rate with distance. What is surprising is that \(QDF\) is close to unity, which could imply +that the quiet routes are constructed along direct, and therefore +sensible routes. We should caution against such assumptions, however: It +is a small sample of desire lines and, when time is explored, we find +that the ‘quietness diversion factor with respect to time’ (\(QDF_t\)) is slightly larger:

-l$pwalk <- l$On.foot / l$All
-plot(l$d_euclidean, l$pwalk,
-  cex = l$All / 50,
-  xlab = "Euclidean distance (m)", ylab = "Proportion of trips by foot"
-)
-

Based on the right-hand panel in Figure , there is a clear negative relationship between distance of trips and the proportion of those trips made by walking. This is unsurprising: beyond a certain distance (around 1.5km according the the data presented in the figure above) walking is usually seen as too slow and other modes are considered. According to the academic literature, this ‘distance decay’ is non-linear and there have been a number of functions proposed to fit to distance decay curves . From the range of options we test below just two forms. We will compare the ability of linear and log-square-root functions to fit the data contained in l for walking.

+(QDFt <- mean(routes_slow$time / routes_fast$time, na.rm = TRUE)) + +
+

Models of travel behaviour +

+

There are many ways of estimating flows between origins and +destinations, including spatial interaction models, the four-stage +transport model and gravity models (‘distance decay’). +stplanr aims eventually to facilitate creation of many +types of flow model.

+

At present there are no functions for modelling distance decay, but +this is something we would like to add in future versions of +stplanr. Distance decay is an especially important +concept for sustainable transport planning due to physical limitations +on the ability of people to walk and cycle large distances .

+

We can explore the relationship between distance and the proportion +of trips made by walking, using the same object l generated +by stplanr.

-lm1 <- lm(pwalk ~ d_euclidean, data = l@data, weights = All)
-lm2 <- lm(pwalk ~ d_rf, data = l@data, weights = All)
-lm3 <- glm(pwalk ~ d_rf + I(d_rf^0.5),
-  data = l@data, weights = All, family = quasipoisson(link = "log")
-)
-

The results of these regression models can be seen using summary(). Surprisingly, Euclidean distance was a better predictor of walking than route distance, but no strong conclusions can be drawn from this finding, with such a small sample of desire lines (n = 42). The results are purely illustrative, of the kind of the possibilities created by using stplanr in conjuction with R’s modelling capabilities (see Figure ).

+l$pwalk <- l$On.foot / l$All +plot(l$d_euclidean, l$pwalk, + cex = l$All / 50, + xlab = "Euclidean distance (m)", ylab = "Proportion of trips by foot" +)
+

Based on the right-hand panel in Figure \(\ref{fig:euclidfastest}\), there is a clear +negative relationship between distance of trips and the proportion of +those trips made by walking. This is unsurprising: beyond a certain +distance (around 1.5km according the the data presented in the figure +above) walking is usually seen as too slow and other modes are +considered. According to the academic literature, this ‘distance decay’ +is non-linear and there have been a number of functions proposed to fit +to distance decay curves . From the range of options we test below just +two forms. We will compare the ability of linear and log-square-root +functions to fit the data contained in l for walking.

-plot(l$d_euclidean, l$pwalk,
-  cex = l$All / 50,
-  xlab = "Euclidean distance (m)", ylab = "Proportion of trips by foot"
-)
-l2 <- data.frame(d_euclidean = 1:5000, d_rf = 1:5000)
-lm1p <- predict(lm1, l2)
-lm2p <- predict(lm2, l2)
-lm3p <- predict(lm3, l2)
-lines(l2$d_euclidean, lm1p)
-lines(l2$d_euclidean, exp(lm2p), col = "green")
-lines(l2$d_euclidean, exp(lm3p), col = "red")
- -
-

-Visualisation

-

Visualisation is an important aspect of any transport study, as it enables researchers to communicate their findings to other researchers, policy-makers and, ultimately, the public. It may therefore come as a surprise that stplanr contains no functions for visualisation. Instead, users are encouraged to make use of existing spatial visualisation tools in R, such as tmap, leaflet and ggmap .

-

Furthermore, with the development of online application frameworks such as shiny, it is now easier than ever to make the results of transport analysis and modelling projects available to the public. An example is the online interface of the Propensity to Cycle Tool (PCT). The results of the project, generated using stplanr, are presented at zone, desire line and Route Network levels . There is great potential to expand on the principle of publicly accessible transport planning tools via ‘web apps,’ perhaps through new R packages dedicated to visualising transport data.

-
- -
-

-Future directions of travel

-

This paper has demonstrated the great potential for R to be used for transport planning. R’s flexibility, powerful GIS capabilities and free accessibility makes it well-suited to the needs of transport planners and researchers, especially those wanting to avoid the high costs of market-leading products. Rather than ‘reinvent the wheel’ (e.g. with a new class system), stplanr builds on existing packages and classes to work with common transport data formats.

-

It is useful to see stplanr, and R for transport planning in general, as an addition tool in the transport planner’s cabinet. It can be understood as one part of a wider movement that is making transport planning a more open and democratic process. Other developments in this movement include the increasing availability of open data and the rise of open source products for transport modelling, such as SUMO, MATSim and MITSIMLAB . stplanr, with its focus on GIS operations rather than microscopic vehicle-level behaviour, can complement such software and help make better use of new open data sources.

-

Because transport planning is an inherently spatial activity, stplanr occupies an important niche in the transport planning software landscape, with its focus on spatial transport data. There is great potential for development of stplanr in many directions. Desirable developments include the additional of functions for modelling modal split, for examample with functions to create commonly distance decay curves which are commonly found in active travel research and improving the computational efficiency of existing functions to make the methods more scalable for large databases. Our priority for stplanr however, is to keep the focus on geographic functions for transport planning. There are many opportunities in this direction, including:

+lm1 <- lm(pwalk ~ d_euclidean, data = l@data, weights = All) +lm2 <- lm(pwalk ~ d_rf, data = l@data, weights = All) +lm3 <- glm(pwalk ~ d_rf + I(d_rf^0.5), + data = l@data, weights = All, family = quasipoisson(link = "log") +)
+

The results of these regression models can be seen using +summary(). Surprisingly, Euclidean distance was a better +predictor of walking than route distance, but no strong conclusions can +be drawn from this finding, with such a small sample of desire lines (n += 42). The results are purely illustrative, of the kind of the +possibilities created by using stplanr in conjuction +with R’s modelling capabilities (see Figure ).

+
+plot(l$d_euclidean, l$pwalk,
+  cex = l$All / 50,
+  xlab = "Euclidean distance (m)", ylab = "Proportion of trips by foot"
+)
+l2 <- data.frame(d_euclidean = 1:5000, d_rf = 1:5000)
+lm1p <- predict(lm1, l2)
+lm2p <- predict(lm2, l2)
+lm3p <- predict(lm3, l2)
+lines(l2$d_euclidean, lm1p)
+lines(l2$d_euclidean, exp(lm2p), col = "green")
+lines(l2$d_euclidean, exp(lm3p), col = "red")
+ +
+

Visualisation +

+

Visualisation is an important aspect of any transport study, as it +enables researchers to communicate their findings to other researchers, +policy-makers and, ultimately, the public. It may therefore come as a +surprise that stplanr contains no functions for +visualisation. Instead, users are encouraged to make use of existing +spatial visualisation tools in R, such as tmap, +leaflet and ggmap .

+

Furthermore, with the development of online application frameworks +such as shiny, it is now easier than ever to make the +results of transport analysis and modelling projects available to the +public. An example is the online interface of the Propensity to Cycle +Tool (PCT). The results of the project, generated using +stplanr, are presented at zone, desire line and Route +Network levels . There is great potential to expand on the principle of +publicly accessible transport planning tools via ‘web apps’, perhaps +through new R packages dedicated to visualising transport data.

+
+ +
+

Future directions of travel +

+

This paper has demonstrated the great potential for R to be used for +transport planning. R’s flexibility, powerful GIS capabilities and free +accessibility makes it well-suited to the needs of transport planners +and researchers, especially those wanting to avoid the high costs of +market-leading products. Rather than ‘reinvent the wheel’ (e.g. with a +new class system), stplanr builds on existing packages +and classes to work with common transport data formats.

+

It is useful to see stplanr, and R for transport +planning in general, as an addition tool in the transport planner’s +cabinet. It can be understood as one part of a wider movement that is +making transport planning a more open and democratic process. Other +developments in this movement include the increasing availability of +open data and the rise of open source products for transport modelling, +such as SUMO, +MATSim and MITSIMLAB . +stplanr, with its focus on GIS operations rather than +microscopic vehicle-level behaviour, can complement such software and +help make better use of new open data sources.

+

Because transport planning is an inherently spatial activity, +stplanr occupies an important niche in the transport +planning software landscape, with its focus on spatial transport data. +There is great potential for development of stplanr in +many directions. Desirable developments include the additional of +functions for modelling modal split, for examample with functions to +create commonly distance decay curves which are commonly found in active +travel research and improving the computational efficiency of existing +functions to make the methods more scalable for large databases. Our +priority for stplanr however, is to keep the focus on +geographic functions for transport planning. There are many +opportunities in this direction, including:

-

Such spatial data processing capabilities would increase the range of transport planning tasks that stplanr can facilitate. For all this planned development activity to be useful, it is vital that new functionality is intuitive. R has a famously steep learning curve. Implementing simple concepts such as consistent naming systems and ensuring ‘type stability’ can greatly improve the usability of the package. For this reason, much future work in stplanr will go into improving documentation and user-friendliness.

-

Like much open source software stplanr is an open-ended project, a work-in-progress. We have set out clear motivations for developing transport planning capabilities in R and believe that the current version of stplanr (0.1.6) provides a major step in that direction compared with what was available a couple of years ago. But there is much more to do. We therefore welcome input on where the package’s priorities should lie, how it should evolve in the future and how to ensure it is well-developed and sustained.

+

Such spatial data processing capabilities would increase the range of +transport planning tasks that stplanr can facilitate. +For all this planned development activity to be useful, it is vital that +new functionality is intuitive. R has a famously steep learning curve. +Implementing simple concepts such as consistent naming systems and +ensuring ‘type stability’ can greatly improve the usability of the +package. For this reason, much future work in stplanr +will go into improving documentation and user-friendliness.

+

Like much open source software stplanr is an +open-ended project, a work-in-progress. We have set out clear +motivations for developing transport planning capabilities in R and +believe that the current version of stplanr (0.1.6) +provides a major step in that direction compared with what was available +a couple of years ago. But there is much more to do. We therefore +welcome input on where the package’s priorities should lie, how it +should evolve in the future and how to ensure it is well-developed and +sustained.

-
-

-References

+
+

References +

-Balmer, Michael, Marcel Rieser, and Kai Nagel. 2009. “MATSim-T: Architecture and Simulation Times.” Multi-Agent Systems for Traffic and Transportation Engineering, 57–78. https://svn.vsp.tu-berlin.de/repos/public-svn/publications/vspwp/2008/08-03/3aug08.pdf. +Balmer, Michael, Marcel Rieser, and Kai Nagel. 2009. +“MATSim-T: Architecture and +Simulation Times.” Multi-Agent Systems for Traffic and +Transportation Engineering, 57–78. https://svn.vsp.tu-berlin.de/repos/public-svn/publications/vspwp/2008/08-03/3aug08.pdf.
-Banister, David. 2008. “The Sustainable Mobility Paradigm.” Transport Policy 15 (2): 73–80. https://doi.org/10.1016/j.tranpol.2007.10.005. +Banister, David. 2008. “The Sustainable Mobility Paradigm.” +Transport Policy 15 (2): 73–80. https://doi.org/10.1016/j.tranpol.2007.10.005.
-Bivand, Roger S, Edzer J Pebesma, and Virgilio G’omez-Rubio. 2013. Applied Spatial Data Analysis with R. Vol. 747248717. Springer. +Bivand, Roger S, Edzer J Pebesma, and Virgilio G’omez-Rubio. 2013. +Applied Spatial Data Analysis with R. Vol. +747248717. Springer.
-Boyce, David E., and Huw C. W. L. Williams. 2015. Forecasting Urban Travel: Past, Present and Future. Edward Elgar Publishing. +Boyce, David E., and Huw C. W. L. Williams. 2015. Forecasting +Urban Travel: Past, +Present and Future. Edward Elgar +Publishing.
-Brown, Patrick E. 2016. “Maps, Coordinate Reference Systems and Visualising Geographic Data with Mapmisc.” The R Journal 8 (1): 64–91. +Brown, Patrick E. 2016. “Maps, Coordinate Reference +Systems and Visualising Geographic Data with +Mapmisc.” The R Journal 8 (1): 64–91.
-Brown, Patrick E., and L. Zhou. 2016. “Diseasemapping: Modelling Spatial Variation in Disease Risk for Areal Data.” https://CRAN.R-project.org/package=diseasemapping. +Brown, Patrick E., and L. Zhou. 2016. “Diseasemapping: +Modelling Spatial Variation in +Disease Risk for Areal +Data.” https://CRAN.R-project.org/package=diseasemapping.
-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. +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.
-Cerin, Ester, Cindy H P Sit, Anthony Barnett, Man Chin Cheung, and Wai Man Chan. 2013. “Walking for Recreation and Perceptions of the Neighborhood Environment in Older Chinese Urban Dwellers.” Journal of Urban Health 90 (1): 56–66. https://doi.org/10.1007/s11524-012-9704-8. +Cerin, Ester, Cindy H P Sit, Anthony Barnett, Man Chin Cheung, and Wai +Man Chan. 2013. “Walking for Recreation and Perceptions of the +Neighborhood Environment in Older Chinese Urban +Dwellers.” Journal of Urban Health 90 (1): 56–66. https://doi.org/10.1007/s11524-012-9704-8.
-de Dios Ortuzar, Juan, and Luis G. Willumsen. 2011. Modelling Transport. John Wiley & Sons. +de Dios Ortuzar, Juan, and Luis G. Willumsen. 2011. Modelling +Transport. John Wiley & Sons.
-Diana, Marco. 2012. “Studying Patterns of Use of Transport Modes Through Data Mining.” Transportation Research Record: Journal of the Transportation Research Board 2308 (December): 1–9. https://doi.org/10.3141/2308-01. +Diana, Marco. 2012. “Studying Patterns of +Use of Transport Modes +Through Data Mining.” +Transportation Research Record: Journal of the Transportation +Research Board 2308 (December): 1–9. https://doi.org/10.3141/2308-01.
-Efthymiou, Dimitrios, and Constantinos Antoniou. 2012. “Use of Social Media for Transport Data Collection.” Procedia - Social and Behavioral Sciences 48 (August 2016): 775–85. https://doi.org/10.1016/j.sbspro.2012.06.1055. +Efthymiou, Dimitrios, and Constantinos Antoniou. 2012. “Use of +Social Media for Transport +Data Collection.” Procedia - Social +and Behavioral Sciences 48 (August 2016): 775–85. https://doi.org/10.1016/j.sbspro.2012.06.1055.
-Hollander, Yaron. 2016. Transport Modelling for a Complete Beginner. CTthink! +Hollander, Yaron. 2016. Transport Modelling for a +Complete Beginner. CTthink!
-Jalal, Hawre, Petros Pechlivanoglou, Eline Krijkamp, Fernando Alarid-Escudero, Eva Enns, and M. G. Myriam Hunink. 2017. “An Overview of R in Health Decision Sciences.” Medical Decision Making, January, 0272989X16686559. https://doi.org/10.1177/0272989X16686559. +Jalal, Hawre, Petros Pechlivanoglou, Eline Krijkamp, Fernando +Alarid-Escudero, Eva Enns, and M. G. Myriam Hunink. 2017. “An +Overview of R in Health Decision +Sciences.” Medical Decision Making, January, +0272989X16686559.
-Kim, Albert Y., and Jon Wakefield. 2016. “SpatialEpi: Methods and Data for Spatial Epidemiology.” https://CRAN.R-project.org/package=SpatialEpi. +Kim, Albert Y., and Jon Wakefield. 2016. “SpatialEpi: +Methods and Data for Spatial +Epidemiology.” https://CRAN.R-project.org/package=SpatialEpi.
-Lovelace, Robin, and Richard Ellison. 2018. “Stplanr: A Package for Transport Planning.” The R Journal 10 (2): 7–23. https://doi.org/10.32614/RJ-2018-053. +Lovelace, Robin, and Richard Ellison. 2018. “Stplanr: A +Package for Transport Planning.” The R +Journal 10 (2): 7–23. https://doi.org/10.32614/RJ-2018-053.
-Lovelace, Robin, Anna Goodman, Rachel Aldred, Nikolai Berkoff, Ali Abbas, and James Woodcock. 2017. “The Propensity to Cycle Tool: An Open Source Online System for Sustainable Transport Planning.” Journal of Transport and Land Use 10 (1). https://doi.org/10.5198/jtlu.2016.862. +Lovelace, Robin, Anna Goodman, Rachel Aldred, Nikolai Berkoff, Ali +Abbas, and James Woodcock. 2017. “The Propensity to +Cycle Tool: An Open Source Online +System for Sustainable Transport Planning.” Journal of +Transport and Land Use 10 (1). https://doi.org/10.5198/jtlu.2016.862.
-Moore, R. D. (Dan), and David Hutchinson. 2017. “Why Watershed Analysts Should Use R for Data Processing and Analysis.” Confluence: Journal of Watershed Science and Management 1 (1). http://confluence-jwsm.ca/index.php/jwsm/article/view/2. +Moore, R. D. (Dan), and David Hutchinson. 2017. “Why +Watershed Analysts Should Use R for Data +Processing and Analysis.” Confluence: +Journal of Watershed Science and Management 1 (1). http://confluence-jwsm.ca/index.php/jwsm/article/view/2.
-Pebesma, Edzer, Roger Bivand, Paulo Justiniano Ribeiro, and others. 2015. “Software for Spatial Statistics.” Journal of Statistical Software 63 (1): 1–8. http://brage.bibsys.no/xmlui/bitstream/id/320781/Pebesma_Bivand_Ribeiro.pdf. +Pebesma, Edzer, Roger Bivand, Paulo Justiniano Ribeiro, et al. 2015. +“Software for Spatial +Statistics.” Journal of Statistical +Software 63 (1): 1–8. http://brage.bibsys.no/xmlui/bitstream/id/320781/Pebesma_Bivand_Ribeiro.pdf.
-Waddell, Paul. 2002. “UrbanSim: Modeling Urban Development for Land Use, Transportation, and Environmental Planning.” Journal of the American Planning Association 68 (3): 297–314. +Waddell, Paul. 2002. “UrbanSim: Modeling +Urban Development for Land Use, Transportation, and Environmental +Planning.” Journal of the American Planning Association +68 (3): 297–314.
-Zheng, Xinhu, Wei Chen, Pu Wang, Dayong Shen, Songhang Chen, Xiao Wang, Qingpeng Zhang, and Liuqing Yang. 2016. “Big Data for Social Transportation.” IEEE Transactions on Intelligent Transportation Systems 17 (3): 620–30. https://ieeexplore.ieee.org/abstract/document/7359138/. -
-
+Zheng, Xinhu, Wei Chen, Pu Wang, Dayong Shen, Songhang Chen, Xiao Wang, +Qingpeng Zhang, and Liuqing Yang. 2016. “Big Data for Social +Transportation.” IEEE Transactions on Intelligent +Transportation Systems 17 (3): 620–30. https://ieeexplore.ieee.org/abstract/document/7359138/.
-
-
-
    -

  1. Many people can think of things that could be improved on their local transport networks, especially for walking, cycling and wheel-chairs. But most lack the evidence to communicate the issues, and potential solutions, to others.↩︎

    2. -

  2. An API key is needed for this function to work. This can be requested (or purchased for large scale routing) from cyclestreets.net/api/apply. See ?route_cyclestreet for details. Thanks to Martin Lucas-Smith and Simon Nuttall for making this possible.↩︎

    3. -
-
- - + - + diff --git a/docs/authors.html b/docs/authors.html index 4682de35..b59c2b75 100644 --- a/docs/authors.html +++ b/docs/authors.html @@ -1,150 +1,108 @@ - - - - - - - -Citation and Authors • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Citation

- Source: inst/CITATION +
+

Authors and Citation

-

Lovelace, R. and Ellison, R., 2017. stplanr: A Package for Transport Planning. The R Journal. https://doi.org/10.32614/RJ-2018-053

- 
@Article{,
+    

+      
Authors

+      
+      
  • 
+          
    Robin Lovelace. Author, maintainer. 
+          
    
+        
    • 
+        
  • 
+          
    Richard Ellison. Author. 
+          
    
+        
    • 
+        
  • 
+          
    Malcolm Morgan. Author. 
+          
    
+        
    • 
+        
  • 
+          
    Barry Rowlingson. Contributor. 
+          
    
+        
    • 
+        
  • 
+          
    Nick Bearman. Contributor. 
+          
    
+        
    • 
+        
  • 
+          
    Nikolai Berkoff. Contributor. 
+          
    
+        
    • 
+        
  • 
+          
    Scott  Chamberlain. Reviewer. 
+          
    Scott reviewed the package for rOpenSci, see https://github.com/ropensci/onboarding/issues/10
    
+        
    • 
+        
  • 
+          
    Mark Padgham. Contributor. 
+          
    
+        
    • 
+        
  • 
+          
    Andrea Gilardi. Contributor. 
+          
    
+        
    • 
+      

+
+    

+      
Citation

+      
Source: inst/CITATION

+
+      
Lovelace, R. and Ellison, R., 2017. stplanr: A Package for Transport Planning. The R Journal. https://doi.org/10.32614/RJ-2018-053

+      
@Article{,
   author = {{Robin Lovelace} and {Richard Ellison}},
   title = {{stplanr: A Package for Transport Planning}},
   year = {2018},
@@ -153,108 +111,55 @@ 
Citation

   journal = {{The R Journal}},
   url = {https://doi.org/10.32614/RJ-2018-053},
 }

-
-    

-      
Authors

     

-
-    
    
-      
  • 
-        
    Robin Lovelace. Author, maintainer. 
-        
    
-      
    • 
-      
  • 
-        
    Richard Ellison. Author. 
-        
    
-      
    • 
-      
  • 
-        
    Malcolm Morgan. Author. 
-        
    
-      
    • 
-      
  • 
-        
    Barry Rowlingson. Contributor. 
-        
    Author of overline
    
-      
    • 
-      
  • 
-        
    Nick Bearman. Contributor. 
-        
    Co-author of gclip
    
-      
    • 
-      
  • 
-        
    Nikolai Berkoff. Contributor. 
-        
    Co-author of line2route
    
-      
    • 
-      
  • 
-        
    Scott  Chamberlain. Reviewer. 
-        
    Scott reviewed the package for rOpenSci, see https://github.com/ropensci/onboarding/issues/10
    
-      
    • 
-      
  • 
-        
    Mark Padgham. Contributor. 
-        
    
-      
    • 
-      
  • 
-        
    Andrea Gilardi. Contributor. 
-        
    
-      
    • 
-    

-
-  

-
-
+
- -
+ - - + + diff --git a/docs/index.html b/docs/index.html index 3ef5423a..0c13206b 100644 --- a/docs/index.html +++ b/docs/index.html @@ -4,360 +4,352 @@ - + + Sustainable Transport Planning • stplanr - + - - - - - - - - - - + + + + + + + + - -
-
-
-
-

-stplanr -

-

rstudio mirror downloads CRAN_Status_Badge lifecycle R-CMD-check

+

rstudio mirror downloads CRAN_Status_Badge lifecycle R-CMD-check

stplanr is a package for sustainable transport planning with R.

-

It provides functions for solving common problems in transport planning and modelling, such as how to best get from point A to point B. The overall aim is to provide a reproducible, transparent and accessible toolkit to help people better understand transport systems and inform policy, as outlined in a paper about the package, and the potential for open source software in transport planning in general, published in the R Journal.

-

The initial work on the project was funded by the Department of Transport (DfT) as part of the development of the Propensity to Cycle Tool (PCT), a web application to explore current travel patterns and cycling potential at zone, desire line, route and route network levels (see www.pct.bike and click on a region to try it out). The basis of the methods underlying the PCT is origin-destination data, which are used to highlight where many short distance trips are being made, and estimate how many could switch to cycling. The results help identify where cycleways are most needed, an important component of sustainable transport planning infrastructure engineering and policy design.

-

See the package vignette (e.g. via vignette("introducing-stplanr")) or an academic paper on the Propensity to Cycle Tool (PCT) for more information on how it can be used. This README provides some basics.

-

Much of the work supports research undertaken at the Leeds’ Institute for Transport Studies (ITS) but stplanr should be useful to transport researchers and practitioners needing free, open and reproducible methods for working with geographic data everywhere.

-
-

-Key functions

+

It provides functions for solving common problems in transport planning and modelling, such as how to best get from point A to point B. The overall aim is to provide a reproducible, transparent and accessible toolkit to help people better understand transport systems and inform policy, as outlined in a paper about the package, and the potential for open source software in transport planning in general, published in the R Journal.

+

The initial work on the project was funded by the Department of Transport (DfT) as part of the development of the Propensity to Cycle Tool (PCT), a web application to explore current travel patterns and cycling potential at zone, desire line, route and route network levels (see www.pct.bike and click on a region to try it out). The basis of the methods underlying the PCT is origin-destination data, which are used to highlight where many short distance trips are being made, and estimate how many could switch to cycling. The results help identify where cycleways are most needed, an important component of sustainable transport planning infrastructure engineering and policy design.

+

See the package vignette (e.g. via vignette("introducing-stplanr")) or an academic paper on the Propensity to Cycle Tool (PCT) for more information on how it can be used. This README provides some basics.

+

Much of the work supports research undertaken at the Leeds’ Institute for Transport Studies (ITS) but stplanr should be useful to transport researchers and practitioners needing free, open and reproducible methods for working with geographic data everywhere.

+
+

Key functions +

Data frames representing flows between origins and destinations must be combined with geo-referenced zones or points to generate meaningful analyses and visualisations of ‘flows’ or origin-destination (OD) data. stplanr facilitates this with od2line(), which takes flow and geographical data as inputs and outputs spatial data. Some example data is provided in the package:

+library(stplanr)

Let’s take a look at this data:

-od_data_sample[1:3, 1:3] # typical form of flow data
-#> # A tibble: 3 x 3
-#>   geo_code1 geo_code2   all
-#>   <chr>     <chr>     <dbl>
-#> 1 E02002361 E02002361   109
-#> 2 E02002361 E02002363    38
-#> 3 E02002361 E02002367    10
-cents_sf[1:3,] # points representing origins and destinations
-#>       geo_code  MSOA11NM percent_fem  avslope             geometry
-#> 1708 E02002384 Leeds 055    0.458721 2.856563 -1.546463, 53.809517
-#> 1712 E02002382 Leeds 053    0.438144 2.284782 -1.511861, 53.811611
-#> 1805 E02002393 Leeds 064    0.408759 2.361707 -1.524205, 53.804098
+od_data_sample[1:3, 1:3] # typical form of flow data +#> # A tibble: 3 x 3 +#> geo_code1 geo_code2 all +#> <chr> <chr> <dbl> +#> 1 E02002361 E02002361 109 +#> 2 E02002361 E02002363 38 +#> 3 E02002361 E02002367 10 +cents_sf[1:3,] # points representing origins and destinations +#> geo_code MSOA11NM percent_fem avslope geometry +#> 1708 E02002384 Leeds 055 0.458721 2.856563 -1.546463, 53.809517 +#> 1712 E02002382 Leeds 053 0.438144 2.284782 -1.511861, 53.811611 +#> 1805 E02002393 Leeds 064 0.408759 2.361707 -1.524205, 53.804098

These datasets can be combined as follows:

-travel_network <- od2line(flow = od_data_sample, zones = cents_sf)
-w <- flow$all / max(flow$all) *10
-plot(travel_network, lwd = w)
+travel_network <- od2line(flow = od_data_sample, zones = cents_sf) +w <- flow$all / max(flow$all) *10 +plot(travel_network, lwd = w)

-

stplanr has many functions for working with OD data. See the stplanr-od vignette for details.

-

The package can also allocate flows to the road network, e.g. with CycleStreets.net and the OpenStreetMap Routing Machine (OSRM) API interfaces. These are supported in route_*() functions such as route_cyclestreets and route_osrm():

+

stplanr has many functions for working with OD data. See the stplanr-od vignette for details.

+

The package can also allocate flows to the road network, e.g. with CycleStreets.net and the OpenStreetMap Routing Machine (OSRM) API interfaces. These are supported in route_*() functions such as route_cyclestreets and route_osrm():

Routing can be done using a range of back-ends and using lat/lon or desire line inputs with the route() function, as illustrated by the following commands which calculates the route between Fleet Street and Southwark Street over the River Thames on Blackfriars Bridge in London:

-library(osrm)
-#> Data: (c) OpenStreetMap contributors, ODbL 1.0 - http://www.openstreetmap.org/copyright
-#> Routing: OSRM - http://project-osrm.org/
-trip <- route(
-  from = c(-0.11, 51.514),
-  to = c(-0.10, 51.506),
-  route_fun = osrmRoute,
-  returnclass = "sf"
-  )
-#> Most common output is sf
-mapview::mapview(trip)
+library(osrm) +#> Data: (c) OpenStreetMap contributors, ODbL 1.0 - http://www.openstreetmap.org/copyright +#> Routing: OSRM - http://project-osrm.org/ +trip <- route( + from = c(-0.11, 51.514), + to = c(-0.10, 51.506), + route_fun = osrmRoute, + returnclass = "sf" + ) +#> Most common output is sf +mapview::mapview(trip)

You can also use and place names, found using the Google Map API:

-trip2 <- route(
-  from = "Leeds",
-  to = "Bradford",
-  route_fun = osrmRoute,
-  returnclass = "sf"
-  )
-#> Most common output is sf
-mapview::mapview(trip2)
+trip2 <- route( + from = "Leeds", + to = "Bradford", + route_fun = osrmRoute, + returnclass = "sf" + ) +#> Most common output is sf +mapview::mapview(trip2)

We can replicate this call multiple times with the l argument in route():

-desire_lines <- travel_network[2:6, ]
+desire_lines <- travel_network[2:6, ]

Next, we’ll calculate the routes:

-routes <- route(
-  l = desire_lines,
-  route_fun = osrmRoute,
-  returnclass = "sf"
-  )
-mapview::mapview(routes) +
-  mapview::mapview(desire_lines, color = "red")
+routes <- route( + l = desire_lines, + route_fun = osrmRoute, + returnclass = "sf" + ) +mapview::mapview(routes) + + mapview::mapview(desire_lines, color = "red")

-

For more examples, example("route").

+

For more examples, example("route").

overline() takes a series of route-allocated lines, splits them into unique segments and aggregates the values of overlapping lines. This can represent where there will be most traffic on the transport system, as demonstrated in the following code chunk.

-routes$foot <- desire_lines$foot
-rnet <- overline(routes, attrib = "foot")
-#> 2020-09-03 22:24:08 constructing segments
-#> 2020-09-03 22:24:08 building geometry
-#> 2020-09-03 22:24:08 simplifying geometry
-#> 2020-09-03 22:24:08 aggregating flows
-#> 2020-09-03 22:24:08 rejoining segments into linestrings
+routes$foot <- desire_lines$foot +rnet <- overline(routes, attrib = "foot") +#> 2020-09-03 22:24:08 constructing segments +#> 2020-09-03 22:24:08 building geometry +#> 2020-09-03 22:24:08 simplifying geometry +#> 2020-09-03 22:24:08 aggregating flows +#> 2020-09-03 22:24:08 rejoining segments into linestrings

The resulting route network, with segment totals calculated from overlapping parts for the routes for walking, can be visualised as follows:

-plot(rnet["foot"], lwd = rnet$foot)
+plot(rnet["foot"], lwd = rnet$foot)

The above plot represents the number walking trips made (the ‘flow’) along particular segments of a transport network.

-
-

-Policy applications

-

The examples shown above, based on tiny demonstration datasets, may not seem particularly revolutionary. At the city scale, however, this type of analysis can be used to inform sustainable transport policies, as described in papers describing the Propensity to Cycle Tool (PCT), and its application to calculate cycling to school potential across England.

-

Results generated by stplanr are now part of national government policy: the PCT is the recommended tool for local and regional authorities developing strategic cycle network under the Cycling and Walking Infrastructure Strategy (CWIS), which is part of the Infrastructure Act 2015. stplanr is helping dozens of local authorities across the UK to answer the question: where to prioritise investment in cycling? In essence, stplanr was designed to support sustainable transport policies.

+
+

Policy applications +

+

The examples shown above, based on tiny demonstration datasets, may not seem particularly revolutionary. At the city scale, however, this type of analysis can be used to inform sustainable transport policies, as described in papers describing the Propensity to Cycle Tool (PCT), and its application to calculate cycling to school potential across England.

+

Results generated by stplanr are now part of national government policy: the PCT is the recommended tool for local and regional authorities developing strategic cycle network under the Cycling and Walking Infrastructure Strategy (CWIS), which is part of the Infrastructure Act 2015. stplanr is helping dozens of local authorities across the UK to answer the question: where to prioritise investment in cycling? In essence, stplanr was designed to support sustainable transport policies.

There are many other research and policy questions that functions in stplanr, and other open source software libraries and packages, can help answer. At a time of climate, health and social crises, it is important that technology is not only sustainable itself (e.g. as enabled by open source communities and licenses) but that it contributes to a sustainable future.

-
-

-Installation

+
+

Installation +

To install the stable version, use:

-install.packages("stplanr")
+install.packages("stplanr")

The development version can be installed using devtools:

-# install.packages("devtools") # if not already installed
-devtools::install_github("ropensci/stplanr")
-library(stplanr)
+# install.packages("devtools") # if not already installed +devtools::install_github("ropensci/stplanr") +library(stplanr)

stplanr depends on rgdal, which can be tricky to install.

-
-

-Installing stplanr on Linux and Mac

-

stplanr depends on sf. Installation instructions for Mac, Ubuntu and other Linux distros can be found here: https://github.com/r-spatial/sf#installing

+
+

Installing stplanr on Linux and Mac +

+

stplanr depends on sf. Installation instructions for Mac, Ubuntu and other Linux distros can be found here: https://github.com/r-spatial/sf#installing

-
-

-Funtions, help and contributing

-

The current list of available functions can be seen on the package’s website at docs.ropensci.org/stplanr/, or with the following command:

+
+

Functions, help and contributing +

+

The current list of available functions can be seen on the package’s website at docs.ropensci.org/stplanr/, or with the following command:

-lsf.str("package:stplanr", all = TRUE)
+lsf.str("package:stplanr", all = TRUE)

To get internal help on a specific function, use the standard way.

-?od2line
-

To contribute, report bugs or request features, see the issue tracker.

+?od2line
+

To contribute, report bugs or request features, see the issue tracker.

-
-

-Further resources / tutorials

+
+

Further resources / tutorials +

Want to learn how to use open source software for reproducible sustainable transport planning work? Now is a great time to learn. Transport planning is a relatively new field of application in R. However, there are already some good resources on the topic, including (any further suggestions: welcome):

-
-

-Meta

+
+

Meta +

-

rofooter

+

rofooter

-
- - - + diff --git a/docs/news/index.html b/docs/news/index.html index 6a950442..f6f7a1a0 100644 --- a/docs/news/index.html +++ b/docs/news/index.html @@ -1,453 +1,341 @@ - - - - - - - -Changelog • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Changelog

- Source: NEWS.md +
+

Changelog

+ Source: NEWS.md
-
-

-stplanr (development version) Unreleased -

-
-
-

-stplanr 0.8.0 2020-10-28 -

- -
-
-

-stplanr 0.7.2 2020-09-04 -

-
    -
  • Support sf objects for toptail_buff() -
    • -
  • Updated examples for tests and README to enable tests to pass on legacy versions of PROJ (#423)
    • -
  • Reduce vulnerability to upcoming upstream changes (#426)
    • -
-
-
-

-stplanr 0.7.1 2020-08-28 -

-
    -
  • Tweaks to the documentation and examples for CRAN tests
    • -
-
-
-

-stplanr 0.7.0 2020-08-27 -

-
    -
  • Issue with line2points() on some set-ups fixed (#418)
    • -
  • Old mapshape(), line_match() and gclip() functions deprecated, maintained alternatives can now be found in other packages.
    • -
  • -sp objects updated for latest version of sp (#364)
    • -
  • -sf objects updated to support more recent CRS encoding (#393)
    • +
    +

    stplanr 1.0.2

    CRAN release: 2022-11-08

    +
    • Update docs, fix missing functions issue (#499)
      • +
    +
    +

    stplanr 1.0.1

    CRAN release: 2022-08-19

    +
    • Fix for breaking change in dodgr (#494)
      • +
    +
    +

    stplanr 1.0.0

    CRAN release: 2022-06-10

    +
    +
    +

    stplanr 0.9.0 (May 2022)

    CRAN release: 2022-05-11

    +
    • Message added on loading the package announcing planned changes: support for sp objects and associated packages will be dropped (#332)
      • +
    • New function line_segment_sf() (#482)
      • +
    • Various changes required by CRAN (#486)
      • +
    +
    +

    stplanr 0.8.7 (February 2022)

    CRAN release: 2022-02-01

    +
    • +route() now runs batch routing when input is a linestring and opentripplanner is installed (#459)
      • +
    +
    +

    stplanr 0.8.6 (November 2021)

    CRAN release: 2021-11-26

    +
    • +route() checks the CRS and gives an appropriate warning if it is projected
      • +
    • The package now Suggests igraph rather than depending on it making it easier to install
      • +
    +
    +

    stplanr 0.8.5

    CRAN release: 2021-11-01

    +
    • No longer Suggests stats19 package
      • +
    +
    +

    stplanr 0.8.4

    CRAN release: 2021-10-12

    +
    • No longer Suggests bench package
      • +
    • Tests pass when internet unavailable (#469)
      • +
    +
    +

    stplanr 0.8.3

    CRAN release: 2021-07-22

    +
    • Outputs of line_via() now have correct CRS
      • +
    • +calc_catchment() have been deprecated because the generate warnings
      • +
    • Minor fixes and improvements in the package’s documentation
      • +
    +
    +

    stplanr 0.8.2

    CRAN release: 2021-04-06

    +
    • Bug fixed related to the route() function: it silently failed when pbapply not installed. The package was promoted from Suggests to Imports (#460)
      • +
    +
    +

    stplanr 0.8.1

    CRAN release: 2021-01-07

    +
    • Thanks to the styler package, code in stplanr now adheres to a consistent style (using arrow <- assignment despite the maintainer’s default of equals = assignment - many = had been introduced accidentally!)
      • +
    • New function rnet_group() groups route network elements (#403)
      • +
    • +overline() now converts MULTILINESTRING geometries to LINESTRINGS automatically
      • +
    • Routing on the network using sum_network_routes() now returns a linestring for routes that start where they end (i.e. no travel) (#444)
      • +
    • Routing using route_local() fixed: the l argument now works (#448)
      • +
    • New route_osrm() function (#449)
      • +
    • +rnet_breakup_vertices() is now way faster, thanks to Andrea Gilardi and others (#416)
      • +
    • +rnet_group() is now a generic function that works with sfNetwork objects (#455)
      • +
    • +route_osrm() provides easy access to multi-modal routing (#449)
      • +
    • Bug in route() function’s calculation of bbox attributes fixed (#452)
      • +
    +
    +

    stplanr 0.8.0

    CRAN release: 2020-10-28

    +
    +
    +

    stplanr 0.7.2

    CRAN release: 2020-09-04

    +
    • Support sf objects for toptail_buff() +
      • +
    • Updated examples for tests and README to enable tests to pass on legacy versions of PROJ (#423)
      • +
    • Reduce vulnerability to upcoming upstream changes (#426)
      • +
    +
    +

    stplanr 0.7.1

    CRAN release: 2020-08-28

    +
    • Tweaks to the documentation and examples for CRAN tests
      • +
    +
    +

    stplanr 0.7.0

    CRAN release: 2020-08-27

    +
    • Issue with line2points() on some set-ups fixed (#418)
      • +
    • Old mapshape(), line_match() and gclip() functions deprecated, maintained alternatives can now be found in other packages.
      • +
    • +sp objects updated for latest version of sp (#364)
      • +
    • +sf objects updated to support more recent CRS encoding (#393)
    • Deprecated functions including od_aggregate(), onewayid(), gtfs2sldf(), and od_radiation() have been removed
      • -
    -
    -
    -

    -stplanr 0.6.2 2020-07-08 -

    -
    -

    -New features

    -
      -
    • New interface to Google Directions API via mapsapi package (#410)
      • +
    +
    +

    stplanr 0.6.2

    CRAN release: 2020-07-08

    +
    +

    New features

    +
    • New interface to Google Directions API via mapsapi package (#410)
    • New quiet argument in overline() makes it less chatty
      • -
    -
    -
    -
    -

    -stplanr 0.6.1 2020-06-23 -

    -
    -

    -BUG FIXES

    -
      -
    • -route() failed when data.table not installed (#408)
      • -
    -
    -
    -
    -

    -stplanr 0.6.0 2020-05-03 -

    -
    -

    -BUG FIXES

    -
    +
    +
    +

    stplanr 0.6.1

    CRAN release: 2020-06-23

    +
    +

    BUG FIXES

    +
    • +route() failed when data.table not installed (#408)
      • +
    +
    +
    +

    stplanr 0.6.0

    CRAN release: 2020-05-03

    +
    +

    BUG FIXES

    +
    • Bug in SpatialLinesNetwork() fixed thanks to Andrea Gilardi (#394)
    • Updated documentation for finding shortest paths
    • Check start and end arguments in short path calculations are numeric
    • -dodgr removed as Suggests until it’s back on CRAN (#398)
      • -
    • Updates to dplyr code to prevent warnings when using the dev version (#395)
      • -
    -
    -
    -

    -NEW FEATURES

    -
      -
    • Improvements to route() allowing you to save a list of raw outputs and use data.table for faster performance if available
      • +dodgr removed as Suggests until it’s back on CRAN (#398) +
    • Updates to dplyr code to prevent warnings when using the dev version (#395)
      • +
    +
    +

    NEW FEATURES

    +
    • Improvements to route() allowing you to save a list of raw outputs and use data.table for faster performance if available
    • A fleet of new route_rolling_*() functions have been added: -
    • -geo_toptail() function now has sf implementation (#390)
      • -
    • New cl argument in route() for parallel routing (#388)
      • +geo_toptail() function now has sf implementation (#390) +
    • New cl argument in route() for parallel routing (#388)
    • New and updated datasets representing od_data_sample in different ways: od_data_lines and od_data_routes
    • -route_graphhopper() deprecated (#389)
      • +route_graphhopper() deprecated (#389)
    • Old functions that use legacy sp and dplyr code, sp_aggregate and od_aggregate, have been deprecated
    • New work-in-progress route_slope*() functions
      • -
    -
    -
    -
    -

    -stplanr 0.5.2 2020-04-06 -

    -
    -

    -BUG FIXES

    -
      -
    • Documentation fixes (#384)
      • -
    • A bug affecting route() function calls when pbapply was not installed has been fixed (#386)
      • -
    • -oneway() has been deprecated in favour of faster and easier-to-maintain function od_oneway() (also see the in-development od package) (#387)
      • -
    • Various other changes have been made to accomodate the dev version of dplyr (#383)
      • -
    -
    -
    -
    -

    -stplanr 0.5.1 2020-03-01 -

    -
      -
    • Changes for compatibility with R 4.0.0
      • -
    -
    -
    -

    -stplanr 0.5.0 2020-01-26 -

    -
    +
    +
    +

    stplanr 0.5.2

    CRAN release: 2020-04-06

    +
    +

    BUG FIXES

    +
    • Documentation fixes (#384)
      • +
    • A bug affecting route() function calls when pbapply was not installed has been fixed (#386)
      • +
    • +oneway() has been deprecated in favour of faster and easier-to-maintain function od_oneway() (also see the in-development od package) (#387)
      • +
    • Various other changes have been made to accomodate the dev version of dplyr (#383)
      • +
    +
    +
    +

    stplanr 0.5.1

    CRAN release: 2020-03-01

    +
    • Changes for compatibility with R 4.0.0
      • +
    +
    +

    stplanr 0.5.0

    CRAN release: 2020-01-26

    +
    • +route_graphhopper() should now work with a local graphhopper instance. See https://github.com/ropensci/stplanr/pull/369 +
      • +
    • The old line2route() function now works with routing functions that return sf objects
    • The new route() function is now more resilient, providing a progress bar if you have pbapply package installed, returning a result even if some routes failed, and telling you which routes failed
    • The package has fewer dependencies, readr, openxlsx and lubridate removed
    • Deprecated function buff_geo() removed
      • -
    -
    -

    -BUG FIXES

    -
    +

    BUG FIXES

    +
    • +destination now works again as an argument in line2route() (#368)
    • overline() now accepts sf objects regardless of the name of the geometry column
    • -line2points() now works with sfc objects (#361)
      • -
    -
    -
    -
    -

    -stplanr 0.4.1 2019-11-23 -

    -
    -

    -NEW FEATURES

    - +line2points() now works with sfc objects (#361) +
+
+

stplanr 0.4.1

CRAN release: 2019-11-23

+
+

NEW FEATURES

+
-
-

-stplanr 0.4.0 2019-10-13 -

-
-

-NEW FEATURES

-
-
-

-stplanr 0.3.1 2019-09-17 -

-
    -
  • stplanr now has a logo! See #334 +
    +

    stplanr 0.3.1

    CRAN release: 2019-09-17

    +
    • stplanr now has a logo! See #334
    • line_to_points() depreciated in favour of od2line(), the latter function name being more consistent with the package’s other functions
    • line2pointsn() now works with sf objects
      • -
    • Documentation fixes - see #329 +
    • Documentation fixes - see #329
      • -
    -
    -

    -OTHER

    -
      -
    • Various improvements made to the stplanr-od vignette, thanks to Edward Leigh
      • -
    • URLs updated to link to stplanr’s new, official website: https://docs.ropensci.org/stplanr/ +
    +

    OTHER

    +
    • Various improvements made to the stplanr-od vignette, thanks to Edward Leigh
      • +
    • URLs updated to link to stplanr’s new, official website: https://docs.ropensci.org/stplanr/
      • -
    +
-
-
-

-stplanr 0.3.0 2019-07-30 -

-
-

-NEW FEATURES

-
    -
  • New functions od_to_odmatrix() and odmatrix_to_od() to convert between matrix forms of origin-destination data
    • +
    +

    stplanr 0.3.0

    CRAN release: 2019-07-30

    +
    +

    NEW FEATURES

    +
    • New functions od_to_odmatrix() and odmatrix_to_od() to convert between matrix forms of origin-destination data
    • New function od_oneway() replaces onewayid(), works better and is twice as fast
      • -
    • New od_id*() functions provide a range of ways to convert origin-destination pair IDs into a single ID. See Stackoverflow and the issue tracker -
      • -
    • New vignette stplanr-od provides detailed documentation on the package’s OD data handling capabilities
      • -
    -
    -
    -
    -

    -stplanr 0.2.10 2019-05-18 -

    -
      -
    • Fix in documentation. See #311 -
      • -
    -
    -
    -

    -stplanr 0.2.9 2019-05-10 -

    -
    -

    -NEW FEATURES

    -
      -
    • New functions od_aggregate_from() and od_aggregate_to() provide easy ways to aggregate origin-destination pairs. See #303.
      • -
    • Updated overline2() is now faster and better documented (#307)
      • -
    • Updates to route_dodgr() function, which provides an interface to the dodgr package, accepts wider range of inputs
      • +
    • New od_id*() functions provide a range of ways to convert origin-destination pair IDs into a single ID. See Stackoverflow and the issue tracker +
      • +
    • New vignette stplanr-od provides detailed documentation on the package’s OD data handling capabilities
      • +
    +
    +
    +

    stplanr 0.2.10

    CRAN release: 2019-05-18

    +
    • Fix in documentation. See #311 +
      • +
    +
    +

    stplanr 0.2.9

    CRAN release: 2019-05-10

    +
    +

    NEW FEATURES

    + -
    -
    -

    -BUG FIXES

    -
    +
    +

    BUG FIXES

    +
    • Bug in sum_network_routes() fixed. See #267
      • -
    -
    +
-
-

-stplanr 0.2.8 2019-03-22 -

-
-

-NEW FEATURES

-
    -
  • The stplanr paper has been published! See it here: https://journal.r-project.org/archive/2018/RJ-2018-053/index.html -
    • -
  • STATS19 functions such as dl_stats19() are depreciated. They have been split-out into the new package stats19 +
    +

    stplanr 0.2.8

    CRAN release: 2019-03-22

    +
    +

    NEW FEATURES

    + -
    -
    -

    -BUG FIXES

    - -
    -
    -
    -

    -stplanr 0.2.7 2019-01-07 -

    -
    -

    -NEW FEATURES

    - -
    -
    -

    -BUG FIXES

    -
      -
    • Fixed #272 by removing byvars argument of overline in preparation for overdue overhaul of overline function.
      • -
    -
    -
    -

    -OTHER

    -
      -
    • No longer suggests tmap to reduce install times: install.packages() installs suggested packages by default
      • -
    -
    -
    -
    -

    -stplanr 0.2.6 2018-10-20 -

    -
    -

    -NEW FEATURES

    - -
    -
    -

    -BUG FIXES

    -
      -
    • Issue with dl_stats19(), see #270 -
      • -
    • Make style consistent, see commit +
    +
    +

    BUG FIXES

    +
    +
    +
    +

    stplanr 0.2.7

    CRAN release: 2019-01-07

    +
    +

    NEW FEATURES

    +
    +
    +

    BUG FIXES

    +
    • Fixed #272 by removing byvars argument of overline in preparation for overdue overhaul of overline function.
      • +
    +
    +

    OTHER

    +
    • No longer suggests tmap to reduce install times: install.packages() installs suggested packages by default
      • +
    +
    +
    +

    stplanr 0.2.6

    CRAN release: 2018-10-20

    +
    +

    NEW FEATURES

    +
    • New function route_local() +
      • +
    • New argument in line2route(): time_sleep waits a period between each route request
      • +
    +
    +

    BUG FIXES

    +
    • Issue with dl_stats19(), see #270 +
      • +
    • Make style consistent, see commit
    • Various small fixes to documentation and style
      • -
    -
    -
    -
    -

    -stplanr 0.2.5 2018-06-02 -

    -
    -

    -NEW FEATURES

    -
      -
    • New function line_via() for identifying intermediary points on a transport network
      • -
    -
    -
    -

    -BUG FIXES

    - -
    -
    -
    -

    -stplanr 0.2.4 2018-05-19 -

    -
    -

    -NEW FEATURES

    -
      -
    • New function geo_length() returns numeric vector of line lengths from sp or sf objects.
      • -
    -
    -
    -

    -DOCUMENTATION

    -
      -
    • -?route_graphhopper no longer mentions the depreciated ‘bike2’ profile - see #246 -
      • -
    • -?route_osrm mentions that the public API only routes for cars - see #246 +
    +
    +
    +

    stplanr 0.2.5

    CRAN release: 2018-06-02

    +
    +

    NEW FEATURES

    +
    • New function line_via() for identifying intermediary points on a transport network
      • +
    +
    +

    BUG FIXES

    +
    • Bug associated with SpatialLinesNetwork() fixed (see #249)
      • +
    +
    +
    +

    stplanr 0.2.4

    CRAN release: 2018-05-19

    +
    +

    NEW FEATURES

    +
    • New function geo_length() returns numeric vector of line lengths from sp or sf objects.
      • +
    +
    +

    DOCUMENTATION

    +
    • +?route_graphhopper no longer mentions the depreciated ‘bike2’ profile - see #246 +
      • +
    • +?route_osrm mentions that the public API only routes for cars - see #246
    • Updated introducing-stplanr vignette to show new function and make more robust
      • -
    -
    -
    -
    -

    -stplanr 0.2.3 2018-03-06 -

    -
    -

    -NEW FEATURES

    -
    +
    +
    +

    stplanr 0.2.3

    CRAN release: 2018-03-06

    +
    +

    NEW FEATURES

    +
    • +stplanr now imports lwgeom, needed for sf::st_length(), used in SpatialLinesNetwork().
    • Plotting behaviour updated for sfNetwork objects: now only plots the geometry by default.
      • -
    • Improved documentation for SpatialLinesNetwork() and plot() for spatial networks.
      • -
    -
    -
    -

    -BUG FIXES

    - -
    -
    -
    -

    -stplanr 0.2.2 2017-12-19 -

    -
    -

    -NEW FEATURES

    -
      -
    • In this release sp is demoted from a Depends to an Imports, meaning that all its functions will not be attached to your namespace (it will not be loaded) when you run library(stplanr), making it less tied to sp. This is a continuation of the work to support sf and will make it easier for the package to work with alternative representations of geographic data.
      • -
    -
    -
    -

    -BUG FIXES

    -
      -
    • Bug in geo_select_aeq.sf() was fixed by Jakub Nowosad in pull #238 +
    • Improved documentation for SpatialLinesNetwork() and plot() for spatial networks.
      • +
    +
    +

    BUG FIXES

    +
    • Bug in sum_network_routes() fixed (see #240).
      • +
    +
    +
    +

    stplanr 0.2.2

    CRAN release: 2017-12-19

    +
    +

    NEW FEATURES

    +
    • In this release sp is demoted from a Depends to an Imports, meaning that all its functions will not be attached to your namespace (it will not be loaded) when you run library(stplanr), making it less tied to sp. This is a continuation of the work to support sf and will make it easier for the package to work with alternative representations of geographic data.
      • +
    +
    +

    BUG FIXES

    +
    • Bug in geo_select_aeq.sf() was fixed by Jakub Nowosad in pull #238
    • An issue with od_aggregate.sf() was fixed making it much faster
      • -
    +
-
-
-

-stplanr 0.2.0 Unreleased -

-
-

-NEW FEATURES

-
+
+

WORK IN PROGRESS

Plans for the next release

-
+
-
-

-stplanr 0.1.9 2017-07-12 -

-
-

-NEW FEATURES

-
-
-

-stplanr 0.1.8 2017-06-02 -

-
-

-NEW FEATURES

-
-
-

-stplanr 0.1.7 2016-12-23 -

-
-

-NEW FEATURES

-
+
+

stplanr 0.1.5

NEW FEATURES

-
-
-

-stplanr 0.1.4

+
+
+

stplanr 0.1.4

NEW FEATURES

-
-
-

-stplanr 0.1.3

+

BUG FIXES

+
+
+

stplanr 0.1.3

NEW FEATURES

-
-
-

-stplanr 0.1.2

+
+
+

stplanr 0.1.2

NEW FEATURES

-
-
-

-stplanr 0.1.0

+
+
+

stplanr 0.1.0

NEW FEATURES

-
-
-

-stplanr 0.0.2

- +
+
+

stplanr 0.0.2

+
- - + - - - - - + - - + + diff --git a/docs/pkgdown.yml b/docs/pkgdown.yml index 13cdd13b..fea39641 100644 --- a/docs/pkgdown.yml +++ b/docs/pkgdown.yml @@ -8,7 +8,7 @@ articles: stplanr-route-nets: stplanr-route-nets.html stplanr-routing: stplanr-routing.html stplanr: stplanr.html -last_built: 2022-11-08T00:28Z +last_built: 2022-11-13T22:50Z urls: reference: https://ropensci.github.io/stplanr/reference article: https://ropensci.github.io/stplanr/articles diff --git a/docs/reference/angle_diff.html b/docs/reference/angle_diff.html index 3114ffec..8ea0aca8 100644 --- a/docs/reference/angle_diff.html +++ b/docs/reference/angle_diff.html @@ -1,291 +1,194 @@ - - - - - - - -Calculate the angular difference between lines and a predefined bearing — angle_diff • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Calculate the angular difference between lines and a predefined bearing

- Source: R/linefuns.R - +
+

Calculate the angular difference between lines and a predefined bearing

+ Source: R/linefuns.R +
angle_diff.Rd
-
+

This function was designed to find lines that are close to parallel and perpendicular to some pre-defined route. It can return results that are absolute (contain information on the direction of turn, i.e. + or - values for clockwise/anticlockwise), bidirectional (which mean values greater than +/- 90 are impossible).

- 
angle_diff(l, angle, bidirectional = FALSE, absolute = TRUE)
+
+

Usage

+ 
angle_diff(l, angle, bidirectional = FALSE, absolute = TRUE)
+
-

Arguments

- - - - - - - - - - - - - - - - - - -
l

A spatial lines object

angle

an angle in degrees relative to North, with 90 being East and -90 being West. -(direction of rotation is ignored).

bidirectional

Should the result be returned in a bidirectional format? -Default is FALSE. If TRUE, the same line in the oposite direction would have the same bearing

absolute

If TRUE (the default) only positive values can be returned

+
+

Arguments

+
l
+

A spatial lines object

-

Details

-

Building on the convention used in bearing() and in many applications, -North is definied as 0, East as 90 and West as -90.

-

See also

+
angle
+

an angle in degrees relative to North, with 90 being East and -90 being West. +(direction of rotation is ignored).

-

Other lines: -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
# fails on some systems (with early versions of PROJ)
-if(lib_versions[3] >= "6.3.1") {
-  # Find all routes going North-South
-  lines_sf = od2line(od_data_sample, zones = zones_sf)
-  angle_diff(lines_sf[2, ], angle = 0)
-  angle_diff(lines_sf[2:3, ], angle = 0)
-  a <- angle_diff(flowlines, angle = 0, bidirectional = TRUE, absolute = TRUE)
-  plot(flowlines)
-  plot(flowlines[a < 15, ], add = TRUE, lwd = 3, col = "red")
-  # East-West
-  plot(flowlines[a > 75, ], add = TRUE, lwd = 3, col = "green")
-}
-
#> Creating centroids representing desire line start and end points.
-
- -
+
bidirectional
+

Should the result be returned in a bidirectional format? +Default is FALSE. If TRUE, the same line in the oposite direction would have the same bearing

+ +
absolute
+

If TRUE (the default) only positive values can be returned

-
- -
+
+
+

Details

+

Building on the convention used in in the bearing() function from the +geosphere package and in many applications, +North is definied as 0, East as 90 and West as -90.

+
+
+

See also

+

Other lines: +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
+ +
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+# fails on some systems (with early versions of PROJ)
+if (lib_versions[3] >= "6.3.1") {
+  # Find all routes going North-South
+  lines_sf <- od2line(od_data_sample, zones = zones_sf)
+  angle_diff(lines_sf[2, ], angle = 0)
+  angle_diff(lines_sf[2:3, ], angle = 0)
+}
+#> Creating centroids representing desire line start and end points.
+#> Linking to GEOS 3.10.2, GDAL 3.4.1, PROJ 8.2.1; sf_use_s2() is TRUE
+#> [1]  92.2313 105.0539
+
+
+
+ + + -
- +
+ - - + + diff --git a/docs/reference/bbox_scale-1.png b/docs/reference/bbox_scale-1.png index 90884e26..3d9868b1 100644 Binary files a/docs/reference/bbox_scale-1.png and b/docs/reference/bbox_scale-1.png differ diff --git a/docs/reference/bbox_scale.html b/docs/reference/bbox_scale.html index f966d634..29b41cc4 100644 --- a/docs/reference/bbox_scale.html +++ b/docs/reference/bbox_scale.html @@ -1,254 +1,157 @@ - - - - - - - -Scale a bounding box — bbox_scale • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Scale a bounding box

- Source: R/geo-functions.R - +
+

Scale a bounding box

+ Source: R/geo-functions.R +
bbox_scale.Rd
-
+

Takes a bounding box as an input and outputs a bounding box of a different size, centred at the same point.

- 
bbox_scale(bb, scale_factor)
+
+

Usage

+ 
bbox_scale(bb, scale_factor)
+
-

Arguments

- - - - - - - - - - -
bb

the bounding box or spatial object that will be used to crop shp

scale_factor

Numeric vector determining how much the bounding box will grow or shrink. -Two numbers refer to extending the bounding box in x and y dimensions, respectively. -If the value is 1, the output size will be the same as the input.

+
+

Arguments

+
bb
+

Bounding box object

-

See also

-

Other geo: -gclip(), -geo_bb_matrix(), -geo_bb(), -mapshape_available(), -mapshape(), -quadrant(), -reproject()

+
scale_factor
+

Numeric vector determining how much the bounding box will grow or shrink. +Two numbers refer to extending the bounding box in x and y dimensions, respectively. +If the value is 1, the output size will be the same as the input.

+ +
+
+

See also

+

Other geo: +geo_bb_matrix(), +geo_bb(), +geo_buffer(), +geo_length(), +geo_projected(), +geo_select_aeq(), +quadrant()

+
-

Examples

- 
bb <- matrix(c(-1.55, 53.80, -1.50, 53.83), nrow = 2)
-bb1 <- bbox_scale(bb, scale_factor = 1.05)
-bb2 <- bbox_scale(bb, scale_factor = c(2, 1.05))
-bb3 <- bbox_scale(bb, 0.1)
-plot(x = bb2[1, ], y = bb2[2, ])
-
points(bb1[1, ], bb1[2, ])
-
points(bb3[1, ], bb3[2, ])
-
points(bb[1, ], bb[2, ], col = "red")
-
-
- -
+
+

Examples

+ 
bb <- matrix(c(-1.55, 53.80, -1.50, 53.83), nrow = 2)
+bb1 <- bbox_scale(bb, scale_factor = 1.05)
+bb2 <- bbox_scale(bb, scale_factor = c(2, 1.05))
+bb3 <- bbox_scale(bb, 0.1)
+plot(x = bb2[1, ], y = bb2[2, ])
+points(bb1[1, ], bb1[2, ])
+points(bb3[1, ], bb3[2, ])
+points(bb[1, ], bb[2, ], col = "red")
+
+
+
+
-
+ - - + + diff --git a/docs/reference/flow.html b/docs/reference/flow.html index 742435b9..a5165e15 100644 --- a/docs/reference/flow.html +++ b/docs/reference/flow.html @@ -1,172 +1,85 @@ - - - - - - - -data frame of commuter flows — flow • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

data frame of commuter flows

- Source: R/data.R - +
+

Data frame of commuter flows

+ Source: R/data.R +
flow.Rd
-
+

This dataset represents commuter flows (work travel) between origin -and destination zones (see cents()). +and destination zones. The data is from the UK and is available as open data: -https://wicid.ukdataservice.ac.uk/.

+https://wicid.ukdataservice.ac.uk/.

- 
data(flow)
- - -

Format

+
+

Format

A data frame with 49 rows and 15 columns

-

Details

- +
+
+

Details

The variables are as follows:

-
-
- -
+
-
+ - - + + diff --git a/docs/reference/flow_dests.html b/docs/reference/flow_dests.html index 89a13ab6..1beaf67a 100644 --- a/docs/reference/flow_dests.html +++ b/docs/reference/flow_dests.html @@ -1,247 +1,160 @@ - - - - - - - -data frame of invented -commuter flows with destinations in a different layer than the origins — flow_dests • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

data frame of invented +
+

Data frame of invented commuter flows with destinations in a different layer than the origins

- Source: R/data.R - + Source: R/data.R +
flow_dests.Rd
-
-

data frame of invented +

+

Data frame of invented commuter flows with destinations in a different layer than the origins

- 
data(flow_dests)
- - -

Format

+
+

Usage

+ 
data(flow_dests)
+
+
+

Format

A data frame with 49 rows and 15 columns

-

See also

- -

Other example data: -destination_zones, -flowlines, -flow, -route_network, -routes_fast, -routes_slow

- -

Examples

- 
if (FALSE) {
-# This is how the dataset was constructed
-flow_dests <- flow
-flow_dests$Area.of.workplace <- sample(x = destinations$WZ11CD, size = nrow(flow))
-flow_dests <- dplyr::rename(flow_dests, WZ11CD = Area.of.workplace)
-devtools::use_data(flow_dests)
-}
+    

+    

+    
See also

+    
Other data: 
+cents_sf,
+destinations_sf,
+flowlines_sf,
+flow,
+od_data_lines,
+od_data_routes,
+od_data_sample,
+osm_net_example,
+read_table_builder(),
+route_network_sf,
+route_network_small,
+routes_fast_sf,
+routes_slow_sf,
+zones_sf

+    

 
-
-
- -

+
+

Examples

+ 
if (FALSE) {
+# This is how the dataset was constructed
+flow_dests <- flow
+flow_dests$Area.of.workplace <- sample(x = destinations$WZ11CD, size = nrow(flow))
+flow_dests <- dplyr::rename(flow_dests, WZ11CD = Area.of.workplace)
+devtools::use_data(flow_dests)
+}
+
+
+
-
+ - - + + diff --git a/docs/reference/geo_bb-1.png b/docs/reference/geo_bb-1.png index b7aaf355..7e6abd99 100644 Binary files a/docs/reference/geo_bb-1.png and b/docs/reference/geo_bb-1.png differ diff --git a/docs/reference/geo_bb.html b/docs/reference/geo_bb.html index 52d79377..54c6f213 100644 --- a/docs/reference/geo_bb.html +++ b/docs/reference/geo_bb.html @@ -1,269 +1,181 @@ - - - - - - - -Flexible function to generate bounding boxes — geo_bb • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Flexible function to generate bounding boxes

- Source: R/geo-functions.R - +
+

Flexible function to generate bounding boxes

+ Source: R/geo-functions.R +
geo_bb.Rd
-
+

Takes a geographic object or bounding box as an input and outputs a bounding box, represented as a bounding box, corner points or rectangular polygon.

- 
geo_bb(
-  shp,
-  scale_factor = 1,
-  distance = 0,
-  output = c("polygon", "points", "bb")
-)
+
+

Usage

+ 
geo_bb(
+  shp,
+  scale_factor = 1,
+  distance = 0,
+  output = c("polygon", "points", "bb")
+)
+
+ +
+

Arguments

+
shp
+

Spatial object

-

Arguments

- - - - - - - - - - - - - - - - - - -
shp

Spatial object (from sf or sp packages)

scale_factor

Numeric vector determining how much the bounding box will grow or shrink. + +

scale_factor
+

Numeric vector determining how much the bounding box will grow or shrink. Two numbers refer to extending the bounding box in x and y dimensions, respectively. -If the value is 1, the output size will be the same as the input.

distance

Distance in metres to extend the bounding box by

output

Type of object returned (polygon by default)

+If the value is 1, the output size will be the same as the input.

+ + +
distance
+

Distance in metres to extend the bounding box by

-

See also

-

bb_scale

+
output
+

Type of object returned (polygon by default)

+ +
+
+

See also

+

bb_scale

Other geo: -bbox_scale(), -gclip(), -geo_bb_matrix(), -mapshape_available(), -mapshape(), -quadrant(), -reproject()

+bbox_scale(), +geo_bb_matrix(), +geo_buffer(), +geo_length(), +geo_projected(), +geo_select_aeq(), +quadrant()

+
-

Examples

- 
# Simple features implementation:
-shp <- routes_fast_sf
-shp_bb <- geo_bb(shp, distance = 100)
-
#> Assuming a geographical (lat/lon) CRS (EPSG:4326)
#> Transforming to CRS +proj=aeqd +lat_0=53.816446 +lon_0=-1.5309755 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
#> Warning: CRS object has comment, which is lost in output
plot(shp_bb, col = "red", reset = FALSE)
-
plot(geo_bb(routes_fast_sf, scale_factor = 0.8), col = "green", add = TRUE)
-
plot(geo_bb(routes_fast_sf, output = "points"), add = TRUE)
-
plot(routes_fast_sf$geometry, add = TRUE)
-
-
- -
+
+

Examples

+ 
shp <- routes_fast_sf
+shp_bb <- geo_bb(shp, distance = 100)
+plot(shp_bb, col = "red", reset = FALSE)
+plot(geo_bb(routes_fast_sf, scale_factor = 0.8), col = "green", add = TRUE)
+plot(routes_fast_sf$geometry, add = TRUE)
+
+geo_bb(shp, output = "point")
+#> Geometry set for 4 features 
+#> Geometry type: POINT
+#> Dimension:     XY
+#> Bounding box:  xmin: -1.550964 ymin: 53.80248 xmax: -1.510987 ymax: 53.83041
+#> Geodetic CRS:  WGS 84
+#> POINT (-1.550964 53.80248)
+#> POINT (-1.510987 53.80248)
+#> POINT (-1.510987 53.83041)
+#> POINT (-1.550964 53.83041)
+
+
+
-
+ - - + + diff --git a/docs/reference/geo_bb_matrix.html b/docs/reference/geo_bb_matrix.html index a7f2691f..7d913730 100644 --- a/docs/reference/geo_bb_matrix.html +++ b/docs/reference/geo_bb_matrix.html @@ -1,255 +1,158 @@ - - - - - - - -Create matrix representing the spatial bounds of an object — geo_bb_matrix • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Create matrix representing the spatial bounds of an object

- Source: R/geo-functions.R - +
+

Create matrix representing the spatial bounds of an object

+ Source: R/geo-functions.R +
geo_bb_matrix.Rd
-
+

Converts a range of spatial data formats into a matrix representing the bounding box

- 
geo_bb_matrix(shp)
- -

Arguments

- - - - - - -
shp

Spatial object (from sf or sp packages)

- -

See also

+
+

Usage

+ 
geo_bb_matrix(shp)
+
-

Other geo: -bbox_scale(), -gclip(), -geo_bb(), -mapshape_available(), -mapshape(), -quadrant(), -reproject()

+
+

Arguments

+
shp
+

Spatial object

+ +
+
+

See also

+

Other geo: +bbox_scale(), +geo_bb(), +geo_buffer(), +geo_length(), +geo_projected(), +geo_select_aeq(), +quadrant()

+
-

Examples

- 
geo_bb_matrix(routes_fast)
-
#>         min       max
-#> x -1.550807 -1.511861
-#> y 53.804098 53.828874
geo_bb_matrix(routes_fast_sf)
-
#>           [,1]      [,2]
-#> [1,] -1.550964 -1.510987
-#> [2,] 53.802478 53.830414
geo_bb_matrix(cents[1, ])
-
#>                 min       max
-#> coords.x1 -1.546463 -1.546463
-#> coords.x2 53.809517 53.809517
geo_bb_matrix(c(-2, 54))
-
#>      [,1] [,2]
-#> [1,]   -2   -2
-#> [2,]   54   54
geo_bb_matrix(sf::st_coordinates(cents_sf))
-
#>           [,1]      [,2]
-#> [1,] -1.550806 -1.511861
-#> [2,] 53.804098 53.828874
-
- -
+
+

Examples

+ 
geo_bb_matrix(routes_fast_sf)
+#>           [,1]      [,2]
+#> [1,] -1.550964 -1.510987
+#> [2,] 53.802478 53.830414
+geo_bb_matrix(cents_sf[1, ])
+#>           [,1]      [,2]
+#> [1,] -1.546463 -1.546463
+#> [2,] 53.809517 53.809517
+geo_bb_matrix(c(-2, 54))
+#>      [,1] [,2]
+#> [1,]   -2   -2
+#> [2,]   54   54
+geo_bb_matrix(sf::st_coordinates(cents_sf))
+#>           [,1]      [,2]
+#> [1,] -1.550806 -1.511861
+#> [2,] 53.804098 53.828874
+
+
+
-
+ - - + + diff --git a/docs/reference/geo_buffer.html b/docs/reference/geo_buffer.html index 4d51ac49..8a8e2591 100644 --- a/docs/reference/geo_buffer.html +++ b/docs/reference/geo_buffer.html @@ -1,262 +1,187 @@ - - - - - - - -Perform a buffer operation on a temporary projected CRS — geo_buffer • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Perform a buffer operation on a temporary projected CRS

- Source: R/geo_projected.R - +
+

Perform a buffer operation on a temporary projected CRS

+ Source: R/geo_projected.R +
geo_buffer.Rd
-
+

This function solves the problem that buffers will not be circular when used on non-projected data.

- 
geo_buffer(shp, dist = NULL, width = NULL, ...)
+
+

Usage

+ 
geo_buffer(shp, dist = NULL, width = NULL, ...)
+
+ +
+

Arguments

+
shp
+

A spatial object with a geographic CRS (e.g. WGS84) +around which a buffer should be drawn

+ + +
dist
+

The distance (in metres) of the buffer (when buffering simple features)

+ + +
width
+

The distance (in metres) of the buffer (when buffering sp objects)

-

Arguments

- - - - - - - - - - - - - - - - - - -
shp

A spatial object with a geographic CRS (e.g. WGS84) -around which a buffer should be drawn

dist

The distance (in metres) of the buffer (when buffering simple features)

width

The distance (in metres) of the buffer (when buffering sp objects)

...

Arguments passed to the buffer (see ?rgeos::gBuffer or ?sf::st_buffer for details)

-

Details

+
...
+

Arguments passed to the buffer (see ?sf::st_buffer for details)

+
+
+

Details

Requires recent version of PROJ (>= 6.3.0). Buffers on sf objects with geographic (lon/lat) coordinates can also -be done with the s2 package.

+be done with the s2 package.

+
+
+

See also

+

Other geo: +bbox_scale(), +geo_bb_matrix(), +geo_bb(), +geo_length(), +geo_projected(), +geo_select_aeq(), +quadrant()

+
-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
if(lib_versions[3] >= "6.3.1") {
-  buff_sf <- geo_buffer(routes_fast_sf, dist = 50)
-  plot(buff_sf$geometry, add = TRUE)
-  geo_buffer(routes_fast_sf$geometry, dist = 50)
-  # on legacy sp objects (not tested)
-  buff_sp <- geo_buffer(routes_fast, width = 100)
-  class(buff_sp)
-  plot(buff_sp, col = "red")
-}
-
#> Error in polypath(p_bind(x[[i]]), border = border[i], lty = lty[i], lwd = lwd[i],     col = col[i], rule = rule): plot.new has not been called yet
-
- -
+
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+if (lib_versions[3] >= "6.3.1") {
+  buff_sf <- geo_buffer(routes_fast_sf, dist = 50)
+  plot(buff_sf$geometry)
+  geo_buffer(routes_fast_sf$geometry, dist = 50)
+}
+
+#> Geometry set for 49 features 
+#> Geometry type: POLYGON
+#> Dimension:     XY
+#> Bounding box:  xmin: -1.551723 ymin: 53.80203 xmax: -1.510228 ymax: 53.83086
+#> Geodetic CRS:  WGS 84
+#> First 5 geometries:
+#> POLYGON ((-1.515974 53.82887, -1.515975 53.8288...
+#> POLYGON ((-1.535569 53.82873, -1.535517 53.8287...
+#> POLYGON ((-1.550723 53.82451, -1.550871 53.8248...
+#> POLYGON ((-1.530548 53.81706, -1.530586 53.8170...
+#> POLYGON ((-1.518697 53.81731, -1.51892 53.81742...
+
+
+
-
+ - - + + diff --git a/docs/reference/geo_code.html b/docs/reference/geo_code.html index 6970df44..3ce9cea0 100644 --- a/docs/reference/geo_code.html +++ b/docs/reference/geo_code.html @@ -1,265 +1,161 @@ - - - - - - - -Convert text strings into points on the map — geo_code • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert text strings into points on the map

- Source: R/geo_code.R - +
+

Convert text strings into points on the map

+ Source: R/geo_code.R +
geo_code.Rd
-
+

Generate a lat/long pair from data using Google's geolocation API.

- 
geo_code(
-  address,
-  service = "nominatim",
-  base_url = "https://maps.google.com/maps/api/geocode/json",
-  return_all = FALSE,
-  pat = NULL
-)
+
+

Usage

+ 
geo_code(
+  address,
+  service = "nominatim",
+  base_url = "https://maps.google.com/maps/api/geocode/json",
+  return_all = FALSE,
+  pat = NULL
+)
+
-

Arguments

- - - - - - - - - - - - - - - - - - - - - - -
address

Text string representing the address you want to geocode

service

Which service to use? Nominatim by default

base_url

The base url to query

return_all

Should the request return all information returned by Google Maps? -The default is FALSE: to return only two numbers: the longitude and latitude, in that order

pat

The API key used. By default this is set to NULL and -this is usually aquired automatically through a helper, api_pat().

+
+

Arguments

+
address
+

Text string representing the address you want to geocode

-

See also

-

Other nodes: -nearest_google()

+
service
+

Which service to use? Nominatim by default

+ + +
base_url
+

The base url to query

-

Examples

- 
if (FALSE) {
-geo_code(address = "Hereford")
-geo_code("LS7 3HB")
-geo_code("hereford", return_all = TRUE)
-# needs api key in .Renviron
-geo_code("hereford", service = "google", pat = Sys.getenv("GOOGLE"), return_all = TRUE)
-}
-
-
- -
+
return_all
+

Should the request return all information returned by Google Maps? +The default is FALSE: to return only two numbers: the longitude and latitude, in that order

-
- -
+ +
pat
+

Personal access token

+ +
+ +
+

Examples

+ 
if (FALSE) {
+geo_code(address = "Hereford")
+geo_code("LS7 3HB")
+geo_code("hereford", return_all = TRUE)
+# needs api key in .Renviron
+geo_code("hereford", service = "google", pat = Sys.getenv("GOOGLE"), return_all = TRUE)
+}
+
+
+
+ + + -
- +
+ - - + + diff --git a/docs/reference/geo_length.html b/docs/reference/geo_length.html index 0df833da..fd278f83 100644 --- a/docs/reference/geo_length.html +++ b/docs/reference/geo_length.html @@ -1,245 +1,161 @@ - - - - - - - -Calculate line length of line with geographic or projected CRS — geo_length • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Calculate line length of line with geographic or projected CRS

- Source: R/geo_projected.R - +
+

Calculate line length of line with geographic or projected CRS

+ Source: R/geo_projected.R +
geo_length.Rd
-
+

Takes a line (represented in sf or sp classes) and returns a numeric value representing distance in meters.

- 
geo_length(shp)
- -

Arguments

- - - - - - -
shp

A spatial line object

+
+

Usage

+ 
geo_length(shp)
+
+
+

Arguments

+
shp
+

A spatial line object

+ +
+
+

See also

+

Other geo: +bbox_scale(), +geo_bb_matrix(), +geo_bb(), +geo_buffer(), +geo_projected(), +geo_select_aeq(), +quadrant()

+
-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
if(lib_versions[3] >= "6.3.1") {
-  geo_length(routes_fast)
-  geo_length(routes_fast_sf)
-}
-
#>  [1]    0.0000 1538.8810 2990.7783 2297.5929 1870.2117 2239.1301 3352.8345
-#>  [8] 1538.8810    0.0000 1580.7084 1506.1390 2483.2391 3156.1339 3877.7765
-#> [15] 2992.2337 1708.4876    0.0000 2121.8359 3098.9361 3768.5096 3711.6150
-#> [22] 2366.0647 1506.1390 2078.5604    0.0000  977.1004 1646.6739 2371.6377
-#> [29] 1875.7200 2483.2391 3055.6605  977.1004    0.0000  872.9039 1727.9827
-#> [36] 2239.4037 3085.7290 3725.2340 1646.6739  872.9039    0.0000 1303.2590
-#> [43] 3285.0306 3829.5751 3868.1338 2323.4363 1727.9827 1303.2590    0.0000
-
- -
+
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+if (lib_versions[3] >= "6.3.1") {
+  geo_length(routes_fast_sf)
+}
+#>  [1]    0.0000 1538.8810 2990.7783 2297.5929 1870.2117 2239.1301 3352.8345
+#>  [8] 1538.8810    0.0000 1580.7084 1506.1390 2483.2391 3156.1339 3877.7765
+#> [15] 2992.2337 1708.4876    0.0000 2121.8359 3098.9361 3768.5096 3711.6150
+#> [22] 2366.0647 1506.1390 2078.5604    0.0000  977.1004 1646.6739 2371.6377
+#> [29] 1875.7200 2483.2391 3055.6605  977.1004    0.0000  872.9039 1727.9827
+#> [36] 2239.4037 3085.7290 3725.2340 1646.6739  872.9039    0.0000 1303.2590
+#> [43] 3285.0306 3829.5751 3868.1338 2323.4363 1727.9827 1303.2590    0.0000
+
+
+
-
+ - - + + diff --git a/docs/reference/geo_projected.html b/docs/reference/geo_projected.html index 67251fba..8e4c80cf 100644 --- a/docs/reference/geo_projected.html +++ b/docs/reference/geo_projected.html @@ -1,271 +1,187 @@ - - - - - - - -Perform GIS functions on a temporary, projected version of a spatial object — geo_projected • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Perform GIS functions on a temporary, projected version of a spatial object

- Source: R/geo_projected.R - +
+

Perform GIS functions on a temporary, projected version of a spatial object

+ Source: R/geo_projected.R +
geo_projected.Rd
-
+

This function performs operations on projected data.

- 
geo_projected(shp, fun, crs, silent, ...)
+
+

Usage

+ 
geo_projected(shp, fun, crs, silent, ...)
+
-

Arguments

- - - - - - - - - - - - - - - - - - - - - - -
shp

A spatial object with a geographic (WGS84) coordinate system

fun

A function to perform on the projected object (e.g. the the rgeos or sf packages)

crs

An optional coordinate reference system (if not provided it is set -automatically by geo_select_aeq())

silent

A binary value for printing the CRS details (default: TRUE)

...

Arguments to pass to fun, e.g. byid = TRUE if the function is rgeos::gLength()

+
+

Arguments

+
shp
+

A spatial object with a geographic (WGS84) coordinate system

-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
# fails on some systems (with early versions of PROJ)
-if(lib_versions[3] >= "6.3.1") {
-  shp <- routes_fast_sf[2:4, ]
-  geo_projected(shp, sf::st_buffer, dist = 100)
-}
-
#> Simple feature collection with 3 features and 16 fields
-#> geometry type:  POLYGON
-#> dimension:      XY
-#> bbox:           xmin: -1.552483 ymin: 53.81661 xmax: -1.511078 ymax: 53.83131
-#> geographic CRS: WGS 84
-#>   plan start finish length time waypoint cum_hill change_elev dif_max_min
-#> 2    1     1      1   1535  464       53       87          -7          39
-#> 3    1     1      1   2976  829       97      112          -4          39
-#> 4    1     1      1   2290  502       37      103         -45          65
-#>   up_tot down_tot av_incline co2_saving calories busyness ID
-#> 2     40       47 0.05667752        286       52     3327  2
-#> 3     54       58 0.03763441        555       78     7062  3
-#> 4     29       74 0.04497817        427       38     3380  4
-#>                         geometry
-#> 2 POLYGON ((-1.535639 53.8292...
-#> 3 POLYGON ((-1.551653 53.8248...
-#> 4 POLYGON ((-1.530458 53.8166...
-
- -
+
fun
+

A function to perform on the projected object (e.g. from the sf package)

+ + +
crs
+

An optional coordinate reference system (if not provided it is set +automatically by geo_select_aeq())

+ +
silent
+

A binary value for printing the CRS details (default: TRUE)

-
- -
+ +
...
+

Arguments to pass to fun

+ +
+
+

See also

+

Other geo: +bbox_scale(), +geo_bb_matrix(), +geo_bb(), +geo_buffer(), +geo_length(), +geo_select_aeq(), +quadrant()

+
+ +
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+# fails on some systems (with early versions of PROJ)
+if (lib_versions[3] >= "6.3.1") {
+  shp <- routes_fast_sf[2:4, ]
+  geo_projected(shp, sf::st_buffer, dist = 100)
+}
+#> Simple feature collection with 3 features and 16 fields
+#> Geometry type: POLYGON
+#> Dimension:     XY
+#> Bounding box:  xmin: -1.552483 ymin: 53.81661 xmax: -1.511078 ymax: 53.83131
+#> Geodetic CRS:  WGS 84
+#>   plan start finish length time waypoint cum_hill change_elev dif_max_min
+#> 2    1     1      1   1535  464       53       87          -7          39
+#> 3    1     1      1   2976  829       97      112          -4          39
+#> 4    1     1      1   2290  502       37      103         -45          65
+#>   up_tot down_tot av_incline co2_saving calories busyness ID
+#> 2     40       47 0.05667752        286       52     3327  2
+#> 3     54       58 0.03763441        555       78     7062  3
+#> 4     29       74 0.04497817        427       38     3380  4
+#>                         geometry
+#> 2 POLYGON ((-1.535639 53.8292...
+#> 3 POLYGON ((-1.551653 53.8248...
+#> 4 POLYGON ((-1.530458 53.8166...
+
+
+
+ + + -
- +
+ - - + + diff --git a/docs/reference/geo_select_aeq.html b/docs/reference/geo_select_aeq.html index f7ac0676..1c11d4a6 100644 --- a/docs/reference/geo_select_aeq.html +++ b/docs/reference/geo_select_aeq.html @@ -1,287 +1,194 @@ - - - - - - - -Select a custom projected CRS for the area of interest — geo_select_aeq • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Select a custom projected CRS for the area of interest

- Source: R/geo_projected.R - +
+

Select a custom projected CRS for the area of interest

+ Source: R/geo_projected.R +
geo_select_aeq.Rd
-
+

This function takes a spatial object with a geographic (WGS84) CRS and returns a custom projected CRS focussed on the centroid of the object. This function is especially useful for using units of metres in all directions for data collected anywhere in the world.

- 
geo_select_aeq(shp)
- -

Arguments

- - - - - - -
shp

A spatial object with a geographic (WGS84) coordinate system

+
+

Usage

+ 
geo_select_aeq(shp)
+
-

Details

+
+

Arguments

+
shp
+

A spatial object with a geographic (WGS84) coordinate system

+
+
+

Details

The function is based on this stackexchange answer: -https://gis.stackexchange.com/questions/121489

+https://gis.stackexchange.com/questions/121489

+
+
+

See also

+

Other geo: +bbox_scale(), +geo_bb_matrix(), +geo_bb(), +geo_buffer(), +geo_length(), +geo_projected(), +quadrant()

+
-

Examples

- 
sp::bbox(routes_fast)
-
#>         min       max
-#> x -1.550807 -1.511861
-#> y 53.804098 53.828874
new_crs <- geo_select_aeq(routes_fast)
-rf_projected <- sp::spTransform(routes_fast, new_crs)
-sp::bbox(rf_projected)
-
#>         min      max
-#> x -1545.979 1086.642
-#> y -1833.567 1275.756
line_length <- rgeos::gLength(rf_projected, byid = TRUE)
-plot(line_length, rf_projected$length)
-
shp <- zones_sf
-geo_select_aeq(shp)
-
#> Coordinate Reference System:
-#>   User input: +proj=aeqd +lat_0=53.8183052800959 +lon_0=-1.53014431833907 +x_0=0 +y_0=0 
-#>   wkt:
-#> PROJCRS["unknown",
-#>     BASEGEOGCRS["unknown",
-#>         DATUM["World Geodetic System 1984",
-#>             ELLIPSOID["WGS 84",6378137,298.257223563,
-#>                 LENGTHUNIT["metre",1]],
-#>             ID["EPSG",6326]],
-#>         PRIMEM["Greenwich",0,
-#>             ANGLEUNIT["degree",0.0174532925199433],
-#>             ID["EPSG",8901]]],
-#>     CONVERSION["unknown",
-#>         METHOD["Modified Azimuthal Equidistant",
-#>             ID["EPSG",9832]],
-#>         PARAMETER["Latitude of natural origin",53.8183052800959,
-#>             ANGLEUNIT["degree",0.0174532925199433],
-#>             ID["EPSG",8801]],
-#>         PARAMETER["Longitude of natural origin",-1.53014431833907,
-#>             ANGLEUNIT["degree",0.0174532925199433],
-#>             ID["EPSG",8802]],
-#>         PARAMETER["False easting",0,
-#>             LENGTHUNIT["metre",1],
-#>             ID["EPSG",8806]],
-#>         PARAMETER["False northing",0,
-#>             LENGTHUNIT["metre",1],
-#>             ID["EPSG",8807]]],
-#>     CS[Cartesian,2],
-#>         AXIS["(E)",east,
-#>             ORDER[1],
-#>             LENGTHUNIT["metre",1,
-#>                 ID["EPSG",9001]]],
-#>         AXIS["(N)",north,
-#>             ORDER[2],
-#>             LENGTHUNIT["metre",1,
-#>                 ID["EPSG",9001]]]]
-
- -
+
+

Examples

+ 
shp <- zones_sf
+geo_select_aeq(shp)
+#> Coordinate Reference System:
+#>   User input: +proj=aeqd +lat_0=53.8183052800959 +lon_0=-1.53014431833907 +x_0=0 +y_0=0 
+#>   wkt:
+#> PROJCRS["unknown",
+#>     BASEGEOGCRS["unknown",
+#>         DATUM["World Geodetic System 1984",
+#>             ELLIPSOID["WGS 84",6378137,298.257223563,
+#>                 LENGTHUNIT["metre",1]],
+#>             ID["EPSG",6326]],
+#>         PRIMEM["Greenwich",0,
+#>             ANGLEUNIT["degree",0.0174532925199433],
+#>             ID["EPSG",8901]]],
+#>     CONVERSION["unknown",
+#>         METHOD["Modified Azimuthal Equidistant",
+#>             ID["EPSG",9832]],
+#>         PARAMETER["Latitude of natural origin",53.8183052800959,
+#>             ANGLEUNIT["degree",0.0174532925199433],
+#>             ID["EPSG",8801]],
+#>         PARAMETER["Longitude of natural origin",-1.53014431833907,
+#>             ANGLEUNIT["degree",0.0174532925199433],
+#>             ID["EPSG",8802]],
+#>         PARAMETER["False easting",0,
+#>             LENGTHUNIT["metre",1],
+#>             ID["EPSG",8806]],
+#>         PARAMETER["False northing",0,
+#>             LENGTHUNIT["metre",1],
+#>             ID["EPSG",8807]]],
+#>     CS[Cartesian,2],
+#>         AXIS["(E)",east,
+#>             ORDER[1],
+#>             LENGTHUNIT["metre",1,
+#>                 ID["EPSG",9001]]],
+#>         AXIS["(N)",north,
+#>             ORDER[2],
+#>             LENGTHUNIT["metre",1,
+#>                 ID["EPSG",9001]]]]
+
+
+
-
+ - - + + diff --git a/docs/reference/geo_toptail.html b/docs/reference/geo_toptail.html index 30cb9e2f..5bbcc380 100644 --- a/docs/reference/geo_toptail.html +++ b/docs/reference/geo_toptail.html @@ -1,281 +1,184 @@ - - - - - - - -Clip the first and last n metres of SpatialLines — geo_toptail • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Clip the first and last n metres of SpatialLines

- Source: R/toptail.R - +
+

Clip the first and last n metres of SpatialLines

+ Source: R/toptail.R +
geo_toptail.Rd
-
+

Takes lines and removes the start and end point, to a distance determined by the user.

- 
geo_toptail(l, toptail_dist, ...)
+
+

Usage

+ 
geo_toptail(l, toptail_dist, ...)
+
+ +
+

Arguments

+
l
+

An sf object representing lines

-

Arguments

- - - - - - - - - - - - - - -
l

A SpatialLines object

toptail_dist

The distance (in metres) to top and tail the line by. + +

toptail_dist
+

The distance (in metres) to top and tail the line by. Can either be a single value or a vector of the same length as the -SpatialLines object.

...

Arguments passed to rgeos::gBuffer()

+SpatialLines object.

-

Details

-

Note: toptailgs() is around 10 times faster, but only works -on data with geographic CRS's due to its reliance on the geosphere -package.

-

See also

+
...
+

Arguments passed to sf::st_buffer()

-

Other lines: -angle_diff(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+
+

Details

+

Note: see the function +toptailgs() +in stplanr v0.8.5 for an implementation that uses the geosphere +package.

+
+
+

See also

+

Other lines: +angle_diff(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
# dont test due to issues with sp classes on some set-ups
-if(lib_versions[3] >= "6.3.1") {
-  # l <- routes_fast[2:4, ] # to run with sp classes
-  l <- routes_fast_sf[2:4, ]
-  l_top_tail <- geo_toptail(l, 300)
-  l_top_tail
-  plot(sf::st_geometry(l_top_tail))
-  plot(sf::st_geometry(geo_toptail(l, 600)), lwd = 9, add = TRUE)
-}
-
-
- -
+
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+# dont test due to issues with sp classes on some set-ups
+if (lib_versions[3] >= "6.3.1") {
+  l <- routes_fast_sf[2:4, ]
+  l_top_tail <- geo_toptail(l, 300)
+  l_top_tail
+  plot(sf::st_geometry(l_top_tail))
+  plot(sf::st_geometry(geo_toptail(l, 600)), lwd = 9, add = TRUE)
+}
+
+
+
+
-
+ - - + + diff --git a/docs/reference/gsection.html b/docs/reference/gsection.html index e5185db1..975c1073 100644 --- a/docs/reference/gsection.html +++ b/docs/reference/gsection.html @@ -1,280 +1,169 @@ - - - - - - - -Function to split overlapping SpatialLines into segments — gsection • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Function to split overlapping SpatialLines into segments

- Source: R/overline.R - +
+

Function to split overlapping SpatialLines into segments

+ Source: R/overline.R +
gsection.Rd
-
+

Divides SpatialLinesDataFrame objects into separate Lines. Each new Lines object is the aggregate of a single number of aggregated lines.

- 
gsection(sl, buff_dist = 0)
- -

Arguments

- - - - - - - - - - -
sl

SpatialLinesDataFrame with overlapping Lines to split by -number of overlapping features.

buff_dist

A number specifying the distance in meters of the buffer to be used to crop lines before running the operation. -If the distance is zero (the default) touching but non-overlapping lines may be aggregated.

- -

See also

+
+

Usage

+ 
gsection(sl, buff_dist = 0)
+
-

Other rnet: -SpatialLinesNetwork, -calc_catchment_sum(), -calc_catchment(), -calc_moving_catchment(), -calc_network_catchment(), -find_network_nodes(), -islines(), -lineLabels(), -overline_spatial(), -overline(), -plot,SpatialLinesNetwork,ANY-method, -plot,sfNetwork,ANY-method, -rnet_breakup_vertices(), -rnet_group(), -sln2points(), -sum_network_links(), -sum_network_routes()

+
+

Arguments

+
sl
+

SpatialLinesDataFrame with overlapping Lines to split by +number of overlapping features.

+ + +
buff_dist
+

A number specifying the distance in meters of the buffer to be used to crop lines before running the operation. +If the distance is zero (the default) touching but non-overlapping lines may be aggregated.

+ +
+
+

See also

+

Other rnet: +islines(), +overline(), +rnet_breakup_vertices(), +rnet_group()

+
-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
# fails on some systems (with early versions of PROJ)
-if(lib_versions[3] >= "6.3.1") {
-  sl <- routes_fast_sf[2:4, ]
-  rsec <- gsection(sl)
-  length(rsec) # sections
-  plot(rsec, col = seq(length(rsec)))
-  rsec <- gsection(sl, buff_dist = 50)
-  length(rsec) # 4 features: issue
-  plot(rsec, col = seq(length(rsec)))
-  # dont test due to issues with sp classes on some set-ups
-  # sl <- routes_fast[2:4, ]
-  # rsec <- gsection(sl)
-  # rsec_buff <- gsection(sl, buff_dist = 1)
-  # plot(sl[1], lwd = 9, col = 1:nrow(sl))
-  # plot(rsec, col = 5 + (1:length(rsec)), add = TRUE, lwd = 3)
-  # plot(rsec_buff, col = 5 + (1:length(rsec_buff)), add = TRUE, lwd = 3)
-}
-
-
- -
+
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+# fails on some systems (with early versions of PROJ)
+if (lib_versions[3] >= "6.3.1") {
+  sl <- routes_fast_sf[2:4, ]
+  rsec <- gsection(sl)
+  length(rsec) # sections
+  plot(rsec, col = seq(length(rsec)))
+  rsec <- gsection(sl, buff_dist = 50)
+  length(rsec) # 4 features: issue
+  plot(rsec, col = seq(length(rsec)))
+}
+
+
+
+
+
-
+ - - + + diff --git a/docs/reference/index.html b/docs/reference/index.html index cdd63cdb..47b44aaa 100644 --- a/docs/reference/index.html +++ b/docs/reference/index.html @@ -1,794 +1,673 @@ - - - - - - - -Function reference • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Reference

+
+

Function reference

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-

Work with OD data

-

-
-

dist_google()

-

Return travel network distances and time using the Google Maps API

-

od2line() od2line2()

-

Convert origin-destination data to spatial lines

-

od2odf()

-

Extract coordinates from OD data

-

od_aggregate_from()

-

Summary statistics of trips originating from zones in OD data

-

od_aggregate_to()

-

Summary statistics of trips arriving at destination zones in OD data

-

od_coords()

-

Create matrices representing origin-destination coordinates

-

od_coords2line()

-

Convert origin-destination coordinates into desire lines

-

od_dist()

-

Quickly calculate Euclidean distances of od pairs

-

od_id_szudzik() od_id_max_min() od_id_character()

-

Combine two ID values to create a single ID number

-

od_oneway()

-

Aggregate od pairs they become non-directional

-

od_to_odmatrix()

-

Convert origin-destination data from long to wide format

-

odmatrix_to_od()

-

Convert origin-destination data from wide to long format

-

points2flow()

-

Convert a series of points into geographical flows

-

points2odf()

-

Convert a series of points into a dataframe of origins and destinations

-

Work with (desire) lines

-

-
-

angle_diff()

-

Calculate the angular difference between lines and a predefined bearing

-

geo_toptail()

-

Clip the first and last n metres of SpatialLines

-

is_linepoint()

-

Identify lines that are points

-

line2df()

-

Convert geographic line objects to a data.frame with from and to coords

-

line2points() line2pointsn() line2vertices()

-

Convert a spatial (linestring) object to points

-

line_bearing()

-

Find the bearing of straight lines

-

line_breakup()

-

Break up line objects into shorter segments

-

line_match()

-

Match two sets of lines based on similarity

-

line_midpoint()

-

Find the mid-point of lines

-

line_sample()

-

Sample n points along lines with density proportional to a weight

-

line_segment()

-

Divide SpatialLines dataset into regular segments

-

line_via()

-

Add geometry columns representing a route via intermediary points

-

mats2line()

-

Convert 2 matrices to lines

-

n_sample_length()

-

Sample integer number from given continuous vector of line lengths and probabilities, with total n

-

n_vertices()

-

Retrieve the number of vertices from a SpatialLines or SpatialPolygons object

-

onewaygeo()

-

Aggregate flows so they become non-directional (by geometry - the slow way)

-

points2line()

-

Convert a series of points, or a matrix of coordinates, into a line

-

toptail_buff()

-

Clip the beginning and ends SpatialLines to the edge of SpatialPolygon borders

-

toptailgs()

-

Clip the first and last n metres of SpatialLines

-

update_line_geometry()

-

Update line geometry

-

Work with and analyse routes

-

-
-

route_average_gradient()

-

Return average gradient across a route

-

route_rolling_average()

-

Return smoothed averages of vector

-

route_rolling_diff()

-

Return smoothed differences between vector values

-

route_rolling_gradient()

-

Calculate rolling average gradient from elevation data at segment level

-

route_sequential_dist()

-

Calculate the sequential distances between sequential coordinate pairs

-

route_slope_matrix()

-

Calculate the gradient of line segments from a matrix of coordinates

-

route_slope_vector()

-

Calculate the gradient of line segments from distance and elevation vectors

-

Routing

-

-
-

line2route()

-

Convert straight OD data (desire lines) into routes

-

line2routeRetry()

-

Convert straight spatial (linestring) object from flow data into routes retrying -on connection (or other) intermittent failures

-

route()

-

Plan routes on the transport network

-

route_dodgr()

-

Route on local data using the dodgr package

-

route_local()

-

Plan a route with local data

-

route_transportapi_public()

-

Plan a single route with TransportAPI.com

-

Work with nodes

-

-
-

geo_code()

-

Convert text strings into points on the map

-

nearest_google()

-

Generate nearest point on the route network of a point using the Google Maps API

-

Route network functions

-

-
-

SpatialLinesNetwork()

-

Create object of class SpatialLinesNetwork or sfNetwork

-

calc_catchment()

-

Calculate catchment area and associated summary statistics.

-

calc_catchment_sum()

-

Calculate summary statistics for catchment area.

-

calc_moving_catchment()

-

Calculate summary statistics for all features independently.

-

calc_network_catchment()

-

Calculate catchment area and associated summary statistics using network.

-

find_network_nodes()

-

Find graph node ID of closest node to given coordinates

-

gsection()

-

Function to split overlapping SpatialLines into segments

-

islines()

-

Do the intersections between two geometries create lines?

-

lineLabels()

-

Label SpatialLinesDataFrame objects

-

overline() overline2()

-

Convert series of overlapping lines into a route network

-

overline_spatial()

-

Spatial aggregation of routes represented with sp classes

-

plot(<SpatialLinesNetwork>,<ANY>)

-

Plot a SpatialLinesNetwork

-

plot(<sfNetwork>,<ANY>)

-

Plot an sfNetwork

-

rnet_breakup_vertices()

-

Break up an sf object with LINESTRING geometry.

-

rnet_group()

-

Assign segments in a route network to groups

-

sln2points()

-

Generate spatial points representing nodes on a SpatialLinesNetwork -or sfNetwork.

-

sum_network_links()

-

Summarise links from shortest paths data

-

sum_network_routes()

-

Summarise shortest path between nodes on network

-

Geographic functions

-

-
-

bbox_scale()

-

Scale a bounding box

-

gclip()

-

Crops spatial object x to the bounding box of spatial object (or matrix) b

-

geo_bb()

-

Flexible function to generate bounding boxes

-

geo_bb_matrix()

-

Create matrix representing the spatial bounds of an object

-

mapshape()

-

Simplify geometry of spatial objects with the mapshaper library

-

mapshape_available()

-

Does the computer have mapshaper available?

-

quadrant()

-

Split a spatial object into quadrants

-

reproject()

-

Reproject lat/long spatial object so that they are in units of 1m

-

Get transport data

-

-
-

read_table_builder()

-

Import and format Australian Bureau of Statistics (ABS) TableBuilder files

-

Example data

-

-
-
+
+

Work with OD data

+ + + + +
+ + + + +
+ + od2line() +
+
Convert origin-destination data to spatial lines
+
+ + od2odf() +
+
Extract coordinates from OD data
+
+ + od_aggregate_from() +
+
Summary statistics of trips originating from zones in OD data
+
+ + od_aggregate_to() +
+
Summary statistics of trips arriving at destination zones in OD data
+
+ + od_coords() +
+
Create matrices representing origin-destination coordinates
+
+ + od_coords2line() +
+
Convert origin-destination coordinates into desire lines
+
+ + od_id_szudzik() od_id_max_min() od_id_character() +
+
Combine two ID values to create a single ID number
+
+ + od_id_order() +
+
Generate ordered ids of OD pairs so lowest is always first +This function is slow on large datasets, see szudzik_pairing for faster alternative
+
+ + od_oneway() +
+
Aggregate od pairs they become non-directional
+
+ + od_to_odmatrix() +
+
Convert origin-destination data from long to wide format
+
+ + odmatrix_to_od() +
+
Convert origin-destination data from wide to long format
+
+ + points2flow() +
+
Convert a series of points into geographical flows
+
+ + points2odf() +
+
Convert a series of points into a dataframe of origins and destinations
+
+

Work with (desire) lines

+ + + + +
+ + + + +
+ + angle_diff() +
+
Calculate the angular difference between lines and a predefined bearing
+
+ + geo_toptail() +
+
Clip the first and last n metres of SpatialLines
+
+ + is_linepoint() +
+
Identify lines that are points
+
+ + line2df() +
+
Convert geographic line objects to a data.frame with from and to coords
+
+ + line2points() line2pointsn() line2vertices() +
+
Convert a spatial (linestring) object to points
+
+ + line_bearing() +
+
Find the bearing of straight lines
+
+ + line_breakup() +
+
Break up line objects into shorter segments
+
+ + line_midpoint() +
+
Find the mid-point of lines
+
+ + line_segment() +
+
Divide sf LINESTRING objects into regular segments
+
+ + line_via() +
+
Add geometry columns representing a route via intermediary points
+
+ + mats2line() +
+
Convert 2 matrices to lines
+
+ + n_vertices() +
+
Retrieve the number of vertices in sf objects
+
+ + onewaygeo() +
+
Aggregate flows so they become non-directional (by geometry - the slow way)
+
+ + points2line() +
+
Convert a series of points, or a matrix of coordinates, into a line
+
+ + toptail_buff() +
+
Clip the beginning and ends of sf LINESTRING objects
+
+ + line_cast() +
+
Convert multilinestring object into linestrings, without losing and vertices
+
+

Work with and analyse routes

+ + + + +
+ + + + +
+ + route_average_gradient() +
+
Return average gradient across a route
+
+ + route_rolling_average() +
+
Return smoothed averages of vector
+
+ + route_rolling_diff() +
+
Return smoothed differences between vector values
+
+ + route_rolling_gradient() +
+
Calculate rolling average gradient from elevation data at segment level
+
+ + route_sequential_dist() +
+
Calculate the sequential distances between sequential coordinate pairs
+
+ + route_slope_matrix() +
+
Calculate the gradient of line segments from a matrix of coordinates
+
+ + route_slope_vector() +
+
Calculate the gradient of line segments from distance and elevation vectors
+
+ + route() +
+
Plan routes on the transport network
+
+ + route_bikecitizens() +
+
Get a route from the BikeCitizens web service
+
+ + route_dodgr() +
+
Route on local data using the dodgr package
+
+ + route_google() +
+
Find shortest path using Google services
+
+ + route_nearest_point() +
+
Find nearest route to a given point
+
+ + route_network_sf +
+
Spatial lines dataset representing a route network
+
+ + route_network_small +
+
Spatial lines dataset representing a small route network
+
+ + route_osrm() +
+
Plan routes on the transport network using the OSRM server
+
+ + route_split() +
+
Split route in two at point on or near network
+
+ + route_split_id() +
+
Split route based on the id or coordinates of one of its vertices
+
+ + routes_fast_sf +
+
Spatial lines dataset of commuter flows on the travel network
+
+ + routes_slow_sf +
+
Spatial lines dataset of commuter flows on the travel network
+
+

Routing

+ + + + +
+ + + + +
+ + route() +
+
Plan routes on the transport network
+
+ + route_dodgr() +
+
Route on local data using the dodgr package
+
+ + route_osrm() +
+
Plan routes on the transport network using the OSRM server
+
+

Work with nodes

+ + + + +
+ + + + +
+ + geo_code() +
+
Convert text strings into points on the map
+
+

Route network functions

+ + + + +
+ + + + +
+ + rnet_add_node() +
+
Add a node to route network
+
+ + rnet_boundary_points() rnet_boundary_df() rnet_boundary_unique() rnet_boundary_points_lwgeom() rnet_duplicated_vertices() +
+
Get points at the beginner and end of linestrings
+
+ + rnet_breakup_vertices() +
+
Break up an sf object with LINESTRING geometry.
+
+ + rnet_cycleway_intersection +
+
Example of cycleway intersection data showing problems for SpatialLinesNetwork objects
+
+ + rnet_get_nodes() +
+
Extract nodes from route network
+
+ + rnet_group() +
+
Assign segments in a route network to groups
+
+ + rnet_join() +
+
Spatial join function that is designed to add columns to a 'target' route network +from a 'source' route network that contains the base geometry, e.g. from OSM
+
+ + rnet_overpass +
+
Example of overpass data showing problems for SpatialLinesNetwork objects
+
+ + rnet_roundabout +
+
Example of roundabout data showing problems for SpatialLinesNetwork objects
+
+ + rnet_split_lines() +
+
Split lines in a route network based points
+
+ + rnet_subset() +
+
Subset one route network based on overlaps with another
+
+ + overline() overline2() +
+
Convert series of overlapping lines into a route network
+
+ + overline_intersection() +
+
Convert series of overlapping lines into a route network
+
+ + gsection() +
+
Function to split overlapping SpatialLines into segments
+
+ + islines() +
+
Do the intersections between two geometries create lines?
+
+

Geographic functions

+ + + + +
+ + + + +
+ + bbox_scale() +
+
Scale a bounding box
+
+ + geo_bb() +
+
Flexible function to generate bounding boxes
+
+ + geo_bb_matrix() +
+
Create matrix representing the spatial bounds of an object
+
+ + geo_buffer() +
+
Perform a buffer operation on a temporary projected CRS
+
+ + geo_length() +
+
Calculate line length of line with geographic or projected CRS
+
+ + geo_projected() +
+
Perform GIS functions on a temporary, projected version of a spatial object
+
+ + geo_select_aeq() +
+
Select a custom projected CRS for the area of interest
+
+ + quadrant() +
+
Split a spatial object into quadrants
+
+ + stplanr-deprecated +
+
Deprecated functions in stplanr
+
+ + stplanr-package stplanr +
+
stplanr: Sustainable Transport Planning with R
+
+

Get transport data

+ + + + +
+ + + + +
+ + cents_sf +
+
Spatial points representing home locations
+
+ + destinations_sf +
+
Example destinations data
+
+ + flow +
+
Data frame of commuter flows
+
+ + flow_dests +
+
Data frame of invented +commuter flows with destinations in a different layer than the origins
+
+ + flowlines_sf +
+
Spatial lines dataset of commuter flows
+
+ + od_data_lines +
+
Example of desire line representations of origin-destination data from UK Census
+
+ + od_data_routes +
+
Example segment-level route data
+
+ + od_data_sample +
+
Example of origin-destination data from UK Census
+
+ + osm_net_example +
+
Example of OpenStreetMap road network
+
+ + read_table_builder() +
+
Import and format Australian Bureau of Statistics (ABS) TableBuilder files
+
+ + route_network_sf +
+
Spatial lines dataset representing a route network
+
+ + route_network_small +
+
Spatial lines dataset representing a small route network
+
+ + routes_fast_sf +
+
Spatial lines dataset of commuter flows on the travel network
+
+ + routes_slow_sf +
+
Spatial lines dataset of commuter flows on the travel network
+
+ + zones_sf +
+
Spatial polygons of home locations for flow analysis.
+
+

Example data

+ + + + +
+ + + - -
+ +
+
-
+ - - + + diff --git a/docs/reference/is_linepoint.html b/docs/reference/is_linepoint.html index 67802e7c..a3ba31cc 100644 --- a/docs/reference/is_linepoint.html +++ b/docs/reference/is_linepoint.html @@ -1,266 +1,168 @@ - - - - - - - -Identify lines that are points — is_linepoint • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Identify lines that are points

- Source: R/linefuns.R - +
+

Identify lines that are points

+ Source: R/linefuns.R +
is_linepoint.Rd
-
+

OD matrices often contain 'intrazonal' flows, where the origin is the same point as the destination. This function can help identify such intrazonal OD pairs, using 2 criteria: the total number of vertices (2 or fewer) and whether the origin and destination are the same.

- 
is_linepoint(l)
- -

Arguments

- - - - - - -
l

A spatial lines object

+
+

Usage

+ 
is_linepoint(l)
+
-

Details

+
+

Arguments

+
l
+

A spatial lines object

+
+
+

Details

Returns a boolean vector. TRUE means that the associated line is in fact a point (has no distance). This can be useful for removing data that will not be plotted.

-

See also

- -

Other lines: -angle_diff(), -geo_toptail(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
data(flowlines)
-islp <- is_linepoint(flowlines)
-nrow(flowlines)
-
#> [1] 49
sum(islp)
-
#> [1] 7
# Remove invisible 'linepoints'
-nrow(flowlines[!islp, ])
-
#> [1] 42
-
- -
+
+

Examples

+ 
islp <- is_linepoint(flowlines_sf)
+nrow(flowlines_sf)
+#> [1] 49
+sum(islp)
+#> [1] 7
+# Remove invisible 'linepoints'
+nrow(flowlines_sf[!islp, ])
+#> [1] 42
+
+
+
-
+ - - + + diff --git a/docs/reference/islines.html b/docs/reference/islines.html index 24620ee1..4d965d2c 100644 --- a/docs/reference/islines.html +++ b/docs/reference/islines.html @@ -1,268 +1,154 @@ - - - - - - - -Do the intersections between two geometries create lines? — islines • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Do the intersections between two geometries create lines?

- Source: R/overline.R - +
+

Do the intersections between two geometries create lines?

+ Source: R/overline.R +
islines.Rd
-
-

This is a function required in overline(). It identifies +

+

This is a function required in overline(). It identifies whether sets of lines overlap (beyond shared points) or not.

- 
islines(g1, g2)
+
+

Usage

+ 
islines(g1, g2)
+
-

Arguments

- - - - - - - - - - -
g1

A spatial object

g2

A spatial object

+
+

Arguments

+
g1
+

A spatial object

-

See also

-

Other rnet: -SpatialLinesNetwork, -calc_catchment_sum(), -calc_catchment(), -calc_moving_catchment(), -calc_network_catchment(), -find_network_nodes(), -gsection(), -lineLabels(), -overline_spatial(), -overline(), -plot,SpatialLinesNetwork,ANY-method, -plot,sfNetwork,ANY-method, -rnet_breakup_vertices(), -rnet_group(), -sln2points(), -sum_network_links(), -sum_network_routes()

+
g2
+

A spatial object

-

Examples

- 
if (FALSE) {
-rnet <- overline(routes_fast[c(2, 3, 22), ], attrib = "length")
-plot(rnet)
-lines(routes_fast[22, ], col = "red") # line without overlaps
-islines(routes_fast[2, ], routes_fast[3, ])
-islines(routes_fast[2, ], routes_fast[22, ])
-# sf implementation
-islines(routes_fast_sf[2, ], routes_fast_sf[3, ])
-islines(routes_fast_sf[2, ], routes_fast_sf[22, ])
-}
-
-
- -
+
+
+

See also

+

Other rnet: +gsection(), +overline(), +rnet_breakup_vertices(), +rnet_group()

+
+ +
+

Examples

+ 
if (FALSE) {
+# sf implementation
+islines(routes_fast_sf[2, ], routes_fast_sf[3, ])
+islines(routes_fast_sf[2, ], routes_fast_sf[22, ])
+}
+
+
+
-
+ - - + + diff --git a/docs/reference/line2df.html b/docs/reference/line2df.html index b87da7f8..f9ae64b9 100644 --- a/docs/reference/line2df.html +++ b/docs/reference/line2df.html @@ -1,283 +1,158 @@ - - - - - - - -Convert geographic line objects to a data.frame with from and to coords — line2df • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert geographic line objects to a data.frame with from and to coords

- Source: R/od-funs.R - +
+

Convert geographic line objects to a data.frame with from and to coords

+ Source: R/od-funs.R +
line2df.Rd
-
+

This function returns a data frame with fx and fy and tx and ty variables representing the beginning and end points of spatial line features respectively.

- 
line2df(l)
- -

Arguments

- - - - - - -
l

A spatial lines object

- -

See also

+
+

Usage

+ 
line2df(l)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
l
+

A spatial lines object

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
data(flowlines)
-line2df(flowlines[5, ]) # beginning and end of a single straight line
-
#> # A tibble: 1 x 5
-#>   object    fx    fy    tx    ty
-#>    <dbl> <dbl> <dbl> <dbl> <dbl>
-#> 1      1 -1.52  53.8 -1.52  53.8
line2df(flowlines) # on multiple lines
-
#> # A tibble: 49 x 5
-#>    object    fx    fy    tx    ty
-#>     <dbl> <dbl> <dbl> <dbl> <dbl>
-#>  1      1 -1.52  53.8 -1.52  53.8
-#>  2      2 -1.52  53.8 -1.54  53.8
-#>  3      3 -1.52  53.8 -1.55  53.8
-#>  4      4 -1.52  53.8 -1.53  53.8
-#>  5      5 -1.52  53.8 -1.52  53.8
-#>  6      6 -1.52  53.8 -1.51  53.8
-#>  7      7 -1.52  53.8 -1.52  53.8
-#>  8      8 -1.54  53.8 -1.52  53.8
-#>  9      9 -1.54  53.8 -1.54  53.8
-#> 10     10 -1.54  53.8 -1.55  53.8
-#> # … with 39 more rows
line2df(routes_fast[5:6, ]) # beginning and end of routes
-
#> # A tibble: 2 x 5
-#>   object    fx    fy    tx    ty
-#>    <dbl> <dbl> <dbl> <dbl> <dbl>
-#> 1      1 -1.52  53.8 -1.52  53.8
-#> 2      2 -1.52  53.8 -1.51  53.8
line2df(routes_fast_sf[5:6, ]) # beginning and end of routes
-
#> # A tibble: 2 x 5
-#>      L1    fx    fy    tx    ty
-#>   <dbl> <dbl> <dbl> <dbl> <dbl>
-#> 1     1 -1.52  53.8 -1.52  53.8
-#> 2     2 -1.52  53.8 -1.51  53.8
-
- -
+
+

Examples

+ 
line2df(routes_fast_sf[5:6, ]) # beginning and end of routes
+#> # A tibble: 2 × 5
+#>      L1    fx    fy    tx    ty
+#>   <dbl> <dbl> <dbl> <dbl> <dbl>
+#> 1     1 -1.52  53.8 -1.52  53.8
+#> 2     2 -1.52  53.8 -1.51  53.8
+
+
+
-
+ - - + + diff --git a/docs/reference/line2points-2.png b/docs/reference/line2points-2.png index ed7412d6..8c8b84cd 100644 Binary files a/docs/reference/line2points-2.png and b/docs/reference/line2points-2.png differ diff --git a/docs/reference/line2points.html b/docs/reference/line2points.html index 912df2e3..acc8c712 100644 --- a/docs/reference/line2points.html +++ b/docs/reference/line2points.html @@ -1,157 +1,74 @@ - - - - - - - -Convert a spatial (linestring) object to points — line2points • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert a spatial (linestring) object to points

- Source: R/od-funs.R - +
+

Convert a spatial (linestring) object to points

+ Source: R/od-funs.R +
line2points.Rd
-
+

The number of points will be double the number of lines with line2points. A closely related function, line2pointsn returns all the points that were line vertices. The points corresponding with a given line, i, will be @@ -160,125 +77,113 @@

Convert a spatial (linestring) object to points

1 LINESTRING with 2 POINTS, then it returns an empty sf object.

- 
line2points(l, ids = rep(1:nrow(l)))
-
-line2pointsn(l)
-
-line2vertices(l)
- -

Arguments

- - - - - - - - - - -
l

An sf object or a SpatialLinesDataFrame from the older sp package

ids

Vector of ids (by default 1:nrow(l))

- -

See also

+
+

Usage

+ 
line2points(l, ids = rep(1:nrow(l)))
+
+line2pointsn(l)
+
+line2vertices(l)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
l
+

An sf object or a SpatialLinesDataFrame from the older sp package

+ + +
ids
+

Vector of ids (by default 1:nrow(l))

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
l <- routes_fast_sf[2, ]
-lpoints <- line2points(l)
-plot(l$geometry)
-
plot(lpoints, add = TRUE)
-
# test all vertices:
-plot(l$geometry)
-
lpoints2 <- line2pointsn(l)
-plot(lpoints2$geometry, add = TRUE)
-

-# extract only internal vertices
-l_internal_vertices <- line2vertices(l)
-plot(sf::st_geometry(l), reset = FALSE)
-
plot(l_internal_vertices, add = TRUE)
-
# The boundary points are missing
-
-
- -
+
+

Examples

+ 
l <- routes_fast_sf[2, ]
+lpoints <- line2points(l)
+plot(l$geometry)
+plot(lpoints, add = TRUE)
+
+# test all vertices:
+plot(l$geometry)
+lpoints2 <- line2pointsn(l)
+plot(lpoints2$geometry, add = TRUE)
+
+
+# extract only internal vertices
+l_internal_vertices <- line2vertices(l)
+plot(sf::st_geometry(l), reset = FALSE)
+plot(l_internal_vertices, add = TRUE)
+
+# The boundary points are missing
+
+
+
-
+ - - + + diff --git a/docs/reference/line_bearing.html b/docs/reference/line_bearing.html index d948b8db..5e556f65 100644 --- a/docs/reference/line_bearing.html +++ b/docs/reference/line_bearing.html @@ -1,276 +1,175 @@ - - - - - - - -Find the bearing of straight lines — line_bearing • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Find the bearing of straight lines

- Source: R/linefuns.R - +
+

Find the bearing of straight lines

+ Source: R/linefuns.R +
line_bearing.Rd
-
-

This is a simple wrapper around the geosphere function bearing() to return the +

+

This function returns the bearing (in degrees relative to north) of lines.

- 
line_bearing(l, bidirectional = FALSE)
+
+

Usage

+ 
line_bearing(l, bidirectional = FALSE)
+
+ +
+

Arguments

+
l
+

A spatial lines object

-

Arguments

- - - - - - - - - - -
l

A spatial lines object

bidirectional

Should the result be returned in a bidirectional format? -Default is FALSE. If TRUE, the same line in the oposite direction would have the same bearing

-

Details

+
bidirectional
+

Should the result be returned in a bidirectional format? +Default is FALSE. If TRUE, the same line in the oposite direction would have the same bearing

+
+
+

Details

Returns a boolean vector. TRUE means that the associated line is in fact a point (has no distance). This can be useful for removing data that will not be plotted.

-

See also

- -

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
lib_versions <- sf::sf_extSoftVersion()
-lib_versions
-
#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
-#>        "3.8.0"        "3.0.4"        "7.0.0"         "true"         "true" 
# fails on some systems (with early versions of PROJ)
-if(lib_versions[3] >= "6.3.1") {
-  bearings_sf_1_9 <- line_bearing(flowlines_sf[1:5, ])
-  bearings_sf_1_9 # lines of 0 length have NaN bearing
-  bearings_sp_1_9 <- line_bearing(flowlines[1:5, ])
-  bearings_sp_1_9
-  plot(bearings_sf_1_9, bearings_sp_1_9)
-  line_bearing(flowlines_sf[1:5, ], bidirectional = TRUE)
-  line_bearing(flowlines[1:5, ], bidirectional = TRUE)
-}
-
#> [1]  0.000000 87.950582 77.554344 36.163396  6.668455
-
- -
+
+

Examples

+ 
lib_versions <- sf::sf_extSoftVersion()
+lib_versions
+#>           GEOS           GDAL         proj.4 GDAL_with_GEOS     USE_PROJ_H 
+#>       "3.10.2"        "3.4.1"        "8.2.1"         "true"         "true" 
+#>           PROJ 
+#>        "8.2.1" 
+# fails on some systems (with early versions of PROJ)
+if (lib_versions[3] >= "6.3.1") {
+  bearings_sf_1_9 <- line_bearing(flowlines_sf[1:5, ])
+  bearings_sf_1_9 # lines of 0 length have NaN bearing
+  line_bearing(flowlines_sf[1:5, ], bidirectional = TRUE)
+}
+#> [1]       NaN 87.950582 77.554344 36.163396  6.668455
+
+
+
-
+ - - + + diff --git a/docs/reference/line_midpoint.html b/docs/reference/line_midpoint.html index 1f4be1f0..59516f4d 100644 --- a/docs/reference/line_midpoint.html +++ b/docs/reference/line_midpoint.html @@ -1,263 +1,161 @@ - - - - - - - -Find the mid-point of lines — line_midpoint • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Find the mid-point of lines

- Source: R/linefuns.R - +
+

Find the mid-point of lines

+ Source: R/linefuns.R +
line_midpoint.Rd
-
-

This is a wrapper around SpatialLinesMidPoints() that allows it to find the midpoint -of lines that are not projected, which have a lat/long CRS.

+
+

Find the mid-point of lines

- 
line_midpoint(l)
- -

Arguments

- - - - - - -
l

A spatial lines object

- -

See also

+
+

Usage

+ 
line_midpoint(l, tolerance = NULL)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
l
+

A spatial lines object

+ + +
tolerance
+

The tolerance used to break lines at verteces. +See lwgeom::st_linesubstring().

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
data(routes_fast)
-line_midpoint(routes_fast[2:5, ])
-
#> Transforming to CRS +proj=aeqd +lat_0=53.82475517 +lon_0=-1.52535729 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
#> Warning: CRS object has comment, which is lost in output
#> class       : SpatialPointsDataFrame 
-#> features    : 4 
-#> extent      : -1.533454, -1.514055, 53.82031, 53.82947  (xmin, xmax, ymin, ymax)
-#> crs         : +proj=longlat +datum=WGS84 +no_defs 
-#> variables   : 17
-#> names       : plan, start, finish, length, time, waypoint, cum_hill, change_elev, dif_max_min, up_tot, down_tot,         av_incline, co2_saving, calories, busyness, ... 
-#> min values  :    1,     1,      1,   1535,  313,       37,       87,         -61,          39,     14,       47, 0.0376344086021505,        286,       20,     2259, ... 
-#> max values  :    1,     1,      1,   2976,  829,       97,      112,          -4,          65,     54,       75, 0.0566775244299674,        555,       78,     7062, ...
-
- -
+
+

Examples

+ 
l = routes_fast_sf[2:5, ]
+plot(l$geometry, col = 2:5)
+midpoints = line_midpoint(l)
+#> Warning: st_linesubstring does not follow a geodesic; you may want to use st_geod_segmentize first
+#> Warning: st_linesubstring does not follow a geodesic; you may want to use st_geod_segmentize first
+plot(midpoints, add = TRUE)
+
+
+
+
-
+ - - + + diff --git a/docs/reference/line_segment-1.png b/docs/reference/line_segment-1.png index 830ade47..dd3330a1 100644 Binary files a/docs/reference/line_segment-1.png and b/docs/reference/line_segment-1.png differ diff --git a/docs/reference/line_segment.html b/docs/reference/line_segment.html index 21da2143..49fea7b5 100644 --- a/docs/reference/line_segment.html +++ b/docs/reference/line_segment.html @@ -1,265 +1,165 @@ - - - - - - - -Divide SpatialLines dataset into regular segments — line_segment • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Divide SpatialLines dataset into regular segments

- Source: R/linefuns.R - +
+

Divide sf LINESTRING objects into regular segments

+ Source: R/linefuns.R +
line_segment.Rd
-
-

Divide SpatialLines dataset into regular segments

+
+

Divide sf LINESTRING objects into regular segments

- 
line_segment(l, n_segments, segment_length = NA)
- -

Arguments

- - - - - - - - - - - - - - -
l

A spatial lines object

n_segments

The number of segments to divide the line into

segment_length

The approximate length of segments in the output (overides n_segments if set)

- -

See also

+
+

Usage

+ 
line_segment(l, n_segments, segment_length = NA)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
l
+

A spatial lines object

+ + +
n_segments
+

The number of segments to divide the line into

+ + +
segment_length
+

The approximate length of segments in the output (overides n_segments if set)

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
data(routes_fast)
-l <- routes_fast[2, ]
-library(sp)
-l_seg2 <- line_segment(l = l, n_segments = 2)
-
#> Transforming to CRS +proj=aeqd +lat_0=53.82911343 +lon_0=-1.52653966 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs
#> Warning: CRS object has comment, which is lost in output
plot(l_seg2, col = l_seg2$group, lwd = 50)
-
-
- -
+
+

Examples

+ 
l <- routes_fast_sf[2, ]
+l_seg2 <- line_segment(l = l, n_segments = 2)
+#> Warning: st_linesubstring does not follow a geodesic; you may want to use st_geod_segmentize first
+#> Warning: st_linesubstring does not follow a geodesic; you may want to use st_geod_segmentize first
+#> Warning: st_linesubstring does not follow a geodesic; you may want to use st_geod_segmentize first
+#> Warning: st_linesubstring does not follow a geodesic; you may want to use st_geod_segmentize first
+plot(sf::st_geometry(l_seg2), col = 1:2, lwd = 5)
+
+
+
+
-
+ - - + + diff --git a/docs/reference/line_via.html b/docs/reference/line_via.html index 3224ee56..025208f5 100644 --- a/docs/reference/line_via.html +++ b/docs/reference/line_via.html @@ -1,278 +1,210 @@ - - - - - - - -Add geometry columns representing a route via intermediary points — line_via • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +Add geometry columns representing a route via intermediary points — line_via • stplanr + Skip to contents + - - - - - +
-
-
-

Add geometry columns representing a route via intermediary points

- Source: R/line_via.R - +
+

Add geometry columns representing a route via intermediary points

+ Source: R/line_via.R +
line_via.Rd
-
+

Takes an origin (A) and destination (B), represented by the linestring l, and generates 3 extra geometries based on points p:

- 
line_via(l, p)
+
+

Usage

+ 
line_via(l, p)
+
+ +
+

Arguments

+
l
+

A spatial lines object

-

Arguments

- - - - - - - - - - -
l

A spatial lines object

p

A spatial points object

-

Details

+
p
+

A spatial points object

+
+
+

Details

-
    -

  1. From A to P1 (P1 being the nearest point to A)

    2. +

    1. From A to P1 (P1 being the nearest point to A)

    2. From P1 to P2 (P2 being the nearest point to B)

    3. From P2 to B

      4. -
    - -

    See also

    - -

    Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

    +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
l <- flowlines_sf[2:4, ]
-p <- destinations_sf
-lv <- line_via(l, p)
-# library(mapview)
-# mapview(lv) +
-#    mapview(lv$leg_orig, col = "red")
-library(sf)
-plot(lv[3], lwd = 9, reset = FALSE)
-
plot(lv$leg_orig, col = "red", lwd = 5, add = TRUE)
-
plot(lv$leg_via, col = "black", add = TRUE)
-
plot(lv$leg_dest, col = "green", lwd = 5, add = TRUE)
-
-
- -
+
+

Examples

+ 
library(sf)
+l <- flowlines_sf[2:4, ]
+p <- destinations_sf
+lv <- line_via(l, p)
+lv
+#> Simple feature collection with 3 features and 15 fields
+#> Active geometry column: geometry
+#> Geometry type: LINESTRING
+#> Dimension:     XY
+#> Bounding box:  xmin: -1.550807 ymin: 53.81756 xmax: -1.516734 ymax: 53.82887
+#> Geodetic CRS:  WGS 84
+#>        Area.of.residence Area.of.workplace All Work.mainly.at.or.from.home
+#> 920575         E02002361         E02002363  38                           0
+#> 920578         E02002361         E02002367  10                           0
+#> 920582         E02002361         E02002371  44                           0
+#>        Underground..metro..light.rail..tram Train Bus..minibus.or.coach Taxi
+#> 920575                                    0     1                     4    1
+#> 920578                                    0     0                     1    0
+#> 920582                                    0     0                     2    2
+#>        Motorcycle..scooter.or.moped Driving.a.car.or.van
+#> 920575                            0                   24
+#> 920578                            0                    8
+#> 920582                            0                   28
+#>        Passenger.in.a.car.or.van Bicycle On.foot Other.method.of.travel.to.work
+#> 920575                         4       0       4                              0
+#> 920578                         0       0       1                              0
+#> 920582                         3       3       6                              0
+#>                         id                       geometry
+#> 920575 E02002361 E02002363 LINESTRING (-1.516734 53.82...
+#> 920578 E02002361 E02002367 LINESTRING (-1.516734 53.82...
+#> 920582 E02002361 E02002371 LINESTRING (-1.516734 53.82...
+#>                              leg_orig                        leg_via
+#> 920575 LINESTRING (-1.516734 53.82... LINESTRING (-1.517333 53.82...
+#> 920578 LINESTRING (-1.516734 53.82... LINESTRING (-1.517333 53.82...
+#> 920582 LINESTRING (-1.516734 53.82... LINESTRING (-1.517333 53.82...
+#>                              leg_dest
+#> 920575 LINESTRING (-1.53741 53.829...
+#> 920578 LINESTRING (-1.555112 53.82...
+#> 920582 LINESTRING (-1.534205 53.81...
+# library(mapview)
+# mapview(lv) +
+#    mapview(lv$leg_orig, col = "red")
+plot(lv[3], lwd = 9, reset = FALSE)
+plot(lv$leg_orig, col = "red", lwd = 5, add = TRUE)
+plot(lv$leg_via, col = "black", add = TRUE)
+plot(lv$leg_dest, col = "green", lwd = 5, add = TRUE)
+
+
+
+
-
+ - - + + diff --git a/docs/reference/mats2line.html b/docs/reference/mats2line.html index 907cca5f..b18f6442 100644 --- a/docs/reference/mats2line.html +++ b/docs/reference/mats2line.html @@ -1,264 +1,176 @@ - - - - - - - -Convert 2 matrices to lines — mats2line • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert 2 matrices to lines

- Source: R/line_via.R - +
+

Convert 2 matrices to lines

+ Source: R/line_via.R +
mats2line.Rd
-
+

Convert 2 matrices to lines

- 
mats2line(mat1, mat2)
- -

Arguments

- - - - - - - - - - -
mat1

Matrix representing origins

mat2

Matrix representing destinations

- -

See also

+
+

Usage

+ 
mats2line(mat1, mat2, crs = NA)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
mat1
+

Matrix representing origins

+ + +
mat2
+

Matrix representing destinations

+ + +
crs
+

Number representing the coordinate system of the data, e.g. 4326

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +n_vertices(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
m1 <- matrix(c(1, 2, 1, 2), ncol = 2)
-m2 <- matrix(c(9, 9, 9, 1), ncol = 2)
-l <- mats2line(m1, m2)
-class(l)
-
#> [1] "sfc_LINESTRING" "sfc"           
lsf <- sf::st_sf(l, crs = 4326)
-class(lsf)
-
#> [1] "sf"         "data.frame"
plot(lsf)
-
# mapview::mapview(lsf)
-
-
- -
+
+

Examples

+ 
m1 <- matrix(c(1, 2, 1, 2), ncol = 2)
+m2 <- matrix(c(9, 9, 9, 1), ncol = 2)
+l <- mats2line(m1, m2)
+class(l)
+#> [1] "sfc_LINESTRING" "sfc"           
+l
+#> Geometry set for 2 features 
+#> Geometry type: LINESTRING
+#> Dimension:     XY
+#> Bounding box:  xmin: 1 ymin: 1 xmax: 9 ymax: 9
+#> CRS:           NA
+#> LINESTRING (1 1, 9 9)
+#> LINESTRING (2 2, 9 1)
+lsf <- sf::st_sf(l, crs = 4326)
+class(lsf)
+#> [1] "sf"         "data.frame"
+plot(lsf)
+
+# mapview::mapview(lsf)
+
+
+
-
+ - - + + diff --git a/docs/reference/n_vertices.html b/docs/reference/n_vertices.html index f8535ffd..4290b30d 100644 --- a/docs/reference/n_vertices.html +++ b/docs/reference/n_vertices.html @@ -1,263 +1,156 @@ - - - - - - - -Retrieve the number of vertices from a SpatialLines or SpatialPolygons object — n_vertices • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Retrieve the number of vertices from a SpatialLines or SpatialPolygons object

- Source: R/linefuns.R - +
+

Retrieve the number of vertices in sf objects

+ Source: R/linefuns.R +
n_vertices.Rd
-
-

Returns a vector of the same length as the number of lines, -with the number of vertices per line or polygon.

+
+

Returns a vector of the same length as the number of sf objects.

- 
n_vertices(l)
- -

Arguments

- - - - - - -
l

A SpatialLines or SpatalPolygons object

- -

Details

- -

See https://gis.stackexchange.com/questions/58147/ for more information.

-

See also

+
+

Usage

+ 
n_vertices(l)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -onewaygeo(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
l
+

An sf object with LINESTRING geometry

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +onewaygeo(), +points2line(), +toptail_buff()

+
-

Examples

- 
n_vertices(routes_fast)
-
#>  [1]   2  53  97  37  41  73 104  53   2  44  59  79  97 121  98  65   2  64  84
-#> [20] 114 131  44  59  55   2  22  52  64  46  79  75  22   2  27  65  70  87 105
-#> [39]  52  27   2  46 114 126 130  69  65  46   2
n_vertices(routes_fast_sf)
-
#>  [1]   2  53  97  37  41  73 104  53   2  44  59  79  97 121  98  65   2  64  84
-#> [20] 114 131  44  59  55   2  22  52  64  46  79  75  22   2  27  65  70  87 105
-#> [39]  52  27   2  46 114 126 130  69  65  46   2
-
- -
+
+

Examples

+ 
l = routes_fast_sf
+n_vertices(l)
+#>  [1]   2  53  97  37  41  73 104  53   2  44  59  79  97 121  98  65   2  64  84
+#> [20] 114 131  44  59  55   2  22  52  64  46  79  75  22   2  27  65  70  87 105
+#> [39]  52  27   2  46 114 126 130  69  65  46   2
+n_vertices(zones_sf)
+#> [1] 6 8 8 9 7 6 8 7
+
+
+
-
+ - - + + diff --git a/docs/reference/od2line-1.png b/docs/reference/od2line-1.png index ce47f4d0..294592f5 100644 Binary files a/docs/reference/od2line-1.png and b/docs/reference/od2line-1.png differ diff --git a/docs/reference/od2line.html b/docs/reference/od2line.html index 5bdcef62..6e7a37be 100644 --- a/docs/reference/od2line.html +++ b/docs/reference/od2line.html @@ -1,360 +1,222 @@ - - - - - - - -Convert origin-destination data to spatial lines — od2line • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert origin-destination data to spatial lines

- Source: R/od-funs.R - +
+

Convert origin-destination data to spatial lines

+ Source: R/od-funs.R +
od2line.Rd
-
+

Origin-destination ('OD') flow data is often provided in the form of 1 line per flow with zone codes of origin and destination centroids. This can be tricky to plot and link-up with geographical data. This function makes the task easier.

- 
od2line(
-  flow,
-  zones,
-  destinations = NULL,
-  zone_code = names(zones)[1],
-  origin_code = names(flow)[1],
-  dest_code = names(flow)[2],
-  zone_code_d = NA,
-  silent = FALSE
-)
-
-od2line2(flow, zones)
- -

Arguments

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
flow

A data frame representing origin-destination data. +

+

Usage

+ 
od2line(
+  flow,
+  zones,
+  destinations = NULL,
+  zone_code = names(zones)[1],
+  origin_code = names(flow)[1],
+  dest_code = names(flow)[2],
+  zone_code_d = NA,
+  silent = FALSE
+)
+
+ +
+

Arguments

+
flow
+

A data frame representing origin-destination data. The first two columns of this data frame should correspond -to the first column of the data in the zones. Thus in cents(), +to the first column of the data in the zones. Thus in cents_sf(), the first column is geo_code. This corresponds to the first two columns -of flow().

zones

A spatial object representing origins (and destinations -if no separate destinations object is provided) of travel.

destinations

A spatial object -representing destinations of travel flows.

zone_code

Name of the variable in zones containing the ids of the zone. -By default this is the first column names in the zones.

origin_code

Name of the variable in flow containing the ids of the zone of origin. -By default this is the first column name in the flow input dataset.

dest_code

Name of the variable in flow containing the ids of the zone of destination. +of flow().

+ + +
zones
+

A spatial object representing origins (and destinations +if no separate destinations object is provided) of travel.

+ + +
destinations
+

A spatial object +representing destinations of travel flows.

+ + +
zone_code
+

Name of the variable in zones containing the ids of the zone. +By default this is the first column names in the zones.

+ + +
origin_code
+

Name of the variable in flow containing the ids of the zone of origin. +By default this is the first column name in the flow input dataset.

+ + +
dest_code
+

Name of the variable in flow containing the ids of the zone of destination. By default this is the second column name in the flow input dataset or the first column name in the -destinations if that is set.

zone_code_d

Name of the variable in destinations containing the ids of the zone. -By default this is the first column names in the destinations.

silent

TRUE by default, setting it to TRUE will show you the matching columns

- -

Details

+destinations if that is set.

+ +
zone_code_d
+

Name of the variable in destinations containing the ids of the zone. +By default this is the first column names in the destinations.

+ + +
silent
+

TRUE by default, setting it to TRUE will show you the matching columns

+ +
+
+

Details

Origin-destination (OD) data is often provided in the form of 1 line per OD pair, with zone codes of the trip origin in the first column and the zone codes of the destination in the second column -(see the vignette("stplanr-od")) for details. +(see the vignette("stplanr-od")) for details. od2line() creates a spatial (linestring) object representing movement from the origin to the destination for each OD pair. It takes data frame containing origin and destination cones (flow) that match the first column in a a spatial (polygon or point) object (zones).

-

See also

- -

Other od: -dist_google(), -od2odf(), -od_aggregate_from(), -od_aggregate_to(), -od_coords2line(), -od_coords(), -od_dist(), -od_id, -od_oneway(), -od_to_odmatrix(), -odmatrix_to_od(), -points2flow(), -points2odf()

- -

Examples

- 
od_data <- stplanr::flow[1:20, ]
-l <- od2line(flow = od_data, zones = cents_sf)
-plot(sf::st_geometry(cents_sf))
-
plot(l, lwd = l$All / mean(l$All), add = TRUE)
-
#> Warning: ignoring all but the first attribute
l <- od2line(flow = od_data, zones = cents)
-
#> Warning: CRS object has comment, which is lost in output
#> Warning: Discarded datum Unknown based on WGS84 ellipsoid in CRS definition
# When destinations are different
-head(destinations[1:5])
-
#> class       : SpatialPointsDataFrame 
-#> features    : 6 
-#> extent      : -1.540901, -1.492713, 53.80131, 53.81724  (xmin, xmax, ymin, ymax)
-#> crs         : +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs 
-#> variables   : 5
-#> names       :    WZ11CD,   LAD11CD, COWZEW_SG,                     COWZEW_SGN, COWZEW_G 
-#> min values  : E33010351, E08000035,         2, Manufacturing and distribution,       2c 
-#> max values  : E33012352, E08000035,         7,                       Top jobs,       7c 
od_data2 <- flow_dests[1:12, 1:3]
-od_data2
-
#>        Area.of.residence    WZ11CD All
-#> 920573         E02002361 E33010350 109
-#> 920575         E02002361 E33010390  38
-#> 920578         E02002361 E33010468  10
-#> 920582         E02002361 E33012367  44
-#> 920587         E02002361 E33012225  34
-#> 920591         E02002361 E33012368   7
-#> 920601         E02002361 E33012333  94
-#> 921220         E02002363 E33012414  30
-#> 921222         E02002363 E33012313 183
-#> 921225         E02002363 E33010464  11
-#> 921228         E02002363 E33012254  72
-#> 921233         E02002363 E33012352  13
flowlines_dests <- od2line(od_data2, cents_sf, destinations = destinations_sf)
-flowlines_dests
-
#> Simple feature collection with 12 features and 3 fields
-#> geometry type:  LINESTRING
-#> dimension:      XY
-#> bbox:           xmin: -1.563202 ymin: 53.79647 xmax: -1.492713 ymax: 53.83587
-#> geographic CRS: WGS 84
-#> First 10 features:
-#>    Area.of.residence    WZ11CD All                       geometry
-#> 1          E02002361 E33010350 109 LINESTRING (-1.516734 53.82...
-#> 2          E02002361 E33010390  38 LINESTRING (-1.516734 53.82...
-#> 3          E02002361 E33010468  10 LINESTRING (-1.516734 53.82...
-#> 4          E02002361 E33012367  44 LINESTRING (-1.516734 53.82...
-#> 5          E02002361 E33012225  34 LINESTRING (-1.516734 53.82...
-#> 6          E02002361 E33012368   7 LINESTRING (-1.516734 53.82...
-#> 7          E02002361 E33012333  94 LINESTRING (-1.516734 53.82...
-#> 8          E02002363 E33012414  30 LINESTRING (-1.535617 53.82...
-#> 9          E02002363 E33012313 183 LINESTRING (-1.535617 53.82...
-#> 10         E02002363 E33010464  11 LINESTRING (-1.535617 53.82...
plot(flowlines_dests)
-
-
- -
+
+
+

See also

+

Other od: +od2odf(), +od_aggregate_from(), +od_aggregate_to(), +od_coords2line(), +od_coords(), +od_id_order(), +od_id, +od_oneway(), +od_to_odmatrix(), +odmatrix_to_od(), +points2flow(), +points2odf()

+
+ +
+

Examples

+ 
od_data <- stplanr::flow[1:20, ]
+l <- od2line(flow = od_data, zones = cents_sf)
+plot(sf::st_geometry(cents_sf))
+plot(l, lwd = l$All / mean(l$All), add = TRUE)
+#> Warning: ignoring all but the first attribute
+
+
+
+
-
+ - - + + diff --git a/docs/reference/od2odf.html b/docs/reference/od2odf.html index 797417b4..02831426 100644 --- a/docs/reference/od2odf.html +++ b/docs/reference/od2odf.html @@ -1,270 +1,172 @@ - - - - - - - -Extract coordinates from OD data — od2odf • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Extract coordinates from OD data

- Source: R/od-funs.R - +
+

Extract coordinates from OD data

+ Source: R/od-funs.R +
od2odf.Rd
-
+

Extract coordinates from OD data

- 
od2odf(flow, zones)
+
+

Usage

+ 
od2odf(flow, zones)
+
-

Arguments

- - - - - - - - - - -
flow

A data frame representing origin-destination data. +

+

Arguments

+
flow
+

A data frame representing origin-destination data. The first two columns of this data frame should correspond -to the first column of the data in the zones. Thus in cents(), +to the first column of the data in the zones. Thus in cents_sf(), the first column is geo_code. This corresponds to the first two columns -of flow().

zones

A spatial object representing origins (and destinations -if no separate destinations object is provided) of travel.

+of flow().

+ -

Details

+
zones
+

A spatial object representing origins (and destinations +if no separate destinations object is provided) of travel.

+
+
+

Details

Origin-destination (OD) data is often provided in the form of 1 line per OD pair, with zone codes of the trip origin in the first column and the zone codes of the destination in the second column -(see the vignette("stplanr-od")) for details. -od2odf() creates an 'origin-destination data frame', based on a data frame containing -origin and destination cones (flow) that match the first column in a -a spatial (polygon or point) object (zones).

+(see the vignette("stplanr-od")) for details. +od2odf() creates an 'origin-destination data frame', with columns containing +origin and destination codes (flow) that match the first column in a +a spatial (polygon or point sf) object (zones).

The function returns a data frame with coordinates for the origin and destination.

-

See also

- -

Other od: -dist_google(), -od2line(), -od_aggregate_from(), -od_aggregate_to(), -od_coords2line(), -od_coords(), -od_dist(), -od_id, -od_oneway(), -od_to_odmatrix(), -odmatrix_to_od(), -points2flow(), -points2odf()

+
+
+

See also

+

Other od: +od2line(), +od_aggregate_from(), +od_aggregate_to(), +od_coords2line(), +od_coords(), +od_id_order(), +od_id, +od_oneway(), +od_to_odmatrix(), +odmatrix_to_od(), +points2flow(), +points2odf()

+
-

Examples

- 
data(flow)
-data(zones)
-od2odf(flow[1:2, ], zones)
-
#>      code_o    code_d      fx.x     fy.x      fx.y     fy.y
-#> 1 E02002361 E02002361 -1.514962 53.82911 -1.514962 53.82911
-#> 2 E02002361 E02002363 -1.514962 53.82911 -1.535735 53.82863
-
- -
+
+

Examples

+ 
od2odf(flow[1:2, ], zones_sf)
+#> Converting geometry ID from factor to character
+#>             o         d        ox       oy        dx       dy
+#> 1   E02002361 E02002361 -1.514962 53.82911 -1.514962 53.82911
+#> 1.1 E02002361 E02002363 -1.514962 53.82911 -1.535734 53.82863
+
+
+
-
+ - - + + diff --git a/docs/reference/od_coords.html b/docs/reference/od_coords.html index d2923b43..cc0b0908 100644 --- a/docs/reference/od_coords.html +++ b/docs/reference/od_coords.html @@ -1,275 +1,174 @@ - - - - - - - -Create matrices representing origin-destination coordinates — od_coords • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Create matrices representing origin-destination coordinates

- Source: R/od-funs.R - +
+

Create matrices representing origin-destination coordinates

+ Source: R/od-funs.R +
od_coords.Rd
-
+

This function takes a wide range of input data types (spatial lines, points or text strings) and returns a matrix of coordinates representing origin (fx, fy) and destination (tx, ty) points.

- 
od_coords(from = NULL, to = NULL, l = NULL)
- -

Arguments

- - - - - - - - - - - - - - -
from

An object representing origins -(if lines are provided as the first argument, from is assigned to l)

to

An object representing destinations

l

Only needed if from and to are empty, in which case this -should be a spatial object representing desire lines

- -

See also

+
+

Usage

+ 
od_coords(from = NULL, to = NULL, l = NULL)
+
-

Other od: -dist_google(), -od2line(), -od2odf(), -od_aggregate_from(), -od_aggregate_to(), -od_coords2line(), -od_dist(), -od_id, -od_oneway(), -od_to_odmatrix(), -odmatrix_to_od(), -points2flow(), -points2odf()

+
+

Arguments

+
from
+

An object representing origins +(if lines are provided as the first argument, from is assigned to l)

+ + +
to
+

An object representing destinations

+ + +
l
+

Only needed if from and to are empty, in which case this +should be a spatial object representing desire lines

+ +
+
+

See also

+

Other od: +od2line(), +od2odf(), +od_aggregate_from(), +od_aggregate_to(), +od_coords2line(), +od_id_order(), +od_id, +od_oneway(), +od_to_odmatrix(), +odmatrix_to_od(), +points2flow(), +points2odf()

+
-

Examples

- 
od_coords(from = c(0, 52), to = c(1, 53)) # lon/lat coordinates
-
#>      fx fy tx ty
-#> [1,]  0 52  1 53
od_coords(from = cents[1, ], to = cents[2, ]) # Spatial points
-
#>             fx       fy        tx       ty
-#> [1,] -1.546463 53.80952 -1.511861 53.81161
od_coords(cents_sf[1:3, ], cents_sf[2:4, ]) # sf points
-
#>          fx       fy        tx       ty
-#> 1 -1.546463 53.80952 -1.511861 53.81161
-#> 2 -1.511861 53.81161 -1.524205 53.80410
-#> 3 -1.524205 53.80410 -1.550806 53.82442
# od_coords("Hereford", "Leeds") # geocode locations
-od_coords(flowlines[1:3, ])
-
#>             fx       fy        tx       ty
-#> [1,] -1.516734 53.82887 -1.516734 53.82887
-#> [2,] -1.516734 53.82887 -1.535617 53.82847
-#> [3,] -1.516734 53.82887 -1.550807 53.82442
od_coords(flowlines_sf[1:3, ])
-
#>             fx       fy        tx       ty
-#> [1,] -1.516734 53.82887 -1.516734 53.82887
-#> [2,] -1.516734 53.82887 -1.535617 53.82847
-#> [3,] -1.516734 53.82887 -1.550807 53.82442
-
- -
+
+

Examples

+ 
od_coords(from = c(0, 52), to = c(1, 53)) # lon/lat coordinates
+#>      fx fy tx ty
+#> [1,]  0 52  1 53
+od_coords(cents_sf[1:3, ], cents_sf[2:4, ]) # sf points
+#>          fx       fy        tx       ty
+#> 1 -1.546463 53.80952 -1.511861 53.81161
+#> 2 -1.511861 53.81161 -1.524205 53.80410
+#> 3 -1.524205 53.80410 -1.550806 53.82442
+# od_coords("Hereford", "Leeds") # geocode locations
+od_coords(flowlines_sf[1:3, ])
+#>             fx       fy        tx       ty
+#> [1,] -1.516734 53.82887 -1.516734 53.82887
+#> [2,] -1.516734 53.82887 -1.535617 53.82847
+#> [3,] -1.516734 53.82887 -1.550807 53.82442
+
+
+
-
+ - - + + diff --git a/docs/reference/od_id_order.html b/docs/reference/od_id_order.html index a7bd7402..e81095c0 100644 --- a/docs/reference/od_id_order.html +++ b/docs/reference/od_id_order.html @@ -1,254 +1,173 @@ - - - - - - - -Generate ordered ids of OD pairs so lowest is always first -This function is slow on large datasets, see szudzik_pairing for faster alternative — od_id_order • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Generate ordered ids of OD pairs so lowest is always first +
+

Generate ordered ids of OD pairs so lowest is always first This function is slow on large datasets, see szudzik_pairing for faster alternative

- Source: R/oneway.R - + Source: R/oneway.R +
od_id_order.Rd
-
+

Generate ordered ids of OD pairs so lowest is always first This function is slow on large datasets, see szudzik_pairing for faster alternative

- 
od_id_order(x, id1 = names(x)[1], id2 = names(x)[2])
+
+

Usage

+ 
od_id_order(x, id1 = names(x)[1], id2 = names(x)[2])
+
-

Arguments

- - - - - - - - - - - - - - -
x

A data frame or SpatialLinesDataFrame, representing an OD matrix

id1

Optional (it is assumed to be the first column) -text string referring to the name of the variable containing -the unique id of the origin

id2

Optional (it is assumed to be the second column) +

+

Arguments

+
x
+

A data frame or SpatialLinesDataFrame, representing an OD matrix

+ + +
id1
+

Optional (it is assumed to be the first column) text string referring to the name of the variable containing -the unique id of the destination

+the unique id of the origin

-

Examples

- 
x <- data.frame(id1 = c(1, 1, 2, 2, 3), id2 = c(1, 2, 3, 1, 4))
-od_id_order(x) # 4th line switches id1 and id2 so stplanr.key is in order
-
#>   stplanr.id1 stplanr.id1.1 stplanr.key
-#> 1           1             1         1 1
-#> 2           1             2         1 2
-#> 3           2             3         2 3
-#> 4           2             1         1 2
-#> 5           3             4         3 4
-
- -

+
id2
+

Optional (it is assumed to be the second column) +text string referring to the name of the variable containing +the unique id of the destination

+ +
+
+

See also

+

Other od: +od2line(), +od2odf(), +od_aggregate_from(), +od_aggregate_to(), +od_coords2line(), +od_coords(), +od_id, +od_oneway(), +od_to_odmatrix(), +odmatrix_to_od(), +points2flow(), +points2odf()

+
+ +
+

Examples

+ 
x <- data.frame(id1 = c(1, 1, 2, 2, 3), id2 = c(1, 2, 3, 1, 4))
+od_id_order(x) # 4th line switches id1 and id2 so stplanr.key is in order
+#>   stplanr.id1 stplanr.id1.1 stplanr.key
+#> 1           1             1         1 1
+#> 2           1             2         1 2
+#> 3           2             3         2 3
+#> 4           2             1         1 2
+#> 5           3             4         3 4
+
+
+
-
+ - - + + diff --git a/docs/reference/onewaygeo.html b/docs/reference/onewaygeo.html index 140a127f..89d98124 100644 --- a/docs/reference/onewaygeo.html +++ b/docs/reference/onewaygeo.html @@ -1,296 +1,179 @@ - - - - - - - -Aggregate flows so they become non-directional (by geometry - the slow way) — onewaygeo • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ + +
-
-
-

Aggregate flows so they become non-directional (by geometry - the slow way)

- Source: R/overline.R - +
+

Aggregate flows so they become non-directional (by geometry - the slow way)

+ Source: R/overline.R +
onewaygeo.Rd
-
+

Flow data often contains movement in two directions: from point A to point B and then from B to A. This can be problematic for transport planning, because the magnitude of flow along a route can be masked by flows the other direction. If only the largest flow in either direction is captured in an analysis, for example, the true extent of travel will by heavily under-estimated for -OD pairs which have similar amounts of travel in both directions. -Flows in both direction are often represented by overlapping lines with -identical geometries (see flowlines()) which can be confusing -for users and are difficult to plot.

+OD pairs which have similar amounts of travel in both directions.

- 
onewaygeo(x, attrib)
+
+

Usage

+ 
onewaygeo(x, attrib)
+
-

Arguments

- - - - - - - - - - -
x

A dataset containing linestring geometries

attrib

A text string containing the name of the line's attribute to -aggregate or a numeric vector of the columns to be aggregated

+
+

Arguments

+
x
+

A dataset containing linestring geometries

-

Value

-

onewaygeo outputs a SpatialLinesDataFrame with single lines +

attrib
+

A text string containing the name of the line's attribute to +aggregate or a numeric vector of the columns to be aggregated

+ +
+
+

Value

+ + +

onewaygeo outputs a SpatialLinesDataFrame with single lines and user-selected attribute values that have been aggregated. Only lines with a distance (i.e. not intra-zone flows) are included

-

Details

- +
+
+

Details

This function aggregates directional flows into non-directional flows, potentially halving the number of lines objects and reducing the number of overlapping lines to zero.

-

See also

- -

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -points2line(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +points2line(), +toptail_buff()

+
-

Examples

- 
plot(flowlines[1:30, ], lwd = flowlines$On.foot[1:30])
-
singlines <- onewaygeo(flowlines[1:30, ], attrib = which(names(flowlines) == "On.foot"))
-plot(singlines, lwd = singlines$On.foot / 2, col = "red", add = TRUE)
-
if (FALSE) {
-plot(flowlines, lwd = flowlines$All / 10)
-singlelines <- onewaygeo(flowlines, attrib = 3:14)
-plot(singlelines, lwd = singlelines$All / 20, col = "red", add = TRUE)
-sum(singlelines$All) == sum(flowlines$All)
-nrow(singlelines)
-singlelines_sf <- onewaygeo(flowlines_sf, attrib = 3:14)
-sum(singlelines_sf$All) == sum(flowlines_sf$All)
-summary(singlelines$All == singlelines_sf$All)
-}
-
-
- -
+
-
+ - - + + diff --git a/docs/reference/overline-1.png b/docs/reference/overline-1.png index dab43551..22ff802e 100644 Binary files a/docs/reference/overline-1.png and b/docs/reference/overline-1.png differ diff --git a/docs/reference/overline-2.png b/docs/reference/overline-2.png index 2d03135f..616e0733 100644 Binary files a/docs/reference/overline-2.png and b/docs/reference/overline-2.png differ diff --git a/docs/reference/overline.html b/docs/reference/overline.html index 4fe5f5d0..f7afffee 100644 --- a/docs/reference/overline.html +++ b/docs/reference/overline.html @@ -1,239 +1,154 @@ - - - - - - - -Convert series of overlapping lines into a route network — overline • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert series of overlapping lines into a route network

- Source: R/overline.R - +
+

Convert series of overlapping lines into a route network

+ Source: R/overline.R +
overline.Rd
-
+

This function takes a series of overlapping lines and converts them into a single route network.

This function is intended as a replacement for overline() and is significantly faster especially on large datasets. However, it also uses more memory.

- 
overline(
-  sl,
-  attrib,
-  ncores = 1,
-  simplify = TRUE,
-  regionalise = 1e+05,
-  quiet = ifelse(nrow(sl) < 1000, TRUE, FALSE),
-  fun = sum
-)
-
-overline2(
-  sl,
-  attrib,
-  ncores = 1,
-  simplify = TRUE,
-  regionalise = 1e+05,
-  quiet = ifelse(nrow(sl) < 1000, TRUE, FALSE),
-  fun = sum
-)
- -

Arguments

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
sl

A spatial object representing routes on a transport network

attrib

character, column names in sl to be aggregated

ncores

integer, how many cores to use in parallel processing, default = 1

simplify

logical, if TRUE group final segments back into lines, default = TRUE

regionalise

integer, during simplification regonalisation is used if the number of segments exceeds this value

quiet

Should the the function omit messages? NULL by default, -which means the output will only be shown if sl has more than 1000 rows.

fun

Named list of functions to summaries the attributes by? sum is the default. -list(sum = sum, average = mean) will summarise all attributes by sum and mean.

- -

Value

- -

An sf object representing a route network

-

Details

+
+

Usage

+ 
overline(
+  sl,
+  attrib,
+  ncores = 1,
+  simplify = TRUE,
+  regionalise = 1e+09,
+  quiet = ifelse(nrow(sl) < 1000, TRUE, FALSE),
+  fun = sum
+)
+
+overline2(
+  sl,
+  attrib,
+  ncores = 1,
+  simplify = TRUE,
+  regionalise = 1e+09,
+  quiet = ifelse(nrow(sl) < 1000, TRUE, FALSE),
+  fun = sum
+)
+
+ +
+

Arguments

+
sl
+

A spatial object representing routes on a transport network

+ + +
attrib
+

character, column names in sl to be aggregated

+ + +
ncores
+

integer, how many cores to use in parallel processing, default = 1

+ + +
simplify
+

logical, if TRUE group final segments back into lines, default = TRUE

+ +
regionalise
+

integer, during simplification regonalisation is used if the number of segments exceeds this value

+ + +
quiet
+

Should the the function omit messages? NULL by default, +which means the output will only be shown if sl has more than 1000 rows.

+ + +
fun
+

Named list of functions to summaries the attributes by? sum is the default. +list(sum = sum, average = mean) will summarise all attributes by sum and mean.

+ +
+
+

Value

+ + +

An sf object representing a route network

+
+
+

Details

The function can be used to estimate the amount of transport 'flow' at the route segment level based on input datasets from routing services, for -example linestring geometries created with the route() function.

+example linestring geometries created with the route() function.

The overline() function breaks each line into many straight segments and then looks for duplicated segments. Attributes are summed for all duplicated segments, and if simplify is TRUE the segments with identical attributes are recombined into linestrings.

-

The following arguments only apply to the sf implementation of overline():

    -

  • ncores, the number of cores to use in parallel processing

    • +

    The following arguments only apply to the sf implementation of overline():

    • ncores, the number of cores to use in parallel processing

    • simplify, should the final segments be converted back into longer lines? The default setting is TRUE. simplify = FALSE results in straight line segments consisting of only 2 vertices (the start and end point), resulting in a data frame with many more rows than the simplified results (see examples).

    • regionalise the threshold number of rows above which regionalisation is used (see details).

      • -
    - -

    For sf objects Regionalisation breaks the dataset into a 10 x 10 grid and +

For sf objects Regionalisation breaks the dataset into a 10 x 10 grid and then performed the simplification across each grid. This significantly reduces computation time for large datasets, but slightly increases the final file size. For smaller datasets it increases computation time slightly but @@ -247,142 +162,112 @@

Details results together, and then overline again, to produce a final result.

Multicore support is only enabled for the regionalised simplification stage as it does not help with other stages.

-

References

- +
+
+

References

Morgan M and Lovelace R (2020). Travel flow aggregation: Nationally scalable methods for interactive and online visualisation of transport behaviour at the road network level. Environment and Planning B: Urban Analytics and City Science. July 2020. -doi:10.1177/2399808320942779

+doi:10.1177/2399808320942779 +.

Rowlingson, B (2015). Overlaying lines and aggregating their values for overlapping -segments. Reproducible question from https://gis.stackexchange.com. See -https://gis.stackexchange.com/questions/139681/.

-

See also

- -

Other rnet: -SpatialLinesNetwork, -calc_catchment_sum(), -calc_catchment(), -calc_moving_catchment(), -calc_network_catchment(), -find_network_nodes(), -gsection(), -islines(), -lineLabels(), -overline_spatial(), -plot,SpatialLinesNetwork,ANY-method, -plot,sfNetwork,ANY-method, -rnet_breakup_vertices(), -rnet_group(), -sln2points(), -sum_network_links(), -sum_network_routes()

+segments. Reproducible question from https://gis.stackexchange.com. See +https://gis.stackexchange.com/questions/139681/.

+
+
+

See also

+

Other rnet: +gsection(), +islines(), +rnet_breakup_vertices(), +rnet_group()

Other rnet: -SpatialLinesNetwork, -calc_catchment_sum(), -calc_catchment(), -calc_moving_catchment(), -calc_network_catchment(), -find_network_nodes(), -gsection(), -islines(), -lineLabels(), -overline_spatial(), -plot,SpatialLinesNetwork,ANY-method, -plot,sfNetwork,ANY-method, -rnet_breakup_vertices(), -rnet_group(), -sln2points(), -sum_network_links(), -sum_network_routes()

-

Author

- +gsection(), +islines(), +rnet_breakup_vertices(), +rnet_group()

+
+
+

Author

Barry Rowlingson

Malcolm Morgan

+
-

Examples

- 
sl <- routes_fast_sf[2:4, ]
-sl$All <- flowlines$All[2:4]
-rnet <- overline(sl = sl, attrib = "All")
-nrow(sl)
-
#> [1] 3
nrow(rnet)
-
#> [1] 4
plot(rnet)
-
rnet_mean <- overline(sl, c("All", "av_incline"), fun = list(mean = mean, sum = sum))
-plot(rnet_mean, lwd = rnet_mean$All_sum / mean(rnet_mean$All_sum))
-
rnet_sf_raw <- overline(sl, attrib = "length", simplify = FALSE)
-nrow(rnet_sf_raw)
-
#> [1] 151
summary(n_vertices(rnet_sf_raw))
-
#>    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
-#>       2       2       2       2       2       2 
plot(rnet_sf_raw)
-
rnet_sf_raw$n = 1:nrow(rnet_sf_raw)
-plot(rnet_sf_raw[10:25, ])
-
# legacy implementation based on sp data
-# sl <- routes_fast[2:4, ]
-# rnet1 <- overline(sl = sl, attrib = "length")
-# rnet2 <- overline(sl = sl, attrib = "length", buff_dist = 1)
-# plot(rnet1, lwd = rnet1$length / mean(rnet1$length))
-# plot(rnet2, lwd = rnet2$length / mean(rnet2$length))
-
-
- -
+
+

Examples

+ 
sl <- routes_fast_sf[2:4, ]
+sl$All <- flowlines_sf$All[2:4]
+rnet <- overline(sl = sl, attrib = "All")
+nrow(sl)
+#> [1] 3
+nrow(rnet)
+#> [1] 4
+plot(rnet)
+
+rnet_mean <- overline(sl, c("All", "av_incline"), fun = list(mean = mean, sum = sum))
+plot(rnet_mean, lwd = rnet_mean$All_sum / mean(rnet_mean$All_sum))
+
+rnet_sf_raw <- overline(sl, attrib = "length", simplify = FALSE)
+nrow(rnet_sf_raw)
+#> [1] 151
+summary(n_vertices(rnet_sf_raw))
+#>    Min. 1st Qu.  Median    Mean 3rd Qu.    Max. 
+#>       2       2       2       2       2       2 
+plot(rnet_sf_raw)
+
+rnet_sf_raw$n <- 1:nrow(rnet_sf_raw)
+plot(rnet_sf_raw[10:25, ])
+
+
+
+
-
+ - - + + diff --git a/docs/reference/pipe.html b/docs/reference/pipe.html index 2fd7cedb..1c493f3c 100644 --- a/docs/reference/pipe.html +++ b/docs/reference/pipe.html @@ -1,220 +1,120 @@ - - - - - - - -Pipe operator — %>% • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Pipe operator

- Source: R/utils-pipe.R - +
+

Pipe operator

+ Source: R/utils-pipe.R +
pipe.Rd
-
+

See ?magrittr for details.

- 
lhs %>% rhs
- +
+

Usage

+ 
lhs %>% rhs
+
-
- -
+
-
+ - - + + diff --git a/docs/reference/points2flow-1.png b/docs/reference/points2flow-1.png index 0dbf5198..c3617ba3 100644 Binary files a/docs/reference/points2flow-1.png and b/docs/reference/points2flow-1.png differ diff --git a/docs/reference/points2flow.html b/docs/reference/points2flow.html index 90cc8235..5bcf7cd5 100644 --- a/docs/reference/points2flow.html +++ b/docs/reference/points2flow.html @@ -1,256 +1,156 @@ - - - - - - - -Convert a series of points into geographical flows — points2flow • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert a series of points into geographical flows

- Source: R/od-funs.R - +
+

Convert a series of points into geographical flows

+ Source: R/od-funs.R +
points2flow.Rd
-
+

Takes a series of geographical points and converts them into a spatial (linestring) object representing the potential flows, or 'spatial interaction', between every combination of points.

- 
points2flow(p)
- -

Arguments

- - - - - - -
p

A spatial (point) object

- -

See also

+
+

Usage

+ 
points2flow(p)
+
-

Other od: -dist_google(), -od2line(), -od2odf(), -od_aggregate_from(), -od_aggregate_to(), -od_coords2line(), -od_coords(), -od_dist(), -od_id, -od_oneway(), -od_to_odmatrix(), -odmatrix_to_od(), -points2odf()

+
+

Arguments

+
p
+

A spatial (point) object

+ +
+
+

See also

+

Other od: +od2line(), +od2odf(), +od_aggregate_from(), +od_aggregate_to(), +od_coords2line(), +od_coords(), +od_id_order(), +od_id, +od_oneway(), +od_to_odmatrix(), +odmatrix_to_od(), +points2odf()

+
-

Examples

- 
data(cents)
-plot(cents)
-
flow <- points2flow(cents)
-
#> Warning: CRS object has comment, which is lost in output
#> Warning: Discarded datum Unknown based on WGS84 ellipsoid in CRS definition
plot(flow, add = TRUE)
-
flow_sf <- points2flow(cents_sf)
-plot(flow_sf)
-
-
- -
+
+

Examples

+ 
flow_sf <- points2flow(cents_sf[1:4, ])
+plot(flow_sf)
+
+
+
+
-
+ - - + + diff --git a/docs/reference/points2line-1.png b/docs/reference/points2line-1.png index 7b84148c..02bfd11f 100644 Binary files a/docs/reference/points2line-1.png and b/docs/reference/points2line-1.png differ diff --git a/docs/reference/points2line.html b/docs/reference/points2line.html index 443c190c..8ef892d7 100644 --- a/docs/reference/points2line.html +++ b/docs/reference/points2line.html @@ -1,265 +1,155 @@ - - - - - - - -Convert a series of points, or a matrix of coordinates, into a line — points2line • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert a series of points, or a matrix of coordinates, into a line

- Source: R/od-funs.R - +
+

Convert a series of points, or a matrix of coordinates, into a line

+ Source: R/od-funs.R +
points2line.Rd
-
-

This is a simple wrapper around spLines() that makes the creation of -SpatialLines objects easy and intuitive

+
+

This function makes that makes the creation of sf +objects with LINESTRING geometries easy.

- 
points2line(p)
- -

Arguments

- - - - - - -
p

A spatial (points) obect or matrix representing the coordinates of points.

- -

See also

+
+

Usage

+ 
points2line(p)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -toptail_buff(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
p
+

A spatial (points) obect or matrix representing the coordinates of points.

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +toptail_buff()

+
-

Examples

- 
p <- matrix(1:4, ncol = 2)
-library(sp)
-l <- points2line(p)
-plot(l)
-
l <- points2line(cents)
-
#> Warning: CRS object has comment, which is lost in output
#> Warning: Discarded datum Unknown based on WGS84 ellipsoid in CRS definition
plot(l)
-
p <- line2points(routes_fast)
-
#> Warning: CRS object has comment, which is lost in output
#> Warning: Discarded datum Unknown based on WGS84 ellipsoid in CRS definition
l <- points2line(p)
-
#> Warning: CRS object has comment, which is lost in output
#> Warning: Discarded datum Unknown based on WGS84 ellipsoid in CRS definition
plot(l)
-
l_sf <- points2line(cents_sf)
-plot(l_sf)
-
-
- -
+
+

Examples

+ 
l_sf <- points2line(cents_sf)
+plot(l_sf)
+
+
+
+
-
+ - - + + diff --git a/docs/reference/points2odf.html b/docs/reference/points2odf.html index d09888f6..123bf013 100644 --- a/docs/reference/points2odf.html +++ b/docs/reference/points2odf.html @@ -1,255 +1,219 @@ - - - - - - - -Convert a series of points into a dataframe of origins and destinations — points2odf • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Convert a series of points into a dataframe of origins and destinations

- Source: R/od-funs.R - +
+

Convert a series of points into a dataframe of origins and destinations

+ Source: R/od-funs.R +
points2odf.Rd
-
+

Takes a series of geographical points and converts them into a data.frame representing the potential flows, or 'spatial interaction', between every combination of points.

- 
points2odf(p)
- -

Arguments

- - - - - - -
p

A spatial points object

- -

See also

+
+

Usage

+ 
points2odf(p)
+
-

Other od: -dist_google(), -od2line(), -od2odf(), -od_aggregate_from(), -od_aggregate_to(), -od_coords2line(), -od_coords(), -od_dist(), -od_id, -od_oneway(), -od_to_odmatrix(), -odmatrix_to_od(), -points2flow()

+
+

Arguments

+
p
+

A spatial points object

+ +
+
+

See also

+

Other od: +od2line(), +od2odf(), +od_aggregate_from(), +od_aggregate_to(), +od_coords2line(), +od_coords(), +od_id_order(), +od_id, +od_oneway(), +od_to_odmatrix(), +odmatrix_to_od(), +points2flow()

+
-

Examples

- 
data(cents)
-df <- points2odf(cents)
-cents_centroids <- rgeos::gCentroid(cents, byid = TRUE)
-df2 <- points2odf(cents_centroids)
-df3 <- points2odf(cents_sf)
-
-
- -
+
+

Examples

+ 
points2odf(cents_sf)
+#>            O         D
+#> 1  E02002384 E02002384
+#> 2  E02002384 E02002382
+#> 3  E02002384 E02002393
+#> 4  E02002384 E02002367
+#> 5  E02002384 E02002363
+#> 6  E02002384 E02002361
+#> 7  E02002384 E02002377
+#> 8  E02002384 E02002371
+#> 9  E02002382 E02002384
+#> 10 E02002382 E02002382
+#> 11 E02002382 E02002393
+#> 12 E02002382 E02002367
+#> 13 E02002382 E02002363
+#> 14 E02002382 E02002361
+#> 15 E02002382 E02002377
+#> 16 E02002382 E02002371
+#> 17 E02002393 E02002384
+#> 18 E02002393 E02002382
+#> 19 E02002393 E02002393
+#> 20 E02002393 E02002367
+#> 21 E02002393 E02002363
+#> 22 E02002393 E02002361
+#> 23 E02002393 E02002377
+#> 24 E02002393 E02002371
+#> 25 E02002367 E02002384
+#> 26 E02002367 E02002382
+#> 27 E02002367 E02002393
+#> 28 E02002367 E02002367
+#> 29 E02002367 E02002363
+#> 30 E02002367 E02002361
+#> 31 E02002367 E02002377
+#> 32 E02002367 E02002371
+#> 33 E02002363 E02002384
+#> 34 E02002363 E02002382
+#> 35 E02002363 E02002393
+#> 36 E02002363 E02002367
+#> 37 E02002363 E02002363
+#> 38 E02002363 E02002361
+#> 39 E02002363 E02002377
+#> 40 E02002363 E02002371
+#> 41 E02002361 E02002384
+#> 42 E02002361 E02002382
+#> 43 E02002361 E02002393
+#> 44 E02002361 E02002367
+#> 45 E02002361 E02002363
+#> 46 E02002361 E02002361
+#> 47 E02002361 E02002377
+#> 48 E02002361 E02002371
+#> 49 E02002377 E02002384
+#> 50 E02002377 E02002382
+#> 51 E02002377 E02002393
+#> 52 E02002377 E02002367
+#> 53 E02002377 E02002363
+#> 54 E02002377 E02002361
+#> 55 E02002377 E02002377
+#> 56 E02002377 E02002371
+#> 57 E02002371 E02002384
+#> 58 E02002371 E02002382
+#> 59 E02002371 E02002393
+#> 60 E02002371 E02002367
+#> 61 E02002371 E02002363
+#> 62 E02002371 E02002361
+#> 63 E02002371 E02002377
+#> 64 E02002371 E02002371
+
+
+
-
+ - - + + diff --git a/docs/reference/quadrant-1.png b/docs/reference/quadrant-1.png index 8f6f9ce4..9a5adbaa 100644 Binary files a/docs/reference/quadrant-1.png and b/docs/reference/quadrant-1.png differ diff --git a/docs/reference/quadrant.html b/docs/reference/quadrant.html index d060bf45..6916f59e 100644 --- a/docs/reference/quadrant.html +++ b/docs/reference/quadrant.html @@ -1,257 +1,161 @@ - - - - - - - -Split a spatial object into quadrants — quadrant • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Split a spatial object into quadrants

- Source: R/quadrants.R - +
+

Split a spatial object into quadrants

+ Source: R/quadrants.R +
quadrant.Rd
-
-

Split a spatial object (initially tested on SpatialPolygons) into quadrants.

+
+

Returns a character vector of NE, SE, SW, NW corresponding to north-east, south-east +quadrants respectively. If number_out is TRUE, returns numbers from 1:4, respectively.

- 
quadrant(sp_obj, number_out = FALSE)
+
+

Usage

+ 
quadrant(x, cent = NULL, number_out = FALSE)
+
-

Arguments

- - - - - - - - - - -
sp_obj

Spatial object

number_out

Should the output be numbers from 1:4 (FALSE by default)

+
+

Arguments

+
x
+

Object of class sf

-

Details

-

Returns a character vector of NE, SE, SW, NW corresponding to north-east, south-east -quadrants respectively. If number_out is TRUE, returns numbers from 1:4, respectively.

-

See also

+
cent
+

The centrepoint of the region of interest. +Quadrants will be defined based on this point. +By default this will be the geographic centroid of the zones.

-

Other geo: -bbox_scale(), -gclip(), -geo_bb_matrix(), -geo_bb(), -mapshape_available(), -mapshape(), -reproject()

-

Examples

- 
data(zones)
-sp_obj <- zones
-(quads <- quadrant(sp_obj))
-
#> [1] "SE" "SW" "SE" "NE" "NE" "SW" "NW" "SE"
plot(sp_obj, col = factor(quads))
-
points(rgeos::gCentroid(sp_obj), col = "white")
-
# edge cases (e.g. when using rasters) lead to NAs
-sp_obj <- raster::rasterToPolygons(raster::raster(ncol = 3, nrow = 3))
-(quads <- quadrant(sp_obj))
-
#> [1] "SW" NA   "NE" NA   NA   NA   "NW" NA   "SE"
plot(sp_obj, col = factor(quads))
-
-
- -
+
number_out
+

Should the result be returned as a number?

+ +
+
+

See also

+

Other geo: +bbox_scale(), +geo_bb_matrix(), +geo_bb(), +geo_buffer(), +geo_length(), +geo_projected(), +geo_select_aeq()

+
+ +
+

Examples

+ 
x = zones_sf
+(quads <- quadrant(x))
+#> Warning: st_centroid assumes attributes are constant over geometries of x
+#> [1] "SE" "SW" "SE" "NE" "NE" "SW" "NW" "SE"
+plot(x$geometry, col = factor(quads))
+
+
+
+
-
+ - - + + diff --git a/docs/reference/read_table_builder.html b/docs/reference/read_table_builder.html index 5704c780..71a88b77 100644 --- a/docs/reference/read_table_builder.html +++ b/docs/reference/read_table_builder.html @@ -1,189 +1,101 @@ - - - - - - - -Import and format Australian Bureau of Statistics (ABS) TableBuilder files — read_table_builder • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +Import and format Australian Bureau of Statistics (ABS) TableBuilder files — read_table_builder • stplanr + Skip to contents + - - - - - +
-
-
-

Import and format Australian Bureau of Statistics (ABS) TableBuilder files

- Source: R/loadABS.R - +
+

Import and format Australian Bureau of Statistics (ABS) TableBuilder files

+ Source: R/loadABS.R +
read_table_builder.Rd
-
+

Import and format Australian Bureau of Statistics (ABS) TableBuilder files

- 
read_table_builder(dataset, filetype = "csv", sheet = 1, removeTotal = TRUE)
+
+

Usage

+ 
read_table_builder(dataset, filetype = "csv", sheet = 1, removeTotal = TRUE)
+
-

Arguments

- - - - - - - - - - - - - - - - - - -
dataset

Either a dataframe containing the original data from +

+

Arguments

+
dataset
+

Either a dataframe containing the original data from TableBuilder or a character string containing the path of the -unzipped TableBuilder file.

filetype

A character string containing the filetype. Valid values +unzipped TableBuilder file.

+ + +
filetype
+

A character string containing the filetype. Valid values are 'csv', 'legacycsv' and 'xlsx' (default = 'csv'). Required even when dataset is a dataframe. Use 'legacycsv' for csv files derived from earlier versions of TableBuilder for which csv outputs were csv versions of the xlsx files. Current csv output from TableBuilder follow a more standard -csv format.

sheet

An integer value containing the index of the sheet in the -xlsx file (default = 1).

removeTotal

A boolean value. If TRUE removes the rows and columns -with totals (default = TRUE).

+csv format.

+ + +
sheet
+

An integer value containing the index of the sheet in the +xlsx file (default = 1).

-

Details

+
removeTotal
+

A boolean value. If TRUE removes the rows and columns +with totals (default = TRUE).

+ +
+
+

Details

The Australian Bureau of Statistics (ABS) provides customised tables for @@ -191,80 +103,77 @@

Details because it contains rows with additional information. This function imports the original (unzipped) TableBuilder files in .csv or .xlsx format before creating an R dataframe with the data.

+

Note: we recommend using the +readabs +package for this purpose.

+

+
+

See also

+

Other data: +cents_sf, +destinations_sf, +flow_dests, +flowlines_sf, +flow, +od_data_lines, +od_data_routes, +od_data_sample, +osm_net_example, +route_network_sf, +route_network_small, +routes_fast_sf, +routes_slow_sf, +zones_sf

+
-

Examples

- 
data_dir <- system.file("extdata", package = "stplanr")
-t1 <- read_table_builder(file.path(data_dir, "SA1Population.csv"))
-if(requireNamespace("openxlsx")) {
-  t2 <- read_table_builder(file.path(data_dir, "SA1Population.xlsx"),
-    filetype = "xlsx", sheet = 1, removeTotal = TRUE
-)
-}
-
#> Loading required namespace: openxlsx
f <- file.path(data_dir, "SA1Population.csv")
-sa1pop <- read.csv(f, stringsAsFactors = TRUE, header = FALSE)
-t3 <- read_table_builder(sa1pop)
-
-
- -
+
-
+ - - + + diff --git a/docs/reference/route.html b/docs/reference/route.html index cea975e2..508f623e 100644 --- a/docs/reference/route.html +++ b/docs/reference/route.html @@ -1,303 +1,194 @@ - - - - - - - -Plan routes on the transport network — route • stplanr - - - - - +Plan routes on the transport network — route • stplanr + Skip to contents + + +
+
+
+

Plan routes on the transport network

+ Source: R/route.R +
route.Rd
+
+
+

Takes origins and destinations, finds the optimal routes between them +and returns the result as a spatial (sf or sp) object. +The definition of optimal depends on the routing function used

+
+
+

Usage

+ 
route(
+  from = NULL,
+  to = NULL,
+  l = NULL,
+  route_fun = cyclestreets::journey,
+  wait = 0,
+  n_print = 10,
+  list_output = FALSE,
+  cl = NULL,
+  ...
+)
+
- - - +
+

Arguments

+
from
+

An object representing origins +(if lines are provided as the first argument, from is assigned to l)

- - - - - - +
to
+

An object representing destinations

- - - - - +
l
+

A spatial (linestring) object

- - - - - +
route_fun
+

A routing function to be used for converting the lines to routes

- - - +
wait
+

How long to wait between routes? +0 seconds by default, can be useful when sending requests to rate limited APIs.

+
n_print
+

A number specifying how frequently progress updates +should be shown

+
list_output
+

If FALSE (default) assumes spatial (linestring) object output. +Set to TRUE to save output as a list.

- - - - - - +
cl
+

Cluster

- - -
-
- - - - -
- -
-
-
-

Plan routes on the transport network

- Source: R/route.R - +
+
+

See also

+

Other routes: +route_dodgr(), +route_osrm()

+

Other routes: +route_dodgr(), +route_osrm()

-
-

Takes origins and destinations, finds the optimal routes between them -and returns the result as a spatial (sf or sp) object. -The definition of optimal depends on the routing function used

+
+

Examples

+ 
# Todo: add examples
+
+
- - 
route(
-  from = NULL,
-  to = NULL,
-  l = NULL,
-  route_fun = cyclestreets::journey,
-  n_print = 10,
-  list_output = FALSE,
-  cl = NULL,
-  ...
-)
- -

Arguments

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
from

An object representing origins -(if lines are provided as the first argument, from is assigned to l)

to

An object representing destinations

l

Only needed if from and to are empty, in which case this -should be a spatial object representing desire lines

route_fun

A routing function to be used for converting the straight lines to routes -od2line()

n_print

A number specifying how frequently progress updates -should be shown

list_output

If FALSE (default) assumes spatial (linestring) object output. Set to TRUE to save output as a list.

cl

Cluster

...

Arguments passed to the routing function, e.g. route_cyclestreets()

- -

See also

- -

Other routes: -line2routeRetry(), -line2route(), -route_dodgr(), -route_local(), -route_transportapi_public()

- -

Examples

- 
library(osrm)
-
#> Data: (c) OpenStreetMap contributors, ODbL 1.0 - http://www.openstreetmap.org/copyright
#> Routing: OSRM - http://project-osrm.org/
r_osrm <- route(
-  from = c(-0.11, 51.514),
-  to = c(-0.10, 51.506),
-  route_fun = osrmRoute,
-  returnclass = "sf"
-)
-
#> Most common output is sf
r <- overline(routes_fast_sf[2:5, ], "length")
-l <- od2line(od_data_sample[2:5, 1:3], cents_sf)
-sln <- stplanr::SpatialLinesNetwork(r)
-# calculate shortest paths
-plot(sln)
-
plot(l$geometry, add = TRUE)
-
r_local <- stplanr::route(
-  l = l,
-  route_fun = stplanr::route_local,
-  sln = sln
-)
-
#> Most common output is sf
library(sf) # for plotting
-plot(r_local["all"], add = TRUE, lwd = 5)
-
-
- -
+
-
+ - - + + diff --git a/docs/reference/route_osrm.html b/docs/reference/route_osrm.html index 16ac8a2c..ce0cbeee 100644 --- a/docs/reference/route_osrm.html +++ b/docs/reference/route_osrm.html @@ -1,212 +1,200 @@ - - - - - - - -Plan a route with OSRM — route_osrm • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - +Plan routes on the transport network using the OSRM server — route_osrm • stplanr + Skip to contents + +
-
-
-

Plan a route with OSRM

- Source: R/osrmfunctions.R - +
+

Plan routes on the transport network using the OSRM server

+ Source: R/route_osrm.R +
route_osrm.Rd
-
- -

This is a wrapper around viaroute that returns a single route between A and B.

- +
+

This function is a simplified and (because it uses GeoJSON not binary polyline format) +slower R interface to OSRM routing services compared with the excellent +osrm::osrmRoute() function (which can be used via the route()) function.

- 
route_osrm(from, to, l = NULL, alt = FALSE, ..., singleline = TRUE)
- -

Arguments

- - - - - - - - - - - - - - - - - - - - - - - - - - -
from

Text string or coordinates (a numeric vector of -length = 2 representing latitude and longitude) representing a point -on Earth.

to

Text string or coordinates (a numeric vector of -length = 2 representing latitude and longitude) representing a point -on Earth. This represents the destination of the trip.

l

Only needed if from and to are empty, in which case this -should be a spatial object representing desire lines

alt

Boolean value to return alternative routes (default = TRUE).

...

Arguments passed to viaroute()

singleline

Should a single line be returned? Default is TRUE

- -

Note

+
+

Usage

+ 
route_osrm(
+  from,
+  to,
+  osrm.server = "https://routing.openstreetmap.de/",
+  osrm.profile = "foot"
+)
+
-

The public-facing OSRM routing service (the default) -only provides routing for cars by default. For details, see -https://github.com/Project-OSRM/osrm-backend/issues/4530.

- +
+

Arguments

+
from
+

An object representing origins +(if lines are provided as the first argument, from is assigned to l)

-

Examples

- 
# NOT RUN {
-from <- c(-1.55, 53.80) # geo_code("leeds")
-to <- c(-1.76, 53.80) # geo_code("bradford uk")
-r <- route_osrm(from, to)
-plot(r)
-r_many <- line2route(flowlines_sf[2:9, ], route_osrm)
-plot(cents)
-plot(r_many, add = TRUE)
-# }
-
- -
+
to
+

An object representing destinations

-
-
-

Developed by Robin Lovelace, Richard Ellison.

-
-
-

Site built with pkgdown.

+
osrm.server
+

The base URL of the routing server. +getOption("osrm.server") by default.

+ + +
osrm.profile
+

The routing profile to use, e.g. "car", "bike" or "foot" +(when using the routing.openstreetmap.de test server). +getOption("osrm.profile") by default.

+ + +
profile
+

Which routing profile to use? One of "foot" (default) +"bike" or "car" for the default open server.

+ +
+
+

See also

+

Other routes: +route_dodgr(), +route()

+
+ +
+

Examples

+ 
# \donttest{
+# Examples no longer working due to API being down
+# l1 = od_data_lines[49, ]
+# l1m = od_coords(l1)
+# from = l1m[, 1:2]
+# to = l1m[, 3:4]
+# if(curl::has_internet()) {
+# r_foot = route_osrm(from, to)
+# r_bike = route_osrm(from, to, osrm.profile = "bike")
+# r_car = route_osrm(from, to, osrm.profile = "car")
+# plot(r_foot$geometry, lwd = 9, col = "grey")
+# plot(r_bike, col = "blue", add = TRUE)
+# plot(r_car, col = "red", add = TRUE)
+# }
+# }
+
+
+
+
+ + + -
+ +
+ + - - + diff --git a/docs/reference/stplanr-package.html b/docs/reference/stplanr-package.html index c8d2dede..21185220 100644 --- a/docs/reference/stplanr-package.html +++ b/docs/reference/stplanr-package.html @@ -1,239 +1,131 @@ - - - - - - - -stplanr: Sustainable Transport Planning with R — stplanr-package • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +route allocation and modelling travel patterns.">stplanr: Sustainable Transport Planning with R — stplanr-package • stplanr + Skip to contents + - - - - - +
-
-
-

stplanr: Sustainable Transport Planning with R

- Source: R/stplanr-package.R - +
+

stplanr: Sustainable Transport Planning with R

+ Source: R/stplanr-package.R +
stplanr-package.Rd
-
+

The stplanr package provides functions to access and analyse data for transportation research, including origin-destination analysis, route allocation and modelling travel patterns.

+
+

See also

+

https://github.com/ropensci/stplanr

+
+
+

Author

+

Robin Lovelace rob00x@gmail.com

+
-

Interesting functions

- - - -
    -

  • overline() - Aggregate overlaying route lines and data intelligently

    • -

  • calc_catchment() - Create a 'catchment area' to show the areas serving a destination

    • -

  • route_cyclestreets() - Finds the fastest routes for cyclists between two places.

    • -
- -

See also

- -

https://github.com/ropensci/stplanr

-

Author

- -

Robin Lovelace rob00x@gmail.com

- -
- -
+
-
+ - - + + diff --git a/docs/reference/toptail_buff-1.png b/docs/reference/toptail_buff-1.png index 3305fc07..f0dfe250 100644 Binary files a/docs/reference/toptail_buff-1.png and b/docs/reference/toptail_buff-1.png differ diff --git a/docs/reference/toptail_buff.html b/docs/reference/toptail_buff.html index 02e9782e..8eda38b5 100644 --- a/docs/reference/toptail_buff.html +++ b/docs/reference/toptail_buff.html @@ -1,270 +1,171 @@ - - - - - - - -Clip the beginning and ends SpatialLines to the edge of SpatialPolygon borders — toptail_buff • stplanr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
-
+
+ +
+
-
-
-

Clip the beginning and ends SpatialLines to the edge of SpatialPolygon borders

- Source: R/toptail.R - +
+

Clip the beginning and ends of sf LINESTRING objects

+ Source: R/toptail.R +
toptail_buff.Rd
-
+

Takes lines and removes the start and end point, to a distance determined -by the nearest polygon border.

+by the nearest buff polygon border.

- 
toptail_buff(l, buff, ...)
- -

Arguments

- - - - - - - - - - - - - - -
l

An sf LINESTRING object

buff

An sf POLYGON object to act as the buffer

...

Arguments passed to rgeos::gBuffer()

- -

See also

+
+

Usage

+ 
toptail_buff(l, buff, ...)
+
-

Other lines: -angle_diff(), -geo_toptail(), -is_linepoint(), -line2df(), -line2points(), -line_bearing(), -line_breakup(), -line_match(), -line_midpoint(), -line_sample(), -line_segment(), -line_via(), -mats2line(), -n_sample_length(), -n_vertices(), -onewaygeo(), -points2line(), -toptailgs(), -update_line_geometry()

+
+

Arguments

+
l
+

An sf object representing lines

+ + +
buff
+

An sf object with POLYGON geometry to buffer the linestring.

+ + +
...
+

Arguments passed to sf::st_buffer()

+ +
+
+

See also

+

Other lines: +angle_diff(), +geo_toptail(), +is_linepoint(), +line2df(), +line2points(), +line_bearing(), +line_breakup(), +line_midpoint(), +line_segment(), +line_via(), +mats2line(), +n_vertices(), +onewaygeo(), +points2line()

+
-

Examples

- 
l <- routes_fast_sf
-buff <- zones_sf
-r_toptail <- toptail_buff(l, buff)
-
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
#> although coordinates are longitude/latitude, st_intersects assumes that they are planar
#> although coordinates are longitude/latitude, st_difference assumes that they are planar
nrow(l)
-
#> [1] 49
nrow(r_toptail)
-
#> [1] 8
plot(zones_sf$geometry)
-
plot(l$geometry, add = TRUE)
-
plot(r_toptail$geometry, lwd = 5, add = TRUE)
-
-
- -
+
+

Examples

+ 
l <- routes_fast_sf
+buff <- zones_sf
+r_toptail <- toptail_buff(l, buff)
+nrow(l)
+#> [1] 49
+nrow(r_toptail)
+#> [1] 8
+plot(zones_sf$geometry)
+plot(l$geometry, add = TRUE)
+plot(r_toptail$geometry, lwd = 5, add = TRUE)
+
+
+
+
-
+ - - + + diff --git a/man/cents_sf.Rd b/man/cents_sf.Rd index 24ff3edf..6739356f 100644 --- a/man/cents_sf.Rd +++ b/man/cents_sf.Rd @@ -35,6 +35,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/destinations_sf.Rd b/man/destinations_sf.Rd index dabd2f07..bd258bd7 100644 --- a/man/destinations_sf.Rd +++ b/man/destinations_sf.Rd @@ -26,6 +26,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/flow.Rd b/man/flow.Rd index bd435fc4..32109dd0 100644 --- a/man/flow.Rd +++ b/man/flow.Rd @@ -40,6 +40,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} @@ -55,6 +56,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/flow_dests.Rd b/man/flow_dests.Rd index 0c91c3d5..85faa4e9 100644 --- a/man/flow_dests.Rd +++ b/man/flow_dests.Rd @@ -36,6 +36,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/flowlines_sf.Rd b/man/flowlines_sf.Rd index fbacfec1..b68bf2c1 100644 --- a/man/flowlines_sf.Rd +++ b/man/flowlines_sf.Rd @@ -22,6 +22,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/line_cast.Rd b/man/line_cast.Rd new file mode 100644 index 00000000..8f54b6e2 --- /dev/null +++ b/man/line_cast.Rd @@ -0,0 +1,14 @@ +% Generated by roxygen2: do not edit by hand +% Please edit documentation in R/rnet_join.R +\name{line_cast} +\alias{line_cast} +\title{Convert multilinestring object into linestrings} +\usage{ +line_cast(x) +} +\arguments{ +\item{x}{Linestring object} +} +\description{ +Without losing vertices +} diff --git a/man/od_data_lines.Rd b/man/od_data_lines.Rd index 34051f67..657657c6 100644 --- a/man/od_data_lines.Rd +++ b/man/od_data_lines.Rd @@ -25,6 +25,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/od_data_routes.Rd b/man/od_data_routes.Rd index 20987925..d7a17c9f 100644 --- a/man/od_data_routes.Rd +++ b/man/od_data_routes.Rd @@ -27,6 +27,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/od_data_sample.Rd b/man/od_data_sample.Rd index 1c633e1b..8930e8d8 100644 --- a/man/od_data_sample.Rd +++ b/man/od_data_sample.Rd @@ -25,6 +25,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/osm_net_example.Rd b/man/osm_net_example.Rd index fa8e660a..3652e4b6 100644 --- a/man/osm_net_example.Rd +++ b/man/osm_net_example.Rd @@ -25,6 +25,7 @@ Other data: \code{\link{od_data_sample}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/read_table_builder.Rd b/man/read_table_builder.Rd index d7ab8ba8..35ae988f 100644 --- a/man/read_table_builder.Rd +++ b/man/read_table_builder.Rd @@ -52,6 +52,7 @@ Other data: \code{\link{od_data_sample}}, \code{\link{osm_net_example}}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/rnet_join.Rd b/man/rnet_join.Rd new file mode 100644 index 00000000..9010b26d --- /dev/null +++ b/man/rnet_join.Rd @@ -0,0 +1,95 @@ +% Generated by roxygen2: do not edit by hand +% Please edit documentation in R/rnet_join.R +\name{rnet_join} +\alias{rnet_join} +\title{Join route networks} +\usage{ +rnet_join( + rnet_x, + rnet_y, + dist = 5, + length_y = TRUE, + key_column = 1, + subset_x = TRUE, + dist_subset = 5, + split_y = TRUE, + ... +) +} +\arguments{ +\item{rnet_x}{Target route network, the output will have the same geometries +as features in this object.} + +\item{rnet_y}{Source route network. Columns from this route network object will +be copied across to the new network.} + +\item{dist}{The buffer width around rnet_y in meters. 1 m by default.} + +\item{length_y}{Add a new column called \code{length_y}? Useful when joining based on +length of segments (e.g. weighted mean). \code{TRUE} by default.} + +\item{key_column}{The index of the key (unique identifier) column in \code{rnet_x}.} + +\item{subset_x}{Subset the source route network by the target network before +creating buffers? This can lead to faster and better results. Default: +\code{TRUE}.} + +\item{dist_subset}{The buffer distance in m to apply when breaking up the +source object \code{rnet_y}. Default: 5.} + +\item{split_y}{Should the second route network be split at the start and +end points of LINESTRING features in the first? \code{TRUE} by default.} + +\item{...}{Additional arguments passed to \code{rnet_subset}.} +} +\description{ +This is a spatial join function that is enables adding columns to a +'target' route network from a 'source' route +network that contains the base geometry, e.g. from OSM +} +\details{ +The output is an sf object containing polygons representing +buffers around the route network in \code{rnet_x}. +The examples below demonstrate how to join attributes from +a route network object created with the function \code{\link[=overline]{overline()}} onto +OSM geometries. + +Note: The main purpose of this function is to join an ID from \code{rnet_x} +onto \code{rnet_y}. Subsequent steps, e.g. with \code{\link[dplyr:mutate-joins]{dplyr::inner_join()}} +are needed to join the attributes back onto \code{rnet_x}. +There are rarely 1-to-1 relationships between spatial network geometries +so we take care when using this function. + +See \href{https://github.com/ropensci/stplanr/issues/505}{#505} for details +and a link to an interactive example of inputs and outputs shown below. +} +\examples{ +library(sf) +library(dplyr) +# Uncomment for interactive examples: +plot(route_network_small["flow"]) +plot(osm_net_example$geometry, lwd = 5, col = "grey") +plot(route_network_small["flow"], add = TRUE) +rnetj = rnet_join(osm_net_example, route_network_small, dist = 9) +# library(mapview) +# mapview(rnetj, zcol = "flow") + +# mapview(route_network_small, zcol = "flow") +plot(rnetj["flow"]) +plot(route_network_small["flow"], add = TRUE) +rnetj_summary = rnetj \%>\% + sf::st_drop_geometry() \%>\% + group_by(osm_id) \%>\% + summarise( + flow = weighted.mean(flow, length_y, na.rm = TRUE), + ) +osm_joined_rnet = left_join(osm_net_example, rnetj_summary) +plot(route_network_small["flow"]) +plot(osm_joined_rnet[c("flow")]) +# Improve fit between geometries and performance by subsetting rnet_x +osm_subset = rnet_subset(osm_net_example, route_network_small, dist = 5) +osm_joined_rnet = left_join(osm_subset, rnetj_summary) +plot(route_network_small["flow"]) +plot(osm_joined_rnet[c("flow")]) +# mapview(joined_network) + +# mapview(route_network_small) +} diff --git a/man/rnet_split_lines.Rd b/man/rnet_split_lines.Rd new file mode 100644 index 00000000..f137de57 --- /dev/null +++ b/man/rnet_split_lines.Rd @@ -0,0 +1,20 @@ +% Generated by roxygen2: do not edit by hand +% Please edit documentation in R/rnet_join.R +\name{rnet_split_lines} +\alias{rnet_split_lines} +\title{Split lines in a route network based points} +\usage{ +rnet_split_lines(rnet_x, geo_y, dist = 1) +} +\arguments{ +\item{rnet_x}{The route network to be broken into smaller pieces} + +\item{geo_y}{The geographic object used to break up the route network} + +\item{dist}{The width of the buffer used when breaking up the route network. +For imprecise data it may be worth increasing this above 1 m, the default.} +} +\description{ +If the object passed to the second argument has LINSTRING geometries +the start and end points of linestrings are used. +} diff --git a/man/rnet_subset.Rd b/man/rnet_subset.Rd new file mode 100644 index 00000000..87ad093c --- /dev/null +++ b/man/rnet_subset.Rd @@ -0,0 +1,24 @@ +% Generated by roxygen2: do not edit by hand +% Please edit documentation in R/rnet_join.R +\name{rnet_subset} +\alias{rnet_subset} +\title{Subset one route network based on overlaps with another} +\usage{ +rnet_subset(rnet_x, rnet_y, dist = 1, crop = TRUE, min_x = 3) +} +\arguments{ +\item{rnet_x}{The route network to be subset} + +\item{rnet_y}{The subsetting route network} + +\item{dist}{The buffer width around y in meters. 1 m by default.} + +\item{crop}{Crop \code{rnet_x}? \code{TRUE} is the default} + +\item{min_x}{Segments shorter than this multiple of dist +\emph{and} which were longer +before the cropping process will be removed. 3 by default.} +} +\description{ +Subset one route network based on overlaps with another +} diff --git a/man/route_network_sf.Rd b/man/route_network_sf.Rd index 78cc3d75..f9255968 100644 --- a/man/route_network_sf.Rd +++ b/man/route_network_sf.Rd @@ -3,7 +3,7 @@ \docType{data} \name{route_network_sf} \alias{route_network_sf} -\title{spatial lines dataset representing a route network} +\title{Spatial lines dataset representing a route network} \format{ A spatial lines dataset 80 rows and 1 column } @@ -23,6 +23,7 @@ Other data: \code{\link{od_data_sample}}, \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} diff --git a/man/route_network_small.Rd b/man/route_network_small.Rd new file mode 100644 index 00000000..3b6ab221 --- /dev/null +++ b/man/route_network_small.Rd @@ -0,0 +1,32 @@ +% Generated by roxygen2: do not edit by hand +% Please edit documentation in R/data.R +\docType{data} +\name{route_network_small} +\alias{route_network_small} +\title{Spatial lines dataset representing a small route network} +\format{ +A spatial lines dataset with one column: flow +} +\description{ +The flow between randomly selected vertices on the \code{osm_net_example}. +See \code{data-raw/route_network_small.R} for details. +} +\seealso{ +Other data: +\code{\link{cents_sf}}, +\code{\link{destinations_sf}}, +\code{\link{flow_dests}}, +\code{\link{flowlines_sf}}, +\code{\link{flow}}, +\code{\link{od_data_lines}}, +\code{\link{od_data_routes}}, +\code{\link{od_data_sample}}, +\code{\link{osm_net_example}}, +\code{\link{read_table_builder}()}, +\code{\link{route_network_sf}}, +\code{\link{routes_fast_sf}}, +\code{\link{routes_slow_sf}}, +\code{\link{zones_sf}} +} +\concept{data} +\keyword{datasets} diff --git a/man/routes_fast_sf.Rd b/man/routes_fast_sf.Rd index de48d341..eb54535f 100644 --- a/man/routes_fast_sf.Rd +++ b/man/routes_fast_sf.Rd @@ -28,6 +28,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_slow_sf}}, \code{\link{zones_sf}} } diff --git a/man/routes_slow_sf.Rd b/man/routes_slow_sf.Rd index f6ac3d1a..baa1d223 100644 --- a/man/routes_slow_sf.Rd +++ b/man/routes_slow_sf.Rd @@ -24,6 +24,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{zones_sf}} } diff --git a/man/zones_sf.Rd b/man/zones_sf.Rd index 9e3d949d..83f1ae77 100644 --- a/man/zones_sf.Rd +++ b/man/zones_sf.Rd @@ -30,6 +30,7 @@ Other data: \code{\link{osm_net_example}}, \code{\link{read_table_builder}()}, \code{\link{route_network_sf}}, +\code{\link{route_network_small}}, \code{\link{routes_fast_sf}}, \code{\link{routes_slow_sf}} }