[PATCH] fix for "pink line of death" bug in routing
Howdy Folks, The attached patch appears to fix the wild zooming away and back again problem we have been seeing in the routing. Please test. My etrex will now route without big zig-zag lines. The interesting question is: why didn't it show up in mapsource? Cheers, Mark
Damn and blast it. Although this patch helped for "small routes" (say < 20km), when I tried a much longer route (90km or so) it went wrong near the end. So back to the drawing board, but at least that's part of the problem sorted if not the whole problem. Just noticed, what's really interesting is that if you zoom out sufficiently, the bad line goes away. At the 8km zoom level the line goes wacky, at 12km, it doesn't.
On Feb 8, 2009, at 00:48, Mark Burton wrote:
Although this patch helped for "small routes" (say < 20km), when I tried a much longer route (90km or so) it went wrong near the end.
So back to the drawing board, but at least that's part of the problem sorted if not the whole problem.
But let's look for related problems. In particular, are the signs of offsets encoded correctly? Negative offsets might explain why occasionally, the route goes off in the opposite direction. Cheers Robert
Hi Robert,
Although this patch helped for "small routes" (say < 20km), when I tried a much longer route (90km or so) it went wrong near the end.
So back to the drawing board, but at least that's part of the problem sorted if not the whole problem.
But let's look for related problems. In particular, are the signs of offsets encoded correctly? Negative offsets might explain why occasionally, the route goes off in the opposite direction.
Actually, I think the fix really did solve the major problem. Further investigation shows that the badness I am seeing with my "longer route" is related to the number of nodes in a particular way. If I limit the number of nodes to no more than 16, the routing works without going wacky. If I have some larger number of nodes (actual limit TBD but more than 16), the gps gets it wrong - it actually looked like it routed to the far end of the way rather than the near end. So, if you use the patch from yesterday and limit the number of nodes in a way, it's looking pretty good (for the moment!) Cheers, Mark
I played around with the splitting long roads function of osm2mp. By default roads got cut after 60 nodes. If I change this to about 30 nodes the "go the motorway the wrong way and take the plane" problem seams to disappear. Just search for the line "$rnod == 60" in osm2mp.pl ... Berni.
If I limit the number of nodes to no more than 16, the routing works without going wacky. If I have some larger number of nodes (actual limit TBD but more than 16), the gps gets it wrong - it actually looked like it routed to the far end of the way rather than the near end.
So, if you use the patch from yesterday and limit the number of nodes in a way, it's looking pretty good (for the moment!)
r865 works for me. Just thought I'd let you know. All of the pink lines of death around where I work have now disappeared. As suggested below I have set $rnod to 30 in osm2mp.pl Thanks for the patch Paul Mark Burton wrote:
Hi Robert,
Although this patch helped for "small routes" (say < 20km), when I tried a much longer route (90km or so) it went wrong near the end.
So back to the drawing board, but at least that's part of the problem sorted if not the whole problem. But let's look for related problems. In particular, are the signs of offsets encoded correctly? Negative offsets might explain why occasionally, the route goes off in the opposite direction.
Actually, I think the fix really did solve the major problem.
Further investigation shows that the badness I am seeing with my "longer route" is related to the number of nodes in a particular way.
If I limit the number of nodes to no more than 16, the routing works without going wacky. If I have some larger number of nodes (actual limit TBD but more than 16), the gps gets it wrong - it actually looked like it routed to the far end of the way rather than the near end.
So, if you use the patch from yesterday and limit the number of nodes in a way, it's looking pretty good (for the moment!)
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Paul,
r865 works for me. Just thought I'd let you know.
All of the pink lines of death around where I work have now disappeared.
That's great.
As suggested below I have set $rnod to 30 in osm2mp.pl
I have now determined the max number of nodes in a way that I can have before a particular route on a particular map goes wrong on an etrex vista. The max number is 18. So, while 30 may work in other situations, it won't work for all maps/routes/gps's. I don't believe there is a huge cost in space/speed if you break a way into segments that have fewer routing nodes. After all, a large proportion of the roads in the map will only have a few routing nodes anyway, so partitioning a relatively small number of roads into segments should have little impact on resource usage. Cheers, Mark
Mark Burton escribió:
Hi Paul,
r865 works for me. Just thought I'd let you know.
All of the pink lines of death around where I work have now disappeared.
That's great.
As suggested below I have set $rnod to 30 in osm2mp.pl
I have now determined the max number of nodes in a way that I can have before a particular route on a particular map goes wrong on an etrex vista. The max number is 18. So, while 30 may work in other situations, it won't work for all maps/routes/gps's.
I can confirm that while with rnod=30 I still had some lines of death, they seem to have disappeared reducing it to 18. Thanks for the point. Carlos
I don't believe there is a huge cost in space/speed if you break a way into segments that have fewer routing nodes. After all, a large proportion of the roads in the map will only have a few routing nodes anyway, so partitioning a relatively small number of roads into segments should have little impact on resource usage.
Cheers,
Mark
I have now determined the max number of nodes in a way that I can have before a particular route on a particular map goes wrong on an etrex vista. The max number is 18. So, while 30 may work in other situations, it won't work for all maps/routes/gps's.
I've seen maps with over 40 routing nodes and although I don't know for sure that they didn't have the problem, I suspect that there is another bug or something that is not quite understood. ..Steve
Although this patch helped for "small routes" (say < 20km), when I tried a much longer route (90km or so) it went wrong near the end.
So back to the drawing board, but at least that's part of the problem sorted if not the whole problem.
But let's look for related problems. In particular, are the signs of offsets encoded correctly? Negative offsets might explain why occasionally, the route goes off in the opposite direction.
Actually, I think the fix really did solve the major problem.
Further investigation shows that the badness I am seeing with my "longer route" is related to the number of nodes in a particular way.
If I limit the number of nodes to no more than 16, the routing works without going wacky. If I have some larger number of nodes (actual limit TBD but more than 16), the gps gets it wrong - it actually looked like it routed to the far end of the way rather than the near end.
So, if you use the patch from yesterday and limit the number of nodes in a way, it's looking pretty good (for the moment!)
May that have something to do with the faulty loop at generating the bits (r892)? Has anyone an test case at hand, where he can try again with longer segments? While playing around with the bits I accendentially compiled a version in which all bits was cleared. In this case the pink line goes wacky from the first node.
On Feb 7, 2009, at 23:14, Mark Burton wrote:
The attached patch appears to fix the wild zooming away and back again problem we have been seeing in the routing. Please test.
[patch switching lat/lon offsets to correct order for large offsets] Thanks Mark, that's great! A simple bug! I was hunting for some error in our understanding of the format... For reference, these offsets store the coordinates of the routing nodes, and big offsets show up in large (bounding-box wise) route centers, which may show up if these route centers contain long roads.
The interesting question is: why didn't it show up in mapsource?
We're writing some redundant data -- for instance, the routing nodes' coordinates also occur as coordinates in the corresponding polyline. Mapsource may well route along the routing graph in NOD, but only draw using the TRE/RGN data, while the GPS receivers handle this differently. Cheers Robert
participants (7)
-
Bernhard Heibler -
Carlos Dávila -
Johann Gail -
Mark Burton -
Paul -
Robert Vollmert -
Steve Ratcliffe