Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing Routing Info in viaroute Service #1615

Closed
programmer-art opened this issue Aug 19, 2015 · 9 comments
Closed

Missing Routing Info in viaroute Service #1615

programmer-art opened this issue Aug 19, 2015 · 9 comments

Comments

@programmer-art
Copy link

Hi there.

An important route information is the U-turn on a main street where you get the information that at some distance, there is a turn possibility if you missed a previous exit. In OSRM, this information is missing.

pic1

As you can see in the image, the route is showing only that it is going straight ahead and does not show the U-turn as a U-turn.

If I test against graphhopper, it shows some more info and it also shows another turning point.

pic2

On the other hand, forcing GraphHopper taking the same turning point, it is also missing the turning information. Is this an algorithm problem or an OSM problem?

pic1

As a reference, I tested using Google Maps. Again, the same route and it is showing everything very nicely and correctly.

google

In the first image, you can see two things:

  1. There the routing information contains a U-turn direction information at "Maximilianstraße"
  2. It routes the same way graphhopper does.

If changing the destination marker to across "Maximilianstraße" to also force Google Maps to choose the small turning point, it also shows it correctly like in the following image.

google2

Is there any way you can provide the same turning information as Google Maps does in you viaroute service of OSRM backend?

Thanks a lot.

@programmer-art programmer-art changed the title Missing Routing Info and Exposing more Infos Missing Routing Info in viaroute Service Aug 20, 2015
@TheMarex
Copy link
Member

The problem here is that the U-Turn is executed via a connecting street - to OSRM it looks like you are following a street. These short segments would need to be marked in the pre-processing as intersection edges and handled in the turn instruction generation accordingly.

Sadly this is not easily doable. This might get added with the revamp of turn instruction generations, which is still off some time.

@programmer-art
Copy link
Author

So then there are two problems:

  1. The small street connections are not considered.Allow me to post the next image just as a little reminder:

osrm

  1. Your algorithm does not take the big crossing at "Maximilianstraße" where as Graphhopper and Google Maps are considering it. Any idea on that? Showing the same image as the one on the very top:

pic1

Best regards

@TheMarex
Copy link
Member

@programmer-art There is a turn restriction at the intersection, specifically prohibiting the turn. Is that turn restriction correct? Graphhopper also uses OSM data, but can't handle turn restrictions.

@programmer-art
Copy link
Author

@TheMarex Ok, that explains why the crossing is not considered. Unfortunately, I can not tell you if there is a turn restriction in reality, because I do not take that route...

@lbud
Copy link
Member

lbud commented Sep 1, 2015

@TheMarex interestingly though, it looks like that restriction only restricts turns from Maximilianstraße (the east-west way) onto Thomas-Wimmer-Ring (N-S way), which isn't necessarily indicative of a no-U-turn rule from Thomas-Wimmer-Ring around the median onto itself — there is no restriction from Thomas-Wimmer-Ring onto Maximilianstraße. So could this be an OSRM error? (Then again I'm no expert at German traffic laws :p )

@TheMarex
Copy link
Member

TheMarex commented Sep 1, 2015

@lbud looks like you would need to merge on Maximillianstraße first, before you can could turn left again. But it is impossible to tell without seeing the road markings (but U-Turn lanes are not that common at German intersections). So technically this would not even be considered a U-Turn, more like turning left twice.

@danpat
Copy link
Member

danpat commented Aug 26, 2016

OSRM v5 has improved guidance for this:

screen shot 2016-08-25 at 10 56 52 pm

http://map.project-osrm.org/?z=18&center=48.136992%2C11.582076&loc=48.137146%2C11.584353&loc=48.137125%2C11.584139&hl=en&alt=0

The turn restriction still applies.

Street-level imagery for this intersection is here:
https://www.mapillary.com/app/?lat=48.13858454&lng=11.58475153&z=17&pKey=VyqknG2C52_RA6QH-VKdkg&focus=photo

@TheMarex based on that imagery, I'd say the route we're returning is correct. In Germany, is it correct that u-turns are generally not permitted except where explicitly allowed?

If so, then I think this ticket can be closed.

@daniel-j-h
Copy link
Member

@TheMarex based on that imagery, I'd say the route we're returning is correct. In Germany, is it correct that u-turns are generally not permitted except where explicitly allowed?

No it's the other way around in germany: uturns are allowed by default in everywhere you can make a left turn, except there is a explicit no-uturn sign:

http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Hinweis_zur_Beschilderung

@MoKob
Copy link

MoKob commented Aug 31, 2016

From looking at the data, the turn-restrictions currently give exactly what we find in the route.
If the u-turn should be allowed, it is a modelling error in OSM, since currently all left turns (including the u-turn as a result) are forbidden from "Maximilianstraße". If the turn is only forbidden when coming from "Maximilianstraße" as well, then this needs to be a restriction using a via way, not a via node.

Thile our support for via-way restrictions is not working yet (#2681), the way it is handled currently is correct with respect to the graph model. I suspect other reasons for why graph-hopper is showing the turn (most likely ignoring the restriction).

Closing here since not actually actionable for us, apart from #2681.

@MoKob MoKob closed this as completed Aug 31, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants