Route includes wrong types of ways
I have my nuvi configured to select fastest route for car/motorcycle. In the attached image, going from A to B it selected first a service way (first red circle) through a petrol station, then another service way instead of a two lanes residential one (second red circle) and finally some steps (third circle). Blue line shows the correct route it should have selected, obviously longer but I think better for a car. What is not working here? Regards Carlos
Hi Carlos,
I have my nuvi configured to select fastest route for car/motorcycle. In the attached image, going from A to B it selected first a service way (first red circle) through a petrol station, then another service way instead of a two lanes residential one (second red circle) and finally some steps (third circle). Blue line shows the correct route it should have selected, obviously longer but I think better for a car. What is not working here?
Please report the OSM tags for those ways it should not have chosen and also if you are using the default style file and, if not, what the rules are for those ways. Then we can work out what is going wrong. Thanks, Mark
Mark Burton escribió:
Hi Carlos,
I have my nuvi configured to select fastest route for car/motorcycle. In the attached image, going from A to B it selected first a service way (first red circle) through a petrol station, then another service way instead of a two lanes residential one (second red circle) and finally some steps (third circle). Blue line shows the correct route it should have selected, obviously longer but I think better for a car. What is not working here?
Please report the OSM tags for those ways it should not have chosen and also if you are using the default style file and, if not, what the rules are for those ways. Then we can work out what is going wrong.
Service ways: highway=service lanes=1 oneway=true/yes surface=paved steps: highway=steps layer=0 surface=paved width=4 I'm using the default style file Thanks as always for your interest Carlos
Hi Carlos,
Service ways: highway=service lanes=1 oneway=true/yes surface=paved
steps: highway=steps layer=0 surface=paved width=4
I'm using the default style file
The above looks OK.
Thanks as always for your interest
You're welcome. With my recent changes to the style files and the code fixes (r942), I believe it should avoid routing you via the steps! The service way has a low class/speed assigned to it so the gps really should try and use a better road (especially as it can't take a shortcut via the steps). Please test. Cheers, Mark
Mark Burton escribió:
Hi Carlos,
Service ways: highway=service lanes=1 oneway=true/yes surface=paved
steps: highway=steps layer=0 surface=paved width=4
I'm using the default style file
The above looks OK.
Thanks as always for your interest
You're welcome.
With my recent changes to the style files and the code fixes (r942), I believe it should avoid routing you via the steps!
The service way has a low class/speed assigned to it so the gps really should try and use a better road (especially as it can't take a shortcut via the steps).
Please test. Second service way and steps are not selected now, that's solved, but first service way (petrol station) is still selected. Right way is tagged as residential, with first part one lane and second part two lanes. Service way is 34.49 m long (only one crossing) and right way is 45.48 m (two crossings). Attached is an small osm file including the ways, so you can check better the matter. Regards Carlos
Hi Carlos,
Second service way and steps are not selected now, that's solved, but first service way (petrol station) is still selected. Right way is tagged as residential, with first part one lane and second part two lanes. Service way is 34.49 m long (only one crossing) and right way is 45.48 m (two crossings). Attached is an small osm file including the ways, so you can check better the matter.
I have been testing this using mapsource and I get the weirdest results. If I select a route that goes around the corner from Calle Obispo Jesús Domínguez to Calle Gil Cordero, mapsource calculates the time taken as 18 seconds or more. But if you break the route into segments, the sum of the individual times is just a couple of seconds. It looks like a bug in the time calculation in mapsource (I guess the gps does the same?) So, I will take another look at this sometime but at the moment I can't see anything wrong with the data. Cheers, Mark
Hi Carlos,
So, I will take another look at this sometime but at the moment I can't see anything wrong with the data.
What I have discovered is that there appears to be a time penalty for going around sharp junctions - in your example, if I add a node into Calle Obispo Jesús Domínguez S of the service road and move that node just a little bit to the E (which actually makes the route longer, but also reduces the angle at the junction), it will route that way, rather than using the service road. The angle at which the road meet appears to be what's controlling this. So, I am not sure that there is anything we can do in this situation. The only solution may be to tweak your data. Cheers, Mark
Mark Burton escribió:
Hi Carlos,
So, I will take another look at this sometime but at the moment I can't see anything wrong with the data.
What I have discovered is that there appears to be a time penalty for going around sharp junctions - in your example, if I add a node into Calle Obispo Jesús Domínguez S of the service road and move that node just a little bit to the E (which actually makes the route longer, but also reduces the angle at the junction), it will route that way, rather than using the service road. The angle at which the road meet appears to be what's controlling this.
So, I am not sure that there is anything we can do in this situation. The only solution may be to tweak your data.
OK. Thank you very much for your testing. Could this issue be related with instructions telling "keep right/left" instead of "exit right/left" when the angle of the exit way is quite sharp? Cheers Carlos
Hi Carlos, With the new patch (hopefully, committed before too long) you could add the "motorcar=destination" tag to your service way(s) and that should stop cars being routed through them. In fact, you could do that in your style file: highway=service {add motorcar=destination} [0x07 road_class=0 road_speed=1 resolution 22] Cheers, Mark
Carlos,
With the new patch (hopefully, committed before too long) you could add the "motorcar=destination" tag to your service way(s) and that should stop cars being routed through them.
Well, I was wrong. I don't know about a real gps but mapsource didn't pay any attention to me putting a motorcar=destination tag onto that service way. If you get a chance, please try the destination only routing patch on a real gps and see if it still wants to route through the service way. Cheers, Mark
Hi Carlos, Yet more investigation shows that adding access=destination only appears to be effective if the route to be avoided contains more than one way. So, in your example, tagging the service by the filling station with access=destination does no good. However, if you split the way at the kink on the LHS, the way will no longer be used even if the access=destination tag is not added because the extra junction is enough to make the way no longer favourable compared to going the route you wanted it to take! We got there in the end - just split the service and everything will be cool. Cheers, Mark
On Mar 4, 2009, at 00:05, Mark Burton wrote:
Yet more investigation shows that adding access=destination only appears to be effective if the route to be avoided contains more than one way. So, in your example, tagging the service by the filling station with access=destination does no good. However, if you split the way at the kink on the LHS, the way will no longer be used even if the access=destination tag is not added because the extra junction is enough to make the way no longer favourable compared to going the route you wanted it to take! We got there in the end - just split the service and everything will be cool.
This may well have to do with the destination class of that arc. It would currently be set to the class of the major road, since that's where it leads. It seems the way it is being computed is not always appropriate. Cheers Robert
Hi Robert,
This may well have to do with the destination class of that arc. It would currently be set to the class of the major road, since that's where it leads. It seems the way it is being computed is not always appropriate.
In this particular case, all of the roads are class 0 (service & residential). Making the residential roads class 1 should solve the problem (but it didn't, I just tried that and it seemed to make no difference). In general, perhaps the patch below is good (I have my doubts). Just guessing really. Another thing, I notice that addArc() in RouteNode doesn't pay any attention to the fact that the arc being added could be a reverse arc on a oneway road which will never be used for non-pedestrian traffic. In that case, it would be better not to increase the node's class to match the arc's class. Imagine a one way primary road reaching a junction of secondary roads, the class of the node should not be the primary road's class but the max of the secondary roads' class values. Cheers, Mark ------------------------------ diff --git a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java index 3a25e46..bca7b43 100644 --- a/src/uk/me/parabola/imgfmt/app/net/RouteArc.java +++ b/src/uk/me/parabola/imgfmt/app/net/RouteArc.java @@ -195,7 +195,12 @@ public class RouteArc { log.debug("writing arc at", offset, ", flagA=", Integer.toHexString(flagA)); // fetch destination class -- will have been set correctly by now - setDestinationClass(dest.getNodeClass()); + int nc = dest.getNodeClass(); + int rc = roadDef.getRoadClass(); + // don't use a higher class than this arc's class + if(nc > rc) + nc = rc; + setDestinationClass(nc); // determine how to write length and curve bit int[] lendat = encodeLength();
participants (4)
-
Carlos Dávila -
Johann Gail -
Mark Burton -
Robert Vollmert