OpenStreetMap
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.
토론
2017년 6월 23일 14:47에 Piskvor님의 의견
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”)?
2017년 6월 23일 19:35에 ff5722님의 의견
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.
2017년 6월 23일 20:10에 Piskvor님의 의견
Alas, I’m not looking for the Mapbox background layer, but for the “circles” overlay. That’s not a part of the tiles.
2017년 6월 23일 22:55에 aharvey님의 의견
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.
2017년 6월 25일 20:29에 robert님의 의견
Inspired!
2017년 6월 26일 08:45에 Franky63님의 의견
thank you!
2017년 6월 26일 09:06에 Piskvor님의 의견
@aharvey: Excellent, thank you!
2017년 6월 27일 10:20에 daniel-j-h님의 의견
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.
2017년 6월 30일 15:19에 Niels Elgaard Larsen님의 의견
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.
2017년 7월 3일 17:17에 b-jazz님의 의견
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.
2017년 7월 3일 19:20에 daniel-j-h님의 의견
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.
2017년 7월 9일 09:49에 gorn님의 의견
OK, you made my Sunday. Going to correct Czechia :)
2017년 7월 9일 10:03에 Piskvor님의 의견
Is there a way to map false positives (@gorn: e.g. the turn @ Bertramka is indeed legal, passable and used, despite the sharp angle)
2017년 7월 9일 11:28에 gorn님의 의견
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.
2017년 7월 9일 11:44에 gorn님의 의견
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
2017년 7월 9일 18:03에 daniel-j-h님의 의견
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:
osm.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.
2017년 7월 12일 08:45에 daniel-j-h님의 의견
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:
2017년 7월 22일 19:06에 b-jazz님의 의견
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.
2017년 8월 1일 23:50에 Niels Elgaard Larsen님의 의견
I would also like to see regular updates.
2017년 8월 12일 19:02에 daniel-j-h님의 의견
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.
2017년 8월 18일 15:12에 Niels Elgaard Larsen님의 의견
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.
2017년 8월 18일 23:02에 b-jazz님의 의견
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.
2017년 8월 19일 18:20에 Niels Elgaard Larsen님의 의견
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 osm.org/node/323277879 might be better as we could give it to josm.
When will you run the validation for Denmark again?
2017년 8월 20일 03:25에 b-jazz님의 의견
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.
2017년 8월 21일 07:15에 Hjart님의 의견
Am i to understand that 90 +/- 5 degree turns will not trigger your test? I’m looking at the “fix” at osm.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.
2017년 8월 22일 00:26에 b-jazz님의 의견
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.
2017년 9월 4일 04:09에 b-jazz님의 의견
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.
2018년 1월 17일 15:23에 Mateusz Konieczny님의 의견
osm.org/user/daniel-j-h/diary/41777#comment39306 “Up-to-date results can be found here:”
At least for me this map is blank.
2018년 2월 26일 03:03에 Jack the Ripper님의 의견
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
2018년 2월 26일 13:27에 daniel-j-h님의 의견
Thanks, I just added a note to the original diary post.