On Tuesday, January 28, 2003, at 12:18 am, David Megginson wrote:
This single fact alone has saved me an enormous amount of hassle, the tab-delimited format is infinitely more usable.First, forget the native fixed-field DAFIF format and go for DAFIFT -- it's the same stuff in a simple tab-delimited format.
Other than taxiways, the DAFIF has so far not missed any entries (I'm trying UK stuff, but for example even the STARs for Edinburgh are there : a medium-sized international airport, of course, but well outside the US. If people could find more obscure fixes / navaids / stars in their region they want me to 'test' against the DAFIF, feel free. Obviously Europe is likely to be the best-covered area after north america.Second, DAFIF is incomplete outside the US, at least -- all of the navaids and waypoints are there (as far as I can tell), but many airports are missing, and there only a small selection of IFR approaches. The DAFIF is also missing the hand-drawn taxiway data from Robin's database, but we'll have to replace that eventually anyway.
Is there any data in there that won't be in the DAFIF, since we've already established it's US coverage is good?There are several. The FAA publishes complete data for the U.S. -- it is free to redistribute, but you have to pay to order the CD in the first place. People tend to put it online.
I will try to work on a sensible scheme for integrating such data (and other 'supplements') into the data set. This brings up an interesting point: is the (currently) 23MB download for DAFIFT.ZIP too big? Personally I think it's fine for broad-band users, and if we simply say that FGFS_ROOT/DAFIFT/ is the unzipped tree, then people can incorporate new AIRAC cycles trivially. And as we / I extend the amount of data parsed (eg to include airspace boundaries or obstacles) there's no need to integrate other data.Finally, you'll have to solicit user contributions for smaller airports, especially outside the U.S.
Is this acceptable or just 'not'? Obviously we could have a cut down set of data for demos (as we do for the KSFO scenery in the base package), but I think ~23MB to give you a decent chunk of global navigation data is a 'bargain', even if you're on a modem. That said, by switching to a binary format and discarding superfluous fields, we can certainly achieve a gigantic reduction in the data-set size: the processed, compressed bundles from navdata.at average 2.5 to 3MB
Anyway, I think I'll start working on reading in the raw DAFIFT data instead of the existing data in Navaids/, and then worry about supporting compressed forms of the data once I have the basics working. And now I have airways data to play with!
H&H
James
--
The lack of planning on your part does not constitute to an emergency on mine
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
