On 1/15/03 at 12:39 AM Jon Stockill wrote: >On the subject of runways - I've been working on the database today. > >I can import and export the xplane database, and have some code which >parses the DAFIFT data, and compares it with the existing database, >however: > >1. Not all airfields in the xplane database are in DAFIF >2. Not all DAFIF airfields are in xplane >therefore >3. There's no single common identifier for a field
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 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
parsedafif.zip
Description: Zip compressed data
