Hi Ben, bsupnik wrote: > Ralf Gerlich wrote: >>As it seems, the X-Plane authors are not keen to go away from the >>apt.dat format, so if FlightGear would go away from bidirectional >>compatibility with apt.dat, this would result in a clear split of the >>databases and in ceasing the up to now fruitful exchange of data between >>FlightGear and X-Plane. Keep this in mind when assessing the advantages >>of a new, totally different format. > > > I'm not 100% what you mean by this...we are supporting older apt.dat > formats in x-plane ... we have to - in X-plane apt.dat can be embedded > in custom scenery packas, so users can add old-format data to the sim > in-field. So X-Plane will continue to read and show old-format data but > without any new features.
There was criticism of the physical storage model of apt.dat, as it has been and probably will continue to be in version 850. I just wanted to say that, if the FlightGear project were to "invent" its own format - let's call it FGAPT for simplicity - and would then not be able to convert from APT to FGAPT _and_ backwards, we would lose the possibility of properly interchanging data with X-Plane and Robin Peel's database. We might not lose the possibility in total, but at least in part. I like the idea of essentially having the userbases of two flight simulators work on the airport database. This is something both projects gain from. In consequence, I don't like the idea of losing this possibility by not being able to transfer updates in both directions. Some time ago (it might be already a year ago) I had a discussion with Dave Luff on the topic of making TaxiDraw a bit more useable. At that time I had started customising scenery for my local area and found the way of working with single rectangles in TaxiDraw very awkward and time-consuming, in contrast to, e.g., just clicking along the centerline of a taxiway and having TaxiDraw generate the rectangles from that. It all boiled down to the question how we could preserve our basic information - the polylines - in apt.dat. We could - as Curt told us - have our own codes in apt.dat, but then we would have to store the same information twice, once as polyline and once as rectangle list, practically calling for them to go out of sync. In that aspect, the new intended version 850 of apt.dat solves that problem at least in my mind. I also like the mindset of interpreting apt.dat as some kind of intermediate format of a compiler. However, as decompilation into a higher-level format is not possible, apt.dat even in its new form does not seem to be a good format for keeping in a central database based on which updates to the airport layouts are made. Such a format needs to keep the top-level information modellers see in their editor, so that the next one can simply import that top-level model from the database and go on where his/her predecessor left. This is exactly the reason why we have sourcecode in our CVS and not the intermediate register transfer language (RTL) of the GNU C/C++ compiler suite ;-) People in FlightGear have already come up with external solutions, such as Durk Talsma's XML-based logical AI-network, but as Melchior said, this is nothing we should wish to do with any upcoming extension in the future. Cheers, Ralf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
