On 11 Jun 2009, at 09:52, Torsten Dreyer wrote: > Since this was a quite complex formula, nobody noticed. Now, it is > obvious > just by looking at the class names SGGeoc and SGGeod.
Another good reason for using SGGeoc and SGGeod, I think. > I will do some performance tests to see how much cpu power it costs > to convert > from SGGeoc to SGGeod before fetching ground elevation and I will > calculate > the error in the calculation of the slopes if the systems are mixed. > > Consequently one could ask, if spheric trigonometry is adequate for > short > distances up to 2000m (6500ft) or if it is acceptable that earth can > be > assumed to be flat for short distances. This could spare many cpu > cycles at > the price of small displacement of the probes. My guess is, for something like ridge lift, you could convert the input position(s) from geodetic to geocentric, along with any other input lon/lat values, and then do all your internal computations in geocentric. As you say, it's cheaper, and sufficiently accurate over the kind of distances you care about However, I also feel that many of the concerns about the performance of geodetic computations and conversions date from quite a few years ago. While I don't think we should be wasteful, and they are numerically heavy to work with, Mathias' helpers hide the complexity, and I would be surprised if the computations are more than noise on a profile run, compared to the FDMs, rendering and so on. I'd say use whichever is easiest, and cleanest, for you. James ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
