Hi Curt! The World Custom Scenery Team has decided - already some time ago - that the scenery release intended for shipping with the planned FlightGear release in December will be the _last_ scenery release produced by the World Custom Scenery Team that is synchronized with the Base Package apt.dat.
This step is taken for reasons we had already explained and which are otherwise will be seriously obstructing the advancement of the World Scenery. Therefore we designed and proposed an alternative scheme suitable for proper inclusion with the scenery itself, allowing fast lookup of airport data both by geographic location and by airport-ID. This scheme was presented to the concerned developers long ahead of time, including Curt. If anyone of you has a proposal that fits the mentioned purpose better, then come forward _and_ implement that concept. We uphold our proposal and will provide the data in that form. 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. > 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. 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 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. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist | http://www.custom-scenery.org/ ------------------------------------------------------------------------- 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
