[Flightgear-devel] Re: Airport Database Model
* Alex Perry -- Thursday 10 October 2002 20:10: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. But then you couldn't teleport to arbitrary airports, n'est ce que pas? Storing the airport data in some precompiled form may be necessary, but having to cvs-up the whole, still quite big binary file after single-line changes in the database is no fun either. What about storing the data in a gzipped XML file and reading-in a small, uncompressed XML file afterwards, that is able to override some of the data in the big file. So little changes and additions could be made to the small patch file, which would only be merged into the big database once in a while. (Once every year? Every release?) ... I'm just thinking of people with slow dial-up connections, like me ... :-] m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Airport Database Model
Alex Perry writes: * Alex Perry -- Thursday 10 October 2002 20:10: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. But then you couldn't teleport to arbitrary airports, n'est ce que pas? Oh, sorry, let me elaborate ... 1. I'm assuming we keep the airport database (but maybe omit runways etc) Then someone will want to teleport to a specific runway at a specific airport. :-) 2. Given an airport ID, FGFS must priority load the relevant file above 3. The remaining files (between zero and about 300) are defer loaded 4. When the scenery loader thread has no tiles to do, it does one file 5. Thus, we can put huge amounts of information into each airport record I think it's reasonable to consider saving the same data in more than one form in order to suit different needs of different sections of the code. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Airport Database Model
1. I'm assuming we keep the airport database (but maybe omit runways etc) Then someone will want to teleport to a specific runway at a specific airport. :-) Yeah, but the runway-based user request is precisely why I stated that the file is priority loaded ... so we get the runway position details. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
