Jon Stockill writes: > 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
Welcome to the joys of data management. I recommend putting all of the DAFIF airports in separately for now, with a different "source" field: source = xplane source = dafif Then, late, you can specify rules for which ones get included or excluded in a build (i.e. the DAFIF KSFO and the X-Plane KSFO are treated as different, mutually-exclusive airports). > 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. For now, let's just get all the airports in. The way that X-Plane implements taxiways is just horrible -- aprons are just wide taxiways, for example, and taxiways are always rectangles run together. Perhaps we'll be able to think of a better system. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
