Martin Spott wrote:

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,

There has been some small amount of discussion with Robin about giving the FG project a "code range" that we would own. Each line in the apt.dat has a key code saying the type of info it contains, and so we could have a range of codes that are dedicated to FG use and would be guaranteed never to conflict with X-Plane code expantion. When Robin releases new data and Dave integrates our local changes that haven't yet been accepted by Robin, he could also integrate the specific FG info for all the airports we have specific FG info. This would produce a FG specific apt.dat file which could easily be stripped of the extra FG codes to return it to pristine X-Plane format. It also makes sense to talk with Robin about possible changes. He holds much sway in the X-Plane community so if they are planning new codes or features, it might make the most sense to coordinate with them to avoid duplication of effort ... and only introduce a FG specific code when there is no other recourse.



Curtis Olson
HumanFIRST Program
FlightGear Project
Unique text:        2f585eeea02e2c79d7b1d8c4963bae2d

_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] 2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to