Paul Surgeon wrote: > In short we need a vastly improved TaxiDraw or a new replacement. > The only hassle is that genairports cannot handle any new types of data so > that would need modifying too.
To my understanding is _not_ TaxiDraw or 'genairports' that produces hassle - TaxiDraw is just an application that plays on the keyboard of the current infrastructure. Instead, the key point is compatibility with Robin's airport database which instantiates the ongoing dependency of FlightGear on the X-Plane development. Although I heavily dislike this dependency I realize that one would'nt easily discard such an effort that has been so helpful over a long time. Whatever you do on the FG side you still should keep some two-way data exchange with X-Plane as an option. One could agree on the least common denominator: The taxiway layout described by the center, orientation, length, width and surface of a runway/taxiway. You always can add additional information for FG, but you should still be able to generate airports with 'basic' data - right from the X-Plane database - or export to the X-Plane format. I know, here I present that key argument _against_ my own beloved idea of generating airports from shapfiles or similar data .... :-/ I believe the first step is not to replace TaxiDraw but to improve/rewrite the airport generator to handle the current X-Plane format _plus_ whatever you'd like to add. If this is done, one could think about what to do with TaxiDraw, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
