On Tue, 2008-11-04 at 10:01 +0100, Ralf Gerlich wrote: > Curtis Olson wrote: > > Is there a reason that we split up each airport's data into at least 5 > > different files? > > There is reason to separate the pure airport geometry data from the > AI-network. Those come from different sources and are maintained > differently: one part automatically generated from apt.dat, the other is > manually created using TaxiDraw. > > My _personal_ view is that the data coming from the apt.dat could be > merged into one XML-file. This point was already discussed. > > There is also reason to split the data up into one airport per file to > allow fast lookup by airport-ID. > > > Right now, Martin's proposal uses path/file <dot> extension <dot> > > another extension. That is the main thing that jumps out at me as being > > unappealing. > > I have already provided the arguments in favour of the three-level > hierarchy.
By my count, there are some 21,893 airports in apt.dat. This scheme will require 36 top level directories, 1011 2nd level directories and 8634 3rd level directories. So a full Scenery/Airports/ would contain some 109,465 files and 9,681 directories. Managing this in CVS would add another 9,681 CVS directories and 29,000 (Entries, Repository and Root) files. So we could conceivably end up with 140,000 files and 20,000 directories? > > One issue to consider is that on windows file systems, the minimum block > > size is usually really big, so tons of little files really burns up and > > wasted disk space. > > Due to the splitting, each user only downloads those airport-data files > that are related to the scenery area downloaded. The more I hear, the less I like this idea. So I won't have ILS navaids available if I don't download the scenery tile? I won't be able to look for airports unless I pull the whole world scenery? > So in fact only those > people will see an notable increase in disk size who already accept the > disk usage of larger scenery areas. Others will probably only notice > being spared the load of apt.dat.gz Under the current scheme anyone and everyone can scan apt.dat for every/any airport using common *nix tools like grep or sed. This scheme breaks that ability. > In a similar way, this applies to the .stg-files as well. Still I don't > see anyone having objected to this aspect of scenery organisation _for > years_ and having provided and implemented a different concept. > > Again: If anyone has a better proposal than the one provided by us, > present and implement it. Why not just ship apt.dat and nav.dat with the scenery release instead of the base package? Simple, efficient and it doesn't break all the current code and methods that use these files. I'll shut up now since I've already been told I'm not a "real" FlightGear developer and I'm not welcome to create scenery. Thanks, Ron ------------------------------------------------------------------------- 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
