GIScience / GIScience/openrouteservice
ORS driving directions take wrong off-ramps when OSM has no turn restrictions
- Dominant language
- Java
- Stars
- 2k
- Forks
- 481
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 45
Description
First off - thanks for this project!
#### Here's what I did
Requested directions from 46.433539,-81.035328 to 46.450351,-81.003549
https://maps.openrouteservice.org/directions?n1=46.430404&n2=-80.991662&n3=15&a=46.433539,-81.035328,46.450351,-81.003549&b=0&c=0&k1=en-US&k2=km
See also discussion in https://www.openstreetmap.org/note/1711523 and https://www.openstreetmap.org/changeset/68216922
---
#### Here's what I got
OpenRouteService recommends a very sharp left onto a roadway which is the off-ramp for traffic travelling in opposite direction.
(As of time of bug report, this is not entered as a turn restriction in OpenStreetMap. It is likely not signed. I will add it as an implicit restriction, but it seems worth it to handle cases like this.)

ors-export-linestring.json is:
{"elevation":true,"summary":{"distance":5312.4,"duration":301.8,"ascent":31.4,"descent":42.5},"geometry_format":"geojson","geometry":[[46.433554,-81.035314,278],[46.433503,-81.035202,277],[46.43329,-81.03446,275.8],[46.432856,-81.033016,276.6],[46.432468,-81.030673,280.9],[46.432238,-81.02846,280.7],[46.432166,-81.02672,275.5],[46.432223,-81.024967,271],[46.43241,-81.0234,271.5],[46.432597,-81.022034,273.7],[46.432779,-81.021145,275.5],[46.433104,-81.019496,277.3],[46.433374,-81.01824,277],[46.433674,-81.016111,275.9],[46.433725,-81.015076,277.1],[46.433716,-81.013908,278.7],[46.433632,-81.012968,279.4],[46.433503,-81.012131,279.5],[46.433308,-81.011206,281.1],[46.433027,-81.0103,283.9],[46.432548,-81.00886,284.4],[46.432364,-81.008306,282.7],[46.432247,-81.007954,281.8],[46.43156,-81.005836,277.5],[46.430032,-81.001198,277],[46.431424,-81.005051,276.3],[46.431727,-81.005802,276.5],[46.432045,-81.006456,277],[46.432459,-81.006982,277.4],[46.432881,-81.007282,277.8],[46.43331,-81.007443,278.1],[46.433864,-81.007486,278.7],[46.434372,-81.007425,279.8],[46.435193,-81.007179,279.4],[46.435993,-81.006907,275.4],[46.436727,-81.006761,271.1],[46.439577,-81.005731,268.7],[46.440949,-81.005532,270.2],[46.441497,-81.005421,271.1],[46.442075,-81.005468,271.7],[46.442157,-81.005474,271.8],[46.443278,-81.005747,271],[46.443744,-81.005833,270.3],[46.44414,-81.005906,270.1],[46.444787,-81.005934,271.5],[46.445405,-81.005848,273.7],[46.446154,-81.005481,275],[46.447183,-81.005053,272.9],[46.44866,-81.004439,270.2],[46.450361,-81.003591,266.9]],"segments":[{"distance":5312.4,"duration":301.8,"ascent":31.4,"descent":42.5,"detourfactor":1.73,"percentage":100,"steps":[{"distance":2746.2,"duration":123.6,"type":11,"instruction":"Head southeast on Southwest By-Pass, 17","name":"Southwest By-Pass, 17","way_points":[0,24],"distanceTurf":2746.9,"$$hashKey":"object:1055"},{"distance":2566.2,"duration":178.3,"type":2,"instruction":"Turn sharp left","name":"","way_points":[24,49],"distanceTurf":2567,"$$hashKey":"object:1056"},{"distance":0,"duration":0,"type":10,"instruction":"Arrive at your destination, on the right","name":"","way_points":[49,49],"$$hashKey":"object:1057"}],"$$hashKey":"object:1035"}],"way_points":[0,49],"bbox":[-81.035314,46.430032,-81.001198,46.450361]}
---
#### Here's what I was expecting
I would expect to take the right-hand turn onto looping offramp, even without a turn restriction in OSM.
---
#### Here's what I think could be improved
Give a scoring penalty for very sharp left turns, in particular onto one-way ways.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by replaying the directions request in the issue and comparing the result with ors-export-linestring.json, focusing on the sharp-left step onto the opposing off-ramp. Review the linked OpenStreetMap note and changeset for the road context; done means the route prefers the looping offramp or otherwise avoids the unsafe sharp-left choice when no turn restriction is present.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100