Hi, Tony Pelton schrieb: > heck, even taking the records, and stuffing those records, as they are > now, into XML would be a start. > > at least then, you could find records in the XML easier, and only have > to worry about field level parsing of the data. > > that would be a step ...
I wouldn't oppose going for XML, and you've presented some good arguments (the possibilities of XSLT, self-documenting) I agree with. I'm just not yet convinced that that would actually make writing a parser and a writer less work for me. I'll probably have to write the parsers and writers for the new format for TaxiDraw in its redesigned form (unless Dave or Durk take that from me ;-), so I'm interested in any possibilities reducing the effort for this boring and tedious task. OTOH, the actual storage format should be unimportant. What's important is the data that is stored. Overloading a record-type (10) with two essentially differing types of data (runway and taxiway) looks like a good example of bad data-modelling to me - without wanting to diminish the work of those who developed the format and the tools _and_ maintained the database. Targeting XML as a storage-format may help to "force" the people in charge towards better data-modelling, but does not necessarily do so and also is not a prerequisite to do so. I remember that TaxiDraw loses some data regarding edge lights and marking lines when storing to apt.dat-files. I'll have to check whether the relevant info was incorporated into the new apt.dat-format. As far as I see, there is still open questions on some of the points of the new data-model. Also, from the first look at the specification, it seems as if there are also some backwards-compatibility-issues in there, as the old record types have been kept. All-in-all I think this is a large step towards what airport modellers were waiting for. Essentially, the rigid rectangle-based structure of apt.dat and the related tools made me go for extending TaxiDraw, leading to the need for making it easier to extend ;-) So this is coming earlier and with less pain than I expected it. If the alternative would be forcing XML and discussing another half a year, I'd go for the "olden" storage type. BTW: We still have some issues regarding the FlightGear graphics engine to solve if we want curved taxiways and generalised markings (stopbars, etc.), don't we? Cheers, Ralf _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
