OpenStreetMap
Sharp Turns onto Ramps
Posted by daniel-j-h on 23 June 2017 in English. Last updated on 26 February 2018.Here’s a map I got out of our Open Source Routing Machine when I built a validator for sharp turns onto ramps. The idea behind this validator is that turns onto highway ramps should never be sharp (i.e. < 90’ish degree). There is a high chance a turn restriction is missing at those locations.
With these checks enabled I found roughly 30k intersections on the planet. I visualized the results in the map below; the redder the circle, the sharper the turn angle onto the ramp.
In the results I found an issue that frequently re-occurred. Consider the situation below: heading east on Goff Mountain Road (the yellow line), there is a ramp on the right that you can legally take. Around the bend, there is another ramp onto the same road for drivers going west on Goff Mountain Road.
If you are driving east on Goff Mountain Road and happen to miss the ramp, re-routing will kick in. When generating a new route past the ramp that you initially missed, OSRM sees in the road network that there is conveniently a second ramp onto the same road. It then basically gives you the instruction to make a nearly 180 degree turn on the the next ramp! A turn restriction onto that second ramp from Goff Mountain Road would fix this issue.
Given that the navigation is able to pass in your bearings data (what cardinal direction you’re already moving in) to OSRM, OSRM won’t try and tell you to make a fast u-turn and try the first ramp again like in the third frame of the gif. Making a turn onto the second ramp isn’t considered problematic though.
There are definitely false positives in the data and cases you will never hit in reality. But there are also missing turn restrictions onto ramps that will result in bizarre instructions given back to re-routing requests.
As usual check Mapillary and OpenStreetCam imagery before making changes. Especially look out for old satellite imagery.
Even though the sharp-turns-onto-ramps validator was just a quick evening hack it would be great to add more static road network property validators that detect situations like u-turns on high-speed roads or sudden changes in road class.
Discussion
Comment from Piskvor on 23 June 2017 at 14:47
Excellent, excellent! Looking at my area, I see some sharp turns highlighted; is there a way to get to them from your map (other than “open up the same area in JOSM and look for cues”)?
Comment from ff5722 on 23 June 2017 at 19:35
If you could give the WMTS link from the Mapbox style it can be used as a background layer in JOSM (for iD, Leaflet works). Then it’s easy to download that area from OSM right away.
Comment from Piskvor on 23 June 2017 at 20:10
Alas, I’m not looking for the Mapbox background layer, but for the “circles” overlay. That’s not a part of the tiles.
Comment from aharvey on 23 June 2017 at 22:55
It’s all part of the same style (circles included) just add the style WMTS URL like this into JOSM as a WMTS layer.
https://api.mapbox.com/styles/v1/danieljh/cj42l3yw05epa2sqvellka881/wmts?access_token=pk.eyJ1IjoiZGFuaWVsamgiLCJhIjoiTnNYb25JSSJ9.vYOnsuu1zeKcGW2nj0uJZw
If you ONLY want the circle and not the basemap as well, you would need to create your own Mapbox style from that style but remove all layers except the circles.
Comment from robert on 25 June 2017 at 20:29
Inspired!
Comment from Franky63 on 26 June 2017 at 08:45
thank you!
Comment from Piskvor on 26 June 2017 at 09:06
@aharvey: Excellent, thank you!
Comment from daniel-j-h on 27 June 2017 at 10:20
You can also find the raw GeoJSON for the initial run on the planet in this ticket:
https://github.com/Project-OSRM/osrm-backend/pull/4160#issuecomment-309253836
it will probably change with time when refining the check and adding more features to it.
Comment from Niels Elgaard Larsen on 30 June 2017 at 15:19
Great job.
When will you run it again and update the map?
I believe we fix most of the issues in Denmark, and it would be interesting to see if the rest are false positives or problems with the mapping.
I do think there is a few false positives for motorway_links that are not one-way.
Comment from b-jazz on 3 July 2017 at 17:17
This is fantastic. Thanks for the great analysis that will help serve to make OSM better and better. I’ve been cleaning up some of the ones in my area.
It would be great if there were a way to tag false positives so they won’t continue to be tagged in the future.
Comment from daniel-j-h on 3 July 2017 at 19:20
I will run the same validation handler and a new one on the planet tomorrow or the day after and will post back with new GeoJSON data and a map.
It would be great to find false positive categories. For example some of the locations I samples had a stop sign missing and were actual legal turns.
If there are false positives which we can detect from the OpenSTreetMap data I’m more than happy to implement this in OSRM.
Comment from gorn on 9 July 2017 at 09:49
OK, you made my Sunday. Going to correct Czechia :)
Comment from Piskvor on 9 July 2017 at 10:03
Is there a way to map false positives (@gorn: e.g. the turn @ Bertramka is indeed legal, passable and used, despite the sharp angle)
Comment from gorn on 9 July 2017 at 11:28
I started to map Czechia and found these false positives at first
But than I started to see that most of the places in Czechia (and I think this is valid for most of Europe at least for the Countries I visited) will be FALSE positives by principal. Most of the “regular” junctions with motorway (not counting the big complex ones) will look like this
https://api.mapbox.com/styles/v1/danieljh/cj42l3yw05epa2sqvellka881.html?access_token=pk.eyJ1IjoiZGFuaWVsamgiLCJhIjoiTnNYb25JSSJ9.vYOnsuu1zeKcGW2nj0uJZw#16.9/49.72333/13.356
Where there is NO place for your scenario. Even thought the turn to motorway link might be < 90 deg for one of the directions (it will be unless is it exactly 90). There is no reason to think it is a mistake. You should at least check the onway tag.
More sophisticated applrpoach would be to to detect if the are TWO options how to get on the motoway - if there is only one, it is highely probable that it will be accessible from both directions unless the angle is really small.
Comment from gorn on 9 July 2017 at 11:44
Please not that still I did some nice mapping based on your data, so thanks a lot and I wonder if you will be able to correct the problem, because I see similar navigational problems every since and than and it is nice to see some systematic approach to them.
BTW there is another typical junction (used more for smaller roads) with no space for you scenario
https://api.mapbox.com/styles/v1/danieljh/cj42l3yw05epa2sqvellka881.html?access_token=pk.eyJ1IjoiZGFuaWVsamgiLCJhIjoiTnNYb25JSSJ9.vYOnsuu1zeKcGW2nj0uJZw#16.26/50.52168/13.54504
Comment from daniel-j-h on 9 July 2017 at 18:03
We do check the oneway tag - not even that but we check hopefully most if not all routing related tags; if you find a tag missing please open an issue in
https://github.com/Project-OSRM/osrm-backend/issues.
The location you pointed out is problematic mostly because of this turn:
http://map.project-osrm.org/?z=18¢er=49.723316%2C13.355816&loc=49.723387%2C13.356231&loc=49.723484%2C13.355427&hl=en&alt=0
If you have a look at how the intersection is modeled in OpenStreetMap:
https://www.openstreetmap.org/edit?way=139088393#map=19/49.72327/13.35573
and now compare it to reality by looking at the satellite imagery.
In this case all the routing engine sees from the data is a sharp turn onto a ramp; that the intersection here should be modeled out more detailed is something the routing engine can not tell.
Comment from daniel-j-h on 12 July 2017 at 08:45
We refined some checks and added new ones for sharp turns (e.g. sharp turns from one ramp onto another). Here are up-to-date results for the planet:
https://api.mapbox.com/styles/v1/danieljh/cj4zptszf0xgl2srvbsseiwjw.html?access_token=pk.eyJ1IjoiZGFuaWVsamgiLCJhIjoiTnNYb25JSSJ9.vYOnsuu1zeKcGW2nj0uJZw#6.22/51.134/11.663
Colored as follows:
Comment from b-jazz on 22 July 2017 at 19:06
Are there plans to update this on a regular basis. I try to poke around a clean up a few of the sharp turns when I have some time on my hands, but it is getting to the point where I run into ones that I’ve already updated, but they are still on the map. I’d love to see daily updates if it isn’t too difficult.
I’m also curious at how things have changed with the map since you first started the project. There were ~30,000 at the start. I’m guessing the number has dropped since then (partly due to re-jiggering the methodology and partly due to people cleaning the data). But it would still be interesting to see how effective your project has been.
Comment from Niels Elgaard Larsen on 1 August 2017 at 23:50
I would also like to see regular updates.
Comment from daniel-j-h on 12 August 2017 at 19:02
Up-to-date results can be found here:
We still don’t have regular updates or statistics mostly because I’m doing this every now and then on the side when there’s time for it and we still don’t have all checks we want to have in place. If someone wants to help out here I’m happy to get you started.
Trying something new this time: showing a line string for the from and to segment. It’s the routing engine’s normalized graph in the background so the linestring does not follow the way geometry. Hope that still helps to figure out the turn more easily.
You can follow the discussion in the routing engine’s ticket here.
Comment from Niels Elgaard Larsen on 18 August 2017 at 15:12
The lines are a big help. An arrow would be even nicer. Or maybe make the second leg a different color than the first leg.
I believe that Denmark is now mostly fixed. The sharp turns that are left is where it is possible to make U-turns on roads that have been split up in one-way lanes.
Comment from b-jazz on 18 August 2017 at 23:02
I’ve been playing around with osrm-extract on daniel-j-h’s sharp turns validation branch and parsing the input and making maps. I don’t have the compute horsepower to run the whole planet, so I’m looking at smaller countries in the meantime while I work on alternative ways to process chunks of the planet at a time.
Here is an example map that I’ve generated of Denmark. I’ve kept the lines that daniel-j-h had and I’ve added a starting node marker (‘s’) so that you can see the direction through the node that is the problem. I’ve also included a URL to edit the problem node when you click on the marker so that you can easily start editing. (Note: the marker is for the first point, but the actual URL is to edit the second/middle point that has the sharp turn associated with it.) I spent far too many hours zooming in on one map and then zooming the editor/iD map trying to find the node in question. This should be a lot easier.
https://gist.github.com/b-jazz/ec5003c0745270e9eb8994f6957107cf
If you see problems with how I’ve generated the map, please leave a comment here or contact me directly. If you have some small (country-level) maps that you’d like me to process in the short term, let me know.
Comment from Niels Elgaard Larsen on 19 August 2017 at 18:20
Great work.
The urls do not work for me, I see the href value. But it is easy enough to paste it into a browser. Actually a normal url like https://www.openstreetmap.org/node/323277879 might be better as we could give it to josm.
When will you run the validation for Denmark again?
Comment from b-jazz on 20 August 2017 at 03:25
Sorry, yes, I should have mentioned that the URLs aren’t active and clickable. I’m not sure if that is possible with the geojson rendering that github/leaflet/mapbox does. If someone knows the trick, please let me know. I gave up after a bit of searching, and like you noted, at least you can copy/paste the URL.
I went ahead and changed the URLs to be “…/node/323277879” instead of “…/edit?node=323277879”. I prefer those as well.
I’ve started a new github repo for the maps that I generate:
https://github.com/b-jazz/sharp-turns-onto-ramps
When you wrote your comment, the Denmark map was 23 hours hold, so I came back later to make sure I have the latest greatest. You’ll now see (if I remember) the date of the map in the github comment.
I’ve also implemented a rudimentary “exceptions” file in that repo that can be updated with node IDs to ignore the next time I run my map generating script. Feel free to edit and submit a pull request.
As always, let me know if you have any problems/questions.
Comment from Hjart on 21 August 2017 at 07:15
Am i to understand that 90 +/- 5 degree turns will not trigger your test? I’m looking at the “fix” at https://www.openstreetmap.org/#map=19/55.40320/8.72897, which I consider both unnecessary and downright ugly. I’ve been looking at number of similar “solutions” around Denmark (by the same mapper) and when I look at stuff like that I feel quite tempted to just plain revert it. I think it should be fixed by either putting it in the exceptions file mentioned in https://github.com/b-jazz/sharp-turns-onto-ramps or possibly make sure the segment connecting to Darumvej is 90 degrees.
Comment from b-jazz on 22 August 2017 at 00:26
I believe that turns of 1-80 degrees, not 85, get called out. At least that’s what I see empirically looking at the results (it’s not my code, I’m just messing with turning the raw data into maps). And I agree with Hjart that the example map should be left alone and added to the exception list instead of twisting things around to make it not get triggered by this particular validation. That is likely an unintended consequence of the validation. If there is a physical triangular island or painted lines, I would do something like the above, but typically I leave these alone and add them to the exception list.
Comment from b-jazz on 4 September 2017 at 04:09
I have some scripts cobbled together to pull down different regions and process them individually and upload maps to github on roughly a weekly basis. The repo (mentioned above) is: https://github.com/b-jazz/sharp-turns-onto-ramps
My count of worldwide nodes that were called out as of 2017-09-03 is 235,846.
I was thinking of setting up regional map roulette challenges to see if we can get some movement on reducing that number. I’ve never messed with maproulette.org before, but it doesn’t seem too hard to do. Would that be a good idea? If anyone reading this has thoughts, I’m open to hear them.
Comment from Mateusz Konieczny on 17 January 2018 at 15:23
https://www.openstreetmap.org/user/daniel-j-h/diary/41777#comment39306 “Up-to-date results can be found here:”
At least for me this map is blank.
Comment from Jack the Ripper on 26 February 2018 at 03:03
Hi Daniel,
This is a great idea, and should help improve routing greatly. However, I would like to ask that you specifically include a mention to check Mapillary and OpenStreetCam imagery before making changes. I just reverted some changesets that someone made while using your instructions, because unfortunately, the editor relied on outdated satellite imagery, and so converted the new diverging diamond interchange into the old straight-road version.
–jack
Comment from daniel-j-h on 26 February 2018 at 13:27
Thanks, I just added a note to the original diary post.