Norman Vine wrote: > Curtis L. Olson writes: > > Why don't we go ahead and commit one of these since both sound a lot > > better than what we have now. Then we could do some timing tests and > > see if we need to consider trading precision for faster performance. > > Note this will cause a 'shift' with respect to the current scenery > [...] > Not that this will really matter until one tries to patch in pieces of > newer scenery constructed with a 'slightly' different ellipsoid and > then there will be 'slivers' where the different sceneries join.
OK, I've checked my version in (not because I'm refusing the GEODETIC implmentation, but becuase it's already integrated). We can always back it out if something goes horribly wrong. Norman is right that we'll need to be careful about datum issues until the next terrain regeneration cycle. The terrain is stored using cartesian points, so nothing will (er, should) go wrong with existing data. But the converted geodetic points will be different by about a meter. So runway altitudes will be a tiny bit different, for example. New terrain tiles will need to be generated with the old datum to avoid cracks, and scenery objects might need to be adjusted a little when the terrain datum changes (we could write a little program to do this on the whole tree via a perl script or whatnot). But the error isn't very large. It's not like the old code was horribly wrong. On the surface, it disagreed by about a meter or so. Scenery buildings probably aren't placed that accurately anyway. I'll clean up and post my test code, so folks can look at the differences between the two implementations and try them for themselves. Andy _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
