Hi, I get some wrong/bad routing results when it comes to a starting onewayroad. Like it is on a crossing like this one: "^": the oneway road "-" & "|": the normal roads whithout oneway "+": the corner point of the roads ^ ^ ^ ^ ^ ^ +--------------- coming from here | | | | | | | | want to get routed to this direction. In this situation my Garmin Dakota 20 is routing me up the oneway part several roads around the block to get to the target just down the street. If you want to see the place at real OSM-Data, take a look to the Node 101581030 and the surrounding 3 roads. This happens to me with r1760 I used usally, but it happens with the newest r1908 as well. For the settings Iam using, you can look at the wiki for may litle personal generation skripts for the All-In-One Garmin Map. (http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map/Map_generation#A...) Markus
On Wed, Apr 06, 2011 at 08:37:37PM +0200, Markus Hetzmannseder wrote:
In this situation my Garmin Dakota 20 is routing me up the oneway part several roads around the block to get to the target just down the street.
Could it be that we are incorrectly merging the oneway street with the non-oneway street, making the non-oneway section oneway? What are the criteria for merging ways? I think that the merging should be blocked if any of the routing attributes differ: oneway, toll, mkgmap:unpaved, access/motorcar/bicycle/foot, etc. In http://www.openstreetmap.org/browse/node/101581030 the node is not part of a turn restriction relation. If it were, that would be a further reason not to merge the ways, I guess. Marko
I've tested it on a Dakota with similar road situations but I can't reproduce this routing error.
In this situation my Garmin Dakota 20 is routing me up the oneway part
several roads around the block to get to the target just down the street. Could it be that we are incorrectly merging the oneway street with the non-oneway street, making the non-oneway section oneway? What are the criteria for merging ways? I think that the merging should be blocked if any of the routing attributes differ: oneway, toll, mkgmap:unpaved, access/motorcar/bicycle/foot, etc.
In http://www.openstreetmap.org/browse/node/101581030 the node is not part of a turn restriction relation. If it were, that would be a further reason not to merge the ways, I guess.
Yes, that would be a possible explanation. But as far as I remember, merging takes place only for the graphical representation of lines in the different levels. The routing graph should be not affected by this. @Markus: Are there any signs, that the destination road is a oneway? Regards, Johann
I notice the road turning left (Kreuzstraße (11412195) that you want to be routed on), is tagged access:destination. Does this maybe mean that the router will only use it if it is your actual destination, or if there is no other means to reach your destination. Was your destination that immediate road, or would it have to have routed you through that road to your destination. (Was your destination the road itself or next to the road). How does the router interpret the access:destination tag? How does MkGMap interpret the access:destination tag? BennieD
On Thu, 7 Apr 2011, Johann Gail wrote:
@Markus: Are there any signs, that the destination road is a oneway?
The destination i want to get routed to is about at the point http://www.openstreetmap.org/browse/node/1079735170 So it is not a oneway. I was just right now by foot out at the place with the Garmin Dakota to reproduce it in a better way. The results are a bit strange. When iam at Neugasse and let it calc the way to the destination, when i can not reproduce the bad routing up the Kreuzstraße -> Rudolfstraße -> Rosenstraße. The bad routing happens when iam coming from more far out. The original route was over Rudolfstraße -> Rosenstraße. But when i drive down the Neugasse i get a rerouting and that is heading over Kreuzstraße -> Rudolfstraße -> Rosenstraße. So its looking now more like someing from the Dakota routing recalc and not so much from the mapgeneration itself. Is there any knowlege how a new calculated routing is different from a updating recalc of a route on that Garmin devices? Maybe the access=destination tag at that part of the city could be part of that routing troubles too ... Markus
@Markus: Are there any signs, that the destination road is a oneway?
The destination i want to get routed to is about at the point http://www.openstreetmap.org/browse/node/1079735170
So it is not a oneway.
I was just right now by foot out at the place with the Garmin Dakota to reproduce it in a better way. The results are a bit strange. When iam at Neugasse and let it calc the way to the destination, when i can not reproduce the bad routing up the Kreuzstraße -> Rudolfstraße -> Rosenstraße.
The bad routing happens when iam coming from more far out. The original route was over Rudolfstraße -> Rosenstraße. But when i drive down the Neugasse i get a rerouting and that is heading over Kreuzstraße -> Rudolfstraße -> Rosenstraße.
So its looking now more like someing from the Dakota routing recalc and not so much from the mapgeneration itself. Is there any knowlege how a new calculated routing is different from a updating recalc of a route on that Garmin devices? Maybe the access=destination tag at that part of the city could be part of that routing troubles too ...
I asume it a effect of the routing algorithm of the dakota. Your destination lies an a street with access=destination. If you come from far out, you are not in this area and have to enter a street with access=destination. If you start in Neugasse, you are already inside the destination area. So your routing has not to enter a destination area again and its okay to go through Kreuzstraße. Something like this...
participants (5)
-
Bennie du Plessis -
Johann Gail -
Marko Mäkelä -
Markus Hetzmannseder -
Minko