tidy routing

Author: temospena

routing.qmd

@@ -11,7 +11,8 @@ engine: knitr
 ::: callout-note
 ### OD data
 
-If you have **travel survey** data, for some exercises you may use that one. See also [Jittering](jittering.qmd), if needed.
+If you have **travel survey** data, for some exercises you may use that one.
+See also [Jittering](jittering.qmd), if needed.
 
 For all the other, we can simply use **census** data.
 :::
@@ -26,11 +27,15 @@ nrow(POINTS) # 2822
 sum(POINTS$residents) # 545.796
 ```
 
-With census data, each statistical unit represents \~300 residents. In Lisbon, we have 2822 census units.
+With census data, each statistical unit represents \~300 residents.
+In Lisbon, we have 2822 census units.
 
-Routing between all origins and destinations (2822 x 2822 = **7.963.684 OD pairs**) can potentially be a long-duration process. Nothing that r5r wouldn't handle! 🙂
+Routing between all origins and destinations (2822 x 2822 = **7.963.684 OD pairs**) can potentially be a long-duration process.
+Nothing that r5r wouldn't handle!
+🙂
 
-But here we will consider a `city_center` location, and route our census population to the city center. Search in an online map the coordinates for a point that you would like to consider your attractor.
+But here we will consider a `city_center` location, and route our census population to the city center.
+Search in an online map the coordinates for a point that you would like to consider your attractor.
 
 ```{r}
 # Create origin point - Baixa / Downtown
@@ -86,7 +91,8 @@ hist(ttm_car$travel_time_p50)
 
 By car, all the 2822 points with residents are able to be reach from city center.
 
-In free-flow, the longest trip takes 26 minutes. 50% of the trips are shorter than 12 minutes.
+In free-flow, the longest trip takes 26 minutes.
+50% of the trips are shorter than 12 minutes.
 
 ### Walk
 
@@ -124,29 +130,40 @@ hist(ttm_walk$travel_time_p50)
 
 ![](images/clipboard-2894920258.png){fig-align="center"}
 
-The longest trip takes 120 minutes (equal to the max travel time). The time distribution is pretty even.
+The longest trip takes 120 minutes (equal to the max travel time).
+The time distribution is pretty even.
 
 ### Bike
 
 When considering **bike** trips, we can also set a maximum level of traffic stress [@LTSmineta] that cyclists will tolerate.
 
 #### LTS
 
-A value of 1 means cyclists will only travel through the quietest streets, while a value of 4 indicates cyclists can travel through any road. **Defaults to 2, which can be very restrictive in Lisbon (depends on your case study).**
+A value of 1 means cyclists will only travel through the quietest streets, while a value of 4 indicates cyclists can travel through any road.
+**Defaults to 2, which can be very restrictive in Lisbon (depends on your case study).**
 
 From @Pereira2021r5r:
 
-When cycling is enabled in `R5` (by passing the value `BIKE` to either `mode` or `mode_egress`), setting `max_lts` will allow cycling only on streets with a given level of danger/stress. Setting `max_lts` to 1, for example, will allow cycling only on separated bicycle infrastructure or low-traffic streets and routing will revert to walking when traversing any links with LTS exceeding 1. Setting `max_lts` to 3 will allow cycling on links with LTS 1, 2 or 3. Routing also reverts to walking if the street segment is tagged as non-bikable in OSM (e.g. a staircase), independently of the specified max LTS.
+When cycling is enabled in `R5` (by passing the value `BIKE` to either `mode` or `mode_egress`), setting `max_lts` will allow cycling only on streets with a given level of danger/stress.
+Setting `max_lts` to 1, for example, will allow cycling only on separated bicycle infrastructure or low-traffic streets and routing will revert to walking when traversing any links with LTS exceeding 1.
+Setting `max_lts` to 3 will allow cycling on links with LTS 1, 2 or 3.
+Routing also reverts to walking if the street segment is tagged as non-bikable in OSM (e.g. a staircase), independently of the specified max LTS.
 
-The default methodology for assigning LTS values to network edges is based on commonly tagged attributes of OSM ways. See more info about LTS in the original documentation of R5 from Conveyal at <https://docs.conveyal.com/learn-more/traffic-stress>. In summary:
+The default methodology for assigning LTS values to network edges is based on commonly tagged attributes of OSM ways.
+See more info about LTS in the original documentation of R5 from Conveyal at <https://docs.conveyal.com/learn-more/traffic-stress>.
+In summary:
 
--   **LTS 1**: Tolerable for children. This includes low-speed, low-volume streets, as well as those with separated bicycle facilities (such as parking-protected lanes or cycle tracks).
+-   **LTS 1**: Tolerable for children.
+    This includes low-speed, low-volume streets, as well as those with separated bicycle facilities (such as parking-protected lanes or cycle tracks).
 
--   **LTS 2**: Tolerable for the mainstream adult population. This includes streets where cyclists have dedicated lanes and only have to interact with traffic at formal crossing.
+-   **LTS 2**: Tolerable for the mainstream adult population.
+    This includes streets where cyclists have dedicated lanes and only have to interact with traffic at formal crossing.
 
--   **LTS 3**: Tolerable for "enthused and confident" cyclists. This includes streets which may involve close proximity to moderate- or high-speed vehicular traffic.
+-   **LTS 3**: Tolerable for "enthused and confident" cyclists.
+    This includes streets which may involve close proximity to moderate- or high-speed vehicular traffic.
 
--   **LTS 4**: Tolerable only for "strong and fearless" cyclists. This includes streets where cyclists are required to mix with moderate- to high-speed vehicular traffic.
+-   **LTS 4**: Tolerable only for "strong and fearless" cyclists.
+    This includes streets where cyclists are required to mix with moderate- to high-speed vehicular traffic.
 
 For advanced users, you can provide custom LTS values by adding a tag `<key = "lts">` to the `osm.pbf` file.
 
@@ -184,19 +201,23 @@ When estimating travel time with public transit, some considerations should be p
 
 -   **Date and time** of the trips
 
--   Which **modes** are allowed? All or just some of PT?
+-   Which **modes** are allowed?
+    All or just some of PT?
 
 -   How many **transfers** are allowed
 
--   How to **get to the PT stop**? By foot, bike or car? The same from the last stop to the destination
+-   How to **get to the PT stop**?
+    By foot, bike or car?
+    The same from the last stop to the destination
 
 -   How many minutes it is **reasonable to walk** (of bike) in max during the whole trip?
 
 -   Is my best time-travel estimate the same, if I consider a 5min **time-window** period or a 30min time-window period?
 
 #### Date and time
 
-This is a very relevant parameter (`departure_datetime)`. If your selected date is not part of your GTFS calendar, you will not be able to estimate travel by **PT** on those dates.
+This is a very relevant parameter (`departure_datetime)`.
+If your selected date is not part of your GTFS calendar, you will not be able to estimate travel by **PT** on those dates.
 
 ##### Confirm service calendar
 
@@ -219,7 +240,8 @@ uses         stop_times (no frequencies)
 # shapes       307
 ```
 
-My GTFS runs from **2025-09-01** to **2025-12-01**. I will select a **working day**, and a **peak hour** for this exercises.
+My GTFS runs from **2025-09-01** to **2025-12-01**.
+I will select a **working day**, and a **peak hour** for this exercises.
 
 ```{r}
 departure_datetime = as.POSIXct("01-10-2025 08:00:00", # wednesday
@@ -230,7 +252,8 @@ When I change this parameter, my results may be totally different.
 
 #### Modes
 
-`R5` allows for multiple combinations of transport modes. The options include:
+`R5` allows for multiple combinations of transport modes.
+The options include:
 
 -   **Transit modes:** `TRAM`, `SUBWAY`, `RAIL`, `BUS`, `FERRY`, `CABLE_CAR`, `GONDOLA`, `FUNICULAR`.\
     The option `TRANSIT` automatically considers **all public transport modes** available.
@@ -239,13 +262,16 @@ When I change this parameter, my results may be totally different.
 
 #### Transfers
 
-The maximum number of public transport rides allowed in the same trip. The `max_rides` defaults to 3. Consider a plausible number, and take into consideration that shifting from one metro line to other will be considered as 2 rides.
+The maximum number of public transport rides allowed in the same trip.
+The `max_rides` defaults to 3.
+Consider a plausible number, and take into consideration that shifting from one metro line to other will be considered as 2 rides.
 
 #### Egress mode and max walk time
 
 The transport mode used after egress from the last public transport.\
 It can be either `WALK`, `BICYCLE` or `CAR`.\
-Defaults to `WALK`. Ignored when public transport is not used.
+Defaults to `WALK`.
+Ignored when public transport is not used.
 
 The `max_walk_time` (or bike or car) time (in minutes) to access and egress the transit network, to make transfers within the network or to complete walk-only trips.
 
@@ -257,7 +283,8 @@ To calculate the travel time from A to B, or to calculate the accessibility leve
 
 Even a small difference, say leaving at `10:00am` or `10:04am` might importantly change travel time and accessibility estimates depending on when a person departs relative to when a public transport vehicle arrives, and how well transfers are coordinated given a service timetable.
 
-When `time_window` is set, R^5^ computes multiple travel times / accessibility estimates starting at the specified `departure_datetime` and within the `time_window` selected by the user. By default, `r5r` will generate **one estimate per minute**.
+When `time_window` is set, R^5^ computes multiple travel times / accessibility estimates starting at the specified `departure_datetime` and within the `time_window` selected by the user.
+By default, `r5r` will generate **one estimate per minute**.
 
 By default, r5r results have the **50th percentile** of travel time.
 
@@ -303,7 +330,8 @@ summary(ttm_transit$travel_time_p50)
 
 ![](images/clipboard-2721979667.png)
 
-50% of the trips take less than 31 minutes. The distribution is pretty normal.
+50% of the trips take less than 31 minutes.
+The distribution is pretty normal.
 
 ::: {.callout-tip appearance="simple"}
 Try to change some parameters, such as the `max_rides` or the `max_trip_duration` and compare the results.
@@ -313,13 +341,15 @@ Try to change some parameters, such as the `max_rides` or the `max_trip_duration
 
 With the [`detailed_itineraries`](https://ipeagit.github.io/r5r/reference/detailed_itineraries.html)`()`, we can extract more information about each trip, such as:
 
--   Which modes were used for trip *x*? In which order?
+-   Which modes were used for trip *x*?
+    In which order?
 
 -   What is the duration for each leg?
 
 -   Which route (shape) was estimated?
 
-This function is also pretty flexible and allows to see more details. Also, because of this, it may require some **more processing cost**.
+This function is also pretty flexible and allows to see more details.
+Also, because of this, it may require some **more processing cost**.
 
 ### Multi-modal legs
 
@@ -409,7 +439,8 @@ Click on each segment to analyse the details, in particular the segment duration
 
 ## Circuity
 
-**Circuity** measures how direct or indirect a travel route is compared to the straight-line (Euclidean) distance between an origin and a destination. It reflects the efficiency of the transport network in providing direct connections.
+**Circuity** measures how direct or indirect a travel route is compared to the straight-line (Euclidean) distance between an origin and a destination.
+It reflects the efficiency of the transport network in providing direct connections.
 
 The **circuity index** (C) measures how indirect a route is compared to the straight-line distance between an origin and a destination, and is defined as:
 
@@ -428,7 +459,8 @@ In this exercise, circuity will be estimated separately for **car, walking, cycl
 
 ### Euclidean distances
 
-First we will create lines connecting the survey locations to the university, using the `st_nearest_points()` function. This function finds returns the nearest points between two geometries, and creates a line between them.
+First we will create lines connecting the survey locations to the university, using the `st_nearest_points()` function.
+This function finds returns the nearest points between two geometries, and creates a line between them.
 
 ```{r}
 dist_euclidean = st_nearest_points(POINTS, BAIXA, pairwise = TRUE) |>
@@ -670,7 +702,8 @@ Finally, we visualized and aggregated routes using `stplanr::overline()`, combin
 
 ## Stop
 
-`r5r` objects are still allocated to any amount of memory previously set after they are done with their calculations. In order to remove an existing `r5r` object and reallocate the memory it had been using, we use the `stop_r5` function followed by a call to Java’s garbage collector, as follows:
+`r5r` objects are still allocated to any amount of memory previously set after they are done with their calculations.
+In order to remove an existing `r5r` object and reallocate the memory it had been using, we use the `stop_r5` function followed by a call to Java’s garbage collector, as follows:
 
 ```{r}
 r5r::stop_r5(r5r_lisboa)