Re: [Flightgear-devel] apt.dat changes ?

[Ralf G. <rge...@kn...>]

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