Costs for "turn-left" in special cases

[EssBee59]

trafficstars

Intuitively, depending on the traffic side in your country, the costs of a turn to the left or to the right should differ ... (see previous request https://github.com/abrensch/brouter/issues/110) But simply adding costs in each turn-left situation do not really improve the routing (similar side-effects appear as example when adding costs for "traffic-signals")

Some weeks ago I found a new use case that can be visualize with this link:
https://brouter.de/essbee/#map=16/49.8375/8.8337/standard&lonlats=8.828501,49.840029;8.833551,49.834414&profile=fastbike-verylowtraffic

• In my profile, cycleways / pathes / tracks with good asphalted surface have a lower cost as tertiary/secondary/primary (well-founded for fastbike?)
• Often we have the situation where a cycleway / track / path exists parallel to a primary/secondary/tertiary BUT only on ONE side
• In this situation, the router will redirect the biker from primary/secondary/tertiary to the cycleway / track / path

The special case: The cycleway / track / path is on the left side in my direction, AND only a relativ "short" peace of the cycleway / track / path will be used in my tour! Should I really turn left to the cycleway or stay on the tertiary for 500 meters?

The feature "nice to have": I think, the routing engine should be able to consider the costs for turn-left in special cases! (filters could be used to specify the special cases)

Example: On my local PC I made corresponding changes in the Brouter and after some weeks of tests, I am now using the following filter and costs: Conditions (as implemented in StdPath.java):

• We have a jonction (nsection=0)
• The old way and the next way differ grantly ( using the standard priorityclassifiers I check weather the priorityclassifiers differ by more than 10)
• The turn angle is < 0
• A new parameter in the profile defining the cost for left-turn is > 0 (my value "151") If all conditions are sstisfied I add the defined left-turn-cost to the turn-costs!

In the above described use-case it works perfect (only "left-turn" is not longer indicated, on the right side no change).

regards Ess Bee

[polyscias]

Interesting experiment, this is one case, I wonder what kind of side-effects it will give running many routes.

Intuitively, depending on the traffic side in your country, the costs of a turn to the left or to the right should differ ... (see previous request #110) But simply adding costs in each turn-left situation do not really improve the routing

I am interested to see which route-anomalies pop-up with this. I think that the anomalies with this patch that limits the applicability, is a subset of the patch without limiting the applicability.

On the route, I am far from sure I would prefer the route via the round-about ;-)

[EssBee59]

Hello Polyscias, Thank for your interest! I tested the patch in the last 6 weeks (2,500 km fastbike!) some remarks: The benefit of the patch is very limited (5 "special" cases positiv found) I also discovered an anomalie: it was due to a "tertiary_link" but I could solve the case simply by changing the corresponding priority_classifier... Are you interested to test? If so, you should firts install a brouter-web on your PC. After that I could send you the patched "jar" of brouter (only on private basis) regards

[polyscias]

I do think I do not need to install brouter-web on my PC, I have QMapShack with BRouter integration and that is running the Brouter jar.

I also have a script to check a bicycle network for a big city, about 350 routes. I run that regularly after updating the .rd5 files and check if the routes did change more than a few meters, if so I have a look and often correct things in openstreetmap and sometimes in the urban profile I made myself that includes traffic lights.

Yes, I would like to give it a test on the route network to see what changes and if those changes make sense.

[EssBee59]

Hello Polyscias,

My profile is possibly not the best for biking in cities, it was developped for fastbike outside..

Anyway, your tests are very interesting.

Can you send me your „private“ Mail address to receive the jar confidentially ?

Regards

Ess bee

Von: polyscias [email protected] Gesendet: Dienstag, 26. Mai 2020 22:50 An: abrensch/brouter [email protected] Cc: EssBee59 [email protected]; Author [email protected] Betreff: Re: [abrensch/brouter] Costs for "turn-left" in special cases (#236)

I do think I do not need to install brouter-web on my PC, I have QMapShack with BRouter integration and that is running the Brouter jar.

I also have a script to check a bicycle network for a big city, about 350 routes. I run that regularly after updating the .rd5 files and check if the routes did change more than a few meters, if so I have a look and often correct things in openstreetmap and sometimes in the urban profile I made myself that includes traffic lights.

Yes, I would like to give it a test on the route network to see what changes and if those changes make sense.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/abrensch/brouter/issues/236#issuecomment-634271434 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AL75PSBWXFLDKO6SIDDJ3FLRTQTPTANCNFSM4MSGPL3Q .

[quaelnix]

@EssBee59, I just implemented your idea and the results are very promising even without taking the priorityclassifiers, roundabouts or oneways into account. We should definitely follow through with your proposal!

diff --git a/brouter-core/src/main/java/btools/router/StdPath.java b/brouter-core/src/main/java/btools/router/StdPath.java
index b890c27..733027e 100644
--- a/brouter-core/src/main/java/btools/router/StdPath.java
+++ b/brouter-core/src/main/java/btools/router/StdPath.java
@@ -44,6 +44,8 @@ final class StdPath extends OsmPath {
   protected double processWaySection(RoutingContext rc, double distance, double delta_h, double elevation, double angle, double cosangle, boolean isStartpoint, int nsection, int lastpriorityclassifier) {
     // calculate the costfactor inputs
     float turncostbase = rc.expctxWay.getTurncost();
+    float leftturncostbase = rc.expctxWay.getLeftTurncost();
+    float rightturncostbase = rc.expctxWay.getRightTurncost();
     float cfup = rc.expctxWay.getUphillCostfactor();
     float cfdown = rc.expctxWay.getDownhillCostfactor();
     float cf = rc.expctxWay.getCostfactor();
@@ -54,6 +56,9 @@ final class StdPath extends OsmPath {
 
     // penalty for turning angle
     int turncost = (int) ((1. - cosangle) * turncostbase + 0.2); // e.g. turncost=90 -> 90 degree = 90m penalty
+    if (nsection == 0) {
+      turncost += (int) ((1. - cosangle) * (angle < 0 ? leftturncostbase : rightturncostbase) + 0.2);
+    }
     if (message != null) {
       message.linkturncost += turncost;
       message.turnangle = (float) angle;

---context:way
assign is_main_road highway=primary|primary_link|secondary|secondary_link|tertiary|tertiary_link
assign rightturncost switch is_main_road 250 switch not highway=track|path|footway 25 2
assign leftturncost switch is_main_road 750 switch not highway=track|path|footway 125 10

Base profile: https://github.com/quaelnix/brouter-profiles/blob/main/gravel.brf

[EssBee59]

I just implemented your idea and the results are very promising ..

Hello, This was also my thought at the beginning, but not every idea becomes a success story! I tested with a prototype and my results was not longer promising such a succes story:

• it was extremly difficult to avoid uggly "side effects", I had to modify the behaviour with priorityclassifier...
• At the end, the benefit was very very limited...

That is why I prefer yet to work on other features (noise / river , etc.. as you know) Perhaps is your implementation much better, but I recommend to test intensively firts...

[quaelnix]

Part of the problem is that nsection == 0 is not equivalent of being at at junction. The reason why above code still works reasonably well is that (1. - cosangle) is usually close to zero in the cases where it is not a junction.

Replacing nsection == 0 with nsection == 0 && priorityclassifier != lastpriorityclassifier produces even better results and is basically free of ugly side effects. But it won't work on the current master branch due to a bug in the priorityclassifier initialization.

Perhaps is your implementation much better, but I recommend to test intensively firts...

I think a production-ready implementation of a turn cost feature that takes into account crossing oncoming traffic requires the introduction of a new pseudo-tag (during pre-processing) that tells us whether or not we are at an intersection.