On Fri, 22 Feb 2002, David Megginson wrote: > > 2. conversion from raw form to a source independent format stored > > either in memory, or a persistent format > > Yes, if you mean METAR parsing and the like.
Yes, that's what I meant. > I'll probably isolate that behind a generic interface, so that we > can use different kinds of information providers. It will be in > the Environment/ subdirectory, but will really be a separate > package behind the same front-end. Is it safe to assume that if one wanted to add support for winds aloft reports, they would only need to add code to acquire the data and then parse it into some kind of data structure defined by your system? How much support will there be for data beyond that which is included in the METAR's? Winds aloft reports are one example of additional data sources that exist outside FG, but not all weather data would exist outside the application. It could be possible to have weather data generated from inside FG itself in the form of thermals or "ridge lift". (I use that term very loosely.) Would FGEnvironment be able to accept and manage data from these various sources? > > 3. logical analysis of the code to isolate relevant data > > I'm not sure what you mean by "code" here. Oops, I meant data, not code. > If you mean interpolation among weather station data points, then > yes, I'll have to support that. Will there be anything beyond basic interpolation? > Right now there's a tiny bit of rendering code in FGEnvironment, > left over from the old FGWeather class, but I want to remove that > completely. Good to hear! > I'm following the build-for-today rule from Extreme Programming: > I'll add support for (say) volumetric clouds when we can render > volumetric clouds. We *can* render cloud layers today, so I will > add support for that. I'd just hate to see a chicken/egg situation arise where someone willing to improve the cloud visuals is turned off because FGEnvironment doesn't provide the necessary data in a usable manner. While implementing volumetric clouds might not be feasible today, I don't think anyone would argue that it will be soon. Much sooner if one were to aim for "faked" volumetric clouds like those in FS2002 or FLY2. I don't think it would be a waste of time to put a little thought into what better looking clouds might require from FGEnvironment. It could have a significant effect on how FGEnvironment deals with the data. Thad _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
