handling turn restrictions

[idshklein]

Is your feature request related to a problem? Please describe.
in osm and routing networks it is common to have turn restrictions. these change the possible shortest paths of a given mode.
due to the fact that no open or clear algorithm exist for that matter, I either use valhalla when using osm (it takes turn restrictions into account) or proprietary software. I havent found routing engines in the R ecosystem that do that.

Describe the solution you'd like
there is one way I know to handle this problem that is implemented in MATSim that basically changes the structure of the net, and breaks a node that has a restriction to a system of many nodes.
due to the fact that this solution might cause spatial distortions a mess up graph indexing, I thought of a different
way to tackle the problem - switching nodes and edges using to_linegraph, and then removing those "edge-to-edge" (which resemble a part of a node) edges, thus implementing turn restrictions.
(my post-doc instructor once told me there are 3 ways to deal with turn restrictions, but never told me which ones; here are 2. there are probably more and they might be more readible/efficient. )

Describe alternatives you've considered
this mainly gpt-generated script is a start, I don't know how to move weights from the edges to the nodes so st_network_cost will take them into account, or how to use the temp network to start and end in a specific node and not in an edge.

library(sfnetworks)
library(tidygraph)
#> Warning: package 'tidygraph' was built under R version 4.3.3
#> 
#> Attaching package: 'tidygraph'
#> The following object is masked from 'package:stats':
#> 
#>     filter


# Original sfnetwork 'g' with spatial edges
lg <- convert(as_sfnetwork(roxel), to_linegraph)



# Suppose you have a data frame 'turns' listing prohibited transitions:
#   from_edge_id | to_edge_id
from_edge_id = 423
to_edge_id = 1
lg2 <- lg %>% 
  activate("edges") %>% 
  filter(!(from %in% from_edge_id & to %in% to_edge_id))


# Now 'lg2' is a line graph without the restricted turns.
Created on 2025-06-10 with [reprex v2.1.1](https://reprex.tidyverse.org/)

[Robinlovelace]

This would indeed be a great feature, thanks for suggesting it @idshklein. The code that 'expands' the network to deal with restrictions in MATSim seems like one option (as far as I can understand, although I'm not sure why there is a 'radius' argument in there). Just a clarification: the code above is how you could envision it working after the feature is implemented?

[idshklein]

nope, the code is a very general direction regarding implementation.
I envision it this way- the as_sfnetwork/sfnetwork will need to get three args: the net read from an sf object, a table with turn restrictions with from_edge to_edge fields, and the name of the id col in the net that connects to the turn restrictions.

[Robinlovelace]

Yes, that does sound like quite a major feature request. {dodgr} has turn restrictions implemented by @mpadge: https://github.com/search?q=repo%3AUrbanAnalyst%2Fdodgr%20restrictions&type=code

Would be interested to hear your thoughts Mark on this.

[Robinlovelace]

Another piece of advice that suggests this is hard and may be out of scope here is this comment from @Tristramg, author of osm4routing2:

No there aren’t taken in account. Once you start working with turn restrictions, the model get suddenly way more complicated, and that probably means you are working on some serious stuff, not on a toy project, and osm4routing will be missing tons of little things.

Source: rust-transit/osm4routing2#19

[Robinlovelace]

I'm wondering if it could be worth testing implementations in an add-on package that extends {sfnetworks} in the first instance to test ideas.

[mpadge]

Thanks for the ping @Robinlovelace. There are two distinct issues here:

1. Turn restrictions which are purely spatial, and could indeed be implemented along the lines that @idshklein suggested above. These are binary distinctions (yes/no), and just involve removing edges from a network. That could be implemented in this package without too much effort.
2. Turn penalties which is what dodgr implements. That's way harder, and almost always a time-based consideration: turning left takes n times longer than turning right, where n = Inf for true restrictions. But sfnetworks by it's very name is not concerned with time, so we'd only ever be talking about the first case.

All thoughts are concerns about the difficulty or impossibility of turn restrictions are referring in practice to turn penalties, and so don't really apply here. Biggest challenge would be conceiving of how to construct a functional interface that was both simple and general - how could potential restrictions be specified? sf itself is spatial at it's core, unlike OSM which specifies relations between labelled entities that also happen to carry coordinates. I can't imagine any easy way to specify turn restrictions in a purely spatial context. Or @idshklein in the context of your code, many data sets using in this package would have no unique "edge_id", or in the best case would only have those imposed at some later stage during processing. sf data used to construct networks must be generally presumed to not have inherent edge_id_ values. My conclusion: implementation here would be relatively straightforward, but constructing a functional interface would be ... at the very least exceedingly difficult.

[Robinlovelace]

Also tagging @juanfonsecaLS1 who is doing a PhD on traffic modelling. We discussed turn-restrictions yesterday. No regrets strategy: finding a set of minimal networks where turn restrictions is a thing and show what currently happens and what should happen.