r5 not accounting for turn restrictions applied to locally created node-way combinations

[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 (although it seems to be a question of how the r5 engine parses the .pbf and routes over the network). (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?)?

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")

[jamiedtor]

Not sure if this is helpful, but we observed a similar behaviour in Open Trip Planner v. 1.x. , referenced in this issue: https://github.com/opentripplanner/OpenTripPlanner/issues/4720#issue-1537352553

OTP 2.2 does, however, respect the turn restrictions: https://github.com/opentripplanner/OpenTripPlanner/issues/2991

Thought this might point to potential source of the problem or a solution.

[abyrd]

Hi @jamiedtor, thanks for the detailed report. On first inspection I don't think this is the same problem encountered in OTP 1.x / 2.x because R5 performs serialization in a single pass, without the same risk of resetting a reference table. Additionally, com.conveyal.r5.streets.TurnRestriction stores from/to/via edges as integer indexes rather than object references. So we'll need to dig into this more to find the source of the problem.

[jamiedtor]

Hi, there. I was just wondering whether anyone else had observed this behaviour? We recently had occassion to test again with the most recent release of r5 and it still appears to occur. I'm still wondering if it might have something to do with how we're coding the nodes.

[abyrd]

Hi @jamiedtor, I'm taking another look at this. You wrote: "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."

Are you referring to JOSM generating these ids equal to zero? Are you referring to way IDs or turn restriction relation IDs? If I remember correctly the convention is to use negative IDs for any local objects that have not been added to the main OSM database, and I think JOSM follows this convention. If every newly created object has an ID of zero, I would not expect turn restrictions (nor many other things) to work because unique IDs are required - to reference the ways making up a turn restriction for example.

Can you clarify where you observed that IDs were zero? Was this in the OSM editor, or examining the OSM output files, or the internal state of R5?