Change priority based on turn preference

Hi! I have been looking at the documentation and found some interesting information about turn costs, but it looks like its implementation relies on the presence of restriction tags on the OSM data. Is there a way to prefer a certain turn at an intersection?

For example, change the priority value depending on which side a biker decides to turn?
If (going straight)
Priority: 1.1
If (turning right)
Priority: 1.3
If (turning left)
priority: .7

I understand this might not be the exact implementation, but where should I start looking into to get something like this?

P.S: Thank you for this project! Appreciate the effort put into it.

I tried it here: Flexible / Configurable Weighting Update - #2 by karussell

But never had the time to make it production-ready.

(Please note that the custom model format changed significantly since then, see here for the latest documentation on this.)

1 Like

Thank you for the context! The previous iteration is just what I need! I have been going through the its implementation and found out that the config files previously used for speed, priority and turnCosts custom routing are gone (I assume those were left behind in favor of EdgeToDoubleMapping). Any advice on how to implement it in the current version?

I just implemented it for the latest version :slight_smile:

To use this branch you need the following in the config (see the config-example.yml for a complete example):

graphhopper:
  ...
  graph.encoded_values: orientation
  profiles:
    - name: car
      vehicle: car
      turn_costs: true
      weighting: custom
      custom_model: # specify some custom model, the specific one here is just an example
        distance_influence: 70

To use the GH Maps UI you use the format like:

"turn_cost": {
  "straight_cost": 1,
  "left_cost": 1,
  "right_cost": 1,
  "min_left_angle": 17,
  "max_left_angle": 180,
  "min_right_angle": -17,
  "max_right_angle": -180
}

But you have to press Ctrl+Enter as the Search button won’t be enabled as the custom model is seen as invalid.

The turn detection is now done differently via an orientation change (and has certainly its problems) but in general this simple method works better and previously failing tests are now passing.

Still this is not yet production ready because it is unclear to me how to make the modeling more realistic, e.g. where the road_class and changes regarding road_class are also considered. Also regarding performance it is currently suboptimal that we have to use the getEdgeIteratorState.

The best would be to have access to the encoded values of the previous edge in the priority and speed section too but this was hard to achieve in the code and might be expensive regarding performance too.

Powered by Discourse