On 10/13/03 at 5:12 PM David Megginson wrote: >I'd like to propose the following changes to our current airport data >formats: > >1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), > add two fields containing the ISO 3166 country code and a > country-specific region code. Either can be represented by 'U' if > unknown. For example, here is the current entry for KSFO: > > A KSFO 37.618763 -122.374926 13 CYN San Francisco Intl > > Here is a revised entry with the new fields: > > A KSFO 37.618763 -122.374926 13 US CA CYN San Francisco Intl > > This change will allow us to create airport dialogues sorted by > country and (optionally) state/province/region. Initially, we can > just set every one to 'U', or possibly apply some simple heuristics > (every four-letter airport identifier starting with 'K' is in the > U.S., every four-letter airport identifier starting with 'CY' is in > Canada, etc.)
Agree whole-heartedly with this. Things like frequency lookup can then have a nice world-map downwards clickable interface. > >2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), > add two new record types, 'W' for windsock and 'C' for control > tower. The W record would look like this (where 'S' stands for > 'sock' rather than the other thingy, and 'L' stands for 'lighted): > > R KABC 29.650236 -96.579416 176.00 SL > > The 'C' record would give the latitude, longitude, and view > elevation of the control tower: > > C KABC 29.651347 -96.580527 315.00 > >Comments? > 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. 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. 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. Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
