Hi Steve, If I got you right, you think that the patch is ok but the maps produced with the trunk version might contain completely wrong values. I have no idea how one can find out what's right or wrong. Probably a comparison between garmin map data and our results? Gerd Steve Ratcliffe wrote
Hi
okay, safety first. Maybe Steve can say more about how important the precision
It ultimately fits into a byte, so it is only accurate to about 1.5 degrees anyhow. I only saw a difference for the value 90 degrees when I tried WanMil's patch. But both are wrong in that they are only 179 degree apart instead of 180. Why not just reverse the integer value instead of suffering more rounding with floats?
However I am not convinced that the original code is correct in what it is doing.
If you have a road like this:
B .-------. C | \ | \ | \ | \ | * D | * A
where * are routing nodes, and . are plain nodes.
I thought that there were two directions, the initialHeading and the Bearing. The initialHeading was AB and the Bearing AD. (For the forward arc ABCD, for the reverse arc that would be DC and DA)
However the code has initialHeading and finalHeading of AB and CD if I am reading it correctly.
I could be wrong of course, since I only looked at the routing network very early on, and I'm not sure where this memory came from, since I never implemented the complex cases.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-Reduce-bearingTo-calculations-tp5533880... Sent from the Mkgmap Development mailing list archive at Nabble.com.