Hi Thorsten,
ThorstenB wrote:
> On 23.04.2012 13:52, Christian Schmitt wrote:
>> We could, if the xml parser would not simply discard any new runways that
>> are not already in the apt.dat file.
>
> If I understood a comment of James in the bug tracker correctly, this,
> however, always has been and still is the normal behaviour, since these
> XML files were only intended to provide updated airport info, not
> introduce completely new ones (so it's not a new bug, as someone
> suggested).
Indeed, the XML structure was primarily meant to override incorrect
values of pre-existing airfields. Anyhow it's by far flexible enough
to add additional features wherever it makes sense. Thus, for the
cases you outlined, I don't see the need for distributing yet another
set of files carrying almost redundant data.
>> The xml files are small, can be distributed easily and are very fine-
>> grained, meaning that FG only has to parse the data it really needs for the
>> current scenery path, instead of parsing a close-to 100 MB file on every
>> startup (only for the apt data).
>
> I think we need the complete airport data in many places, i.e. when
> mapping the given start airport code to a starting position, to display
> the list of available airports in the selection dialog, to have data for
> the route manager, data for scheduling AI traffic, and for the Nasal
> interface to nav/airport data (which James is just updating these days).
> These probably all rely on a complete airport list being available
> straight away.
"A complete airport list" in the meaning of "a list containing all
airports", "a list containing all features of an airport" or "a list
containing all features of all airports" ? That's quite a huge
difference :-)
The "Scenery/Airports/" layout was designed with minimal overhead in
mind. First there's a plain-text file "index.txt", sufficient to build
a simple geographical index of all airfields. After the relevant
airfields of interest ("AoI's" ;-) have been identified, quick
access if provided by the one-letter XML directory structure.
> So, we probably can't restrict things to the current display area. What
> may make sense is a better, non-compressed file format though, where we
> only load basic data (airport names/position/runways/...) at start-up,
> which would probably only require a few 100K. Later, we could go back
> into the (database) file and load additional data on demand, such as
> taxiway information, etc. (Which reminds of this
> http://developer.x-plane.com/2009/09/scalability-and-apt-dat/ ).
>
> If data needs to be loaded anyway (airport codes/positions), then
> distributing it to tons of individual files may not help with start-up
> delays either.
Given the above structure theres no need neither to parse huge
"apt.dat" files nor to load "tons of individual files".
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
