I vote for some sort of simple approach that just warps the values when ever they change. Once we get the nearest station updating working, then we could do something slightly nicer by "interpolating" the old/new values over time so they change smoothly. Personally I think that interpolating data between stations is probably way over kill. Weather reporting is never that exact, and things could have changed since the last official reading, etc. etc. A simple interpolation scheme should be all we need and I think it would work great.
Here's my suggestion: forget about the internal environment manager (disable it, if possible) and for now, manage the weather entirely though an external daemon written in Perl, Python, Java, C, C++, PHP, or what-have-you. That makes it a lot easier for us to experiment with different approaches -- all the external daemon has to do is check the current lat/lon/alt every couple of seconds and update the /environment variables appropriately.
A really clever external manager could handle things like thermals and ridge lift for the soaring pilots, mountain waves for the mountain fliers, etc., using its own coarse-grained DEM data.
Once we have an external manager that we think is really, really good, we can recode it into C++ and embed it in FlightGear, but since the amount of network traffic is very small, there's no reason not to start out external.
All the best,
David
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
