On Tue, 14 Oct 2003, David Luff wrote: > Agree whole-heartedly with this. Things like frequency lookup can then > have a nice world-map downwards clickable interface.
Yes, it's a small addition, with obvious benefits. > I think we have to be very careful about how much data we store globally. > FG has a pretty large memory footprint - I've just fired a non-debug > version up and it clocks 360Meg of RAM. Really, only airports and > frequencies must be stored in memory ready for use, since that is what we > look up by. We could load runways on demand when the airport is known. > The disadvantage being that the runways come prepackaged in the current > format. Splitting the info only required at scenery generation time out into a seperate file has to be a good thing - as you say, the footprint of flightgear is growing - its pointless holding redundant data in RAM. > I propose adding an xml facilities file for each airport with custom data > that isn't needed all the time - an extended version of what Bernie's > taxiway editor puts out with logical taxiways, gates, circuit direction, > vfr reporting points, noise reduction regs, preferred calm rwy etc - all > the stuff that is going to have to rely on users entering it since there's > no central database, and a lot of it stuff that can fall back to sensible > defaults. I would be very tempted to put tower and windsock in here as > well, unless you know of a large database of such values. It's also > confused by the fact that you probably want to render them based on that > info, and would prefer one file for Terragear input? I'd also be tempted > to put runways in the per-airport file, to be automatically tar'd up in > FG's standard scenery directory format for the program to find, but suspect > that Curt will be sending this to dev/null about now :-) > > A few other points - how about splitting the world-wide databases into 2 - > with the split down the atlantic and down between Alaska and Siberia. > Loading the other database into memory at 30000 over the ocean probably > wouldn't be noticed, and key Greenland etc VORs could be duplicated. Does it buy you much if you're going to have to load both if someone searches for an entry anyway? > Also - the taxiways really don't need to be in runways.dat - they're only > used for rendering (Terragear) and slow up the loading of FG. Remember > that loading text files is much slower on Windows than Linux. It would be > better to split out the taxiways into taxiways.dat.gz and ship it with the > base for reference but not load it IMHO. I was going to suggest moving all the supplementary data to this file too, but then it occurred to me that not all of it is used simply for building scenery - things like windsock info would be fine - as it can be placed when the airport tile is built, but things like circuit and logical taxiway data are required at runtime, so we'd be dragging all the redundant baggage along too. Moving all supplemental airport data to a per airport file would make sense, although it will require changes to terragear for building the airports. If it's done right though it should allow easy expansion of airport facilities. As David said, XML may be the way to go. -- Jon Stockill [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
