Norman Vine wrote: > Yes, this was written before the 'standard' was adopted and we just > adopted it. > > I suggest that we use the attached geoc <-> geod transforms or a > massaged version of them to reflect what we want for an interface > > Note these are arguably 'the current standard' slightly modified by me > to just use WGS84 and to return the Earth radius at location
This one (geoc->geod, the reverse transform is easy, and essentially identical to mine) is about 4x faster than the one I wrote, with a symmetric error about 1000x worse (7mm after a double transform, instead of 6nm). I like (most of, see below) the code size, which is very small. I can't find that paper on the web, though, so unfortunately the algorithm is (literally, heh) greek to me. Do you have a pointer to a copy? The implementation worries me a bit, though. There's an elaborate dance that it does to try to special case the poles, which as far as I can tell is purely an attempt to avoid a divide by zero in the argument to atan(). (Pet peeve. That's what atan2() is for, ugh.) There is "error" checking for situations that shouldn't be errors (latitudes with magnitudes greater than 90� have an unambiguous interpretation and *can* occur in practice due to integer conversion issues, they aren't errors). Quite honestly, I like mine better. Mostly because I wrote it and understand it better, obviously, but also because of the accuracy. The performance difference is real but IMHO irrelevant, and a ~1cm error is *just* at the limit of what a gear collision implementation can tolerate. Stiff gear might have compression distances of only 10cm or so, which makes that spurious 7mm into a noticeable bump. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
