David Luff writes: > Yep, here's my stats from the program I ran to compare the databases when I > imported the atis data: > > ******* STATS ******* > 9873 airports in DAFIF > 16937 airports in default.apt > 1384 airports had K added to match default.apt
Also note that the Alaska and Hawaii airports have a "P" prepended (PANC, PHNL) > 2 airports had a letter removed to match default.apt > 4057 airports could not be matched with default.apt > 1077 of these had no valid ICAO code or FAA host ID > ********************* > 1247 airports with ATIS > 22567 records in com file without ATIS > 0 airports had ATIS but could not be found in the map > 98 airports with ATIS had K added to match default.apt > 2 airports with ATIS had a letter removed to match default.apt > 202 airports with ATIS could not be matched with default.apt > Total of 1045 airports added to default.atis > Total of 1286 unique ATIS frequency/locations written > done > > > Note that that's not the most recent Dafif though. Typically a lot of US > airfields needed K added to a 3 letter identifier in the Dafif to match > default.apt. I've attached the program I wrote to go through it - its very > very rough but may give you some ideas. Note that you have to be carefull > with munging identifiers to fit the two data sources - of the 6 airports > which could be matched from a 4 letter Dafif code to a 3 letter default.apt > code, only 2 of them were actually the same airfield. A similar caution > probably applies to adding 'K' - it'd be worth checking the Dafif country > code to ensure its a US airfield you're doing it to. > > > > >Also, how do we want to handle updates - I can track how everything was > >last updated now, so from an initial import of the xplane database I can > >update it with DAFIF, *but* since the DAFIF info has no taxiway data, if > >the runway positions get changed slightly the taxiways won't line up. > >Updating *only* fields with no taxiway info, or which were last > >updated/created by DAFIF data is possible. Manual updates are another > >problem - if someone goes to the effort of correcting data then we don't > >want to overwrite it with potentially less accurate info from one of the > >databases. > > > >If anyone has any ideas on how we should prioritise the information then > >I'd be very interested in hearing your ideas. > > > > Hmm, its a bit late (1.30am) to think about all that stuff now, but believe > me, you've taken on a huge, but extremely important job. I'd say maintain > multiple entries for each airfield if necessary - xplane, Dafif and manual, > and then a choice can be made at render time which to use. I'd suggest > that basics are to allow manual entries/corrections to be made which aren't > overwritten by x-plane/Dafif updates, to allow xplane/Dafif updates, and to > track where entries come from. Have fun!!! > > Cheers - Dave > > -- 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
