Hi Ralf, Ralf Gerlich wrote:
> 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. Ah...well, it's that translatability that's most important I think ... there's really no reason why FG should be stuck with an X-Plane container model. > 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. This is where the compiler model works...it doesn't dictate a higher level abstraction, so it leaves authors like you and David to make the best internal model for TaxiDraw that you can come up with, one that plays to TaxiDraw's strengths and doesn't saddle you with implementing things you don't need. We had Christian Franz trying to take X-plane's final modeling format (OBJ) and stick extensions into it to make it into an editing format...this ended in repeated failure; by comparison, exporting from Blender works well. > 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 ;-) Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. I'm not against doing that...but to some extent it's beyond the scope of apt.dat 850...to some extent apt.dat 850 says what data x-plane will eat, but nothing about where it comes from. The intention is that the programs that create that data will have a more descriptive format that makes editing practical. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
