Detailed itineraries routing doesn't account for locally created turn restrictions

[jamiedtor]

We're deploying r5 (through the r5r wrapper) to test the impact of various street network scenarios that include new ways, traffic filtering and vehicle turning restrictions. We are manually editing a local OSM .pbf offline using JOSM to insert and tag the new ways and nodes. For proposed turning restrictions, we have tried using the JOSM plug-in "turnrestrictions" and directly editing relationships.

When routing, r5 makes use of the new ways and correctly considers tags regarding directionality, max speed, etc. It appears, however, to ignore turn restrictions applied to relations with a member that is a new local way and/or a new local node, whether generated manually or at intersections. If we apply a new turn restriction to an existing node and existing ways** with standard "ids," r5 does recognize and implement it.

We've double checked all other tagging, and it appears that the only observable difference between the nodes and ways where the restrictions work and don't is if they are newly created locally (with the auto-generated id=0) or downloaded from the OSM server. Because we're testing hypothetical scenarios, we don't want to try uploading our edits to the local .pbf. to see if generating OSM ids would address the issue.

We've attached a few screenshots and a minimum reproducible R code. We believe it may be related to how r5 parses the .pbf and routes over the network, but I can't be 100 percent sure. (We tried to upload a dummy .pbf but it's not supported by Github).

As you can see in the first figure showing the routing output, no right turn should be allowed where the yellow line meets Queen Street East. Similarly, through movement is theoretically prohibited where the purple line crosses Queen Street but it nevertheless does. For one of the red circles, the node is a new local one. For the other red circle, the node was existing, but one of the participating ways is new.

In the second image, the location circled in green contains an existing node and two previously existing ways that we merely edited in JOSM to restrict through movement. It works.

Is this a known behaviour (with a potential fix?)? Or is there another method to edit the pbf for use with r5r?

Reproducible example here

setwd(" ______ ")

# allocate RAM memory to Java
options(java.parameters = "-Xmx16G")

library(r5r)
library(dplyr)
library(mapview)
library(sf)


# build transport network, pointing to the path where OSM data are stored

path <- "________" #path to data

r5r_core <- setup_r5(data_path = path, verbose = FALSE)

# load origin/destination points and set arguments

origin <- data.frame(
  id = "from_1",
  lon = -79.73729,
  lat = 43.70265
)

dests <- data.frame(
  id = c("to_1", "to_2"),
  lon = c(-79.78185, -79.76975),
  lat = c(43.71601, 43.72611)
)

mode <- c("CAR")
max_walk_time <- 30   # minutes
max_trip_duration <- 60 # minutes
departure_datetime <- as.POSIXct("13-05-2019 14:00:00",
                                 format = "%d-%m-%Y %H:%M:%S")

# get detailed info on multiple alternative routes
det <- detailed_itineraries(r5r_core = r5r_core,
                            origins = origin,
                            destinations = dests,
                            mode = mode,
                            departure_datetime = departure_datetime,
                            max_walk_time = max_walk_time,
                            max_trip_duration = max_trip_duration,
                            shortest_path = FALSE,
                            drop_geometry = FALSE)

mapview(det, zcol = "to_id")

[rafapereirabr]

Hi @jamiedtor . Thank you for opening this issue. This looks like a very important issue to run simulations with different scenarios of road interventions. This is an upstream isssue related to how R5 internal parses OSM data, so there is nothing we can do from the R side, unforthunately. I'm glad to see you have already opened an issue on R5 repo. I hope the are able to address this issue sometime soon.

Since this is not an issue that can be addressed from r5r, I'm closing this issue for now.