Hi Melchior, thanks for your feedback. I am taking this to the developers' list.
To everyone else, I am referring to this mail on the users' list: http://sourceforge.net/mailarchive/message.php?msg_name=490C204E.7040405%40aon.at Melchior FRANZ wrote: > The question is, however, if we don't want to put all airport > data into one file, in which case the fourth dir level would > be superfluous. Merging the tower and threshold files would be possible, but I would oppose merging them with the parking files for two reasons. Reason One is organisational: The parking files are based on direct manual work and are created directly by TaxiDraw, while the tower and threshold files are from the apt.dat. Combining them would mix automatically derived and manually generated content, making management of the data much more complex. I see strong arguments in favour of keeping the connection to apt.dat. Although currently the v810 files are not maintained any more by Robin Peel, we will eventually move on to v850 and then be synchronised with the X-Plane Community again. (BTW: There is an open position at the World Custom Scenery Project for implementing v850 in TerraGear ;-) ) I also do not see any chance in general to push an XML format to Robin Peel and the X-Plane-Community. Keep in mind that the files distributed with the scenery contain only a small fraction of the data contained in the apt.dat (which should already lead to an increase in speed). Taxiways, markings and other details are not re-distributed. For this kind of data, the current apt.dat-format is a good compromise between compressing the representation and making it user-editable. Reason Two is technical: The parking files are currently not in PropertyList format. I know that this has been subject of fierce discussion, which I have no interest in repeating. As long as nobody comes up with a patch making the AI code use a PropertyList format, converting the old files and informing me so that I can update TaxiDraw accordingly, we will probably also have a non-PropertyList-format for the AI files in the next FlightGear release. But then Reason One would still exist. Now it all boils down to the tower and threshold files. These are typically pretty small, so that the overhead for parsing two files instead of one file should be negligible. Further there should be very seldomly a case where we need the information from both files at the same time, e.g. when teleporting to another airport, thereby changing the tower view position. Merging them in time for the next release would mean that we'd have to do another scenery release. Such a release - with some further bugfixes regarding the terrain - is planned, but not before end of November due to time constraints on Martin's and my side (preparing to get my Ph.D. thesis submitted). If we were to make a release this year, this would leave not much more than three or two weeks for properly testing this change in the wild. If things go wrong on the scenery side, we might be just in time for the FlightGear release. So if there is a strong argument in favour of the changes you proposed, I'm open to such a last-minute change, but otherwise I'd rather leave the structure as it is. The last time we fixed scenery in the last minute we had a good share of chaos ensue (which happens to have been just about one year ago). I'd also like to add that a sample of the structure as proposed has been in the FlightGear data CVS for quite some time, containing data for the KSFO area, ready to be commented. IIRC this was also explicitly mentioned in the CVS logs. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist | http://www.custom-scenery.org/ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
