> > On 24 Apr 2012, at 08:28, ThorstenB wrote: > >> 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. >> >> James really needs to comment on nav data things though, since I never >> touched this area. > > The quick answer is, we need a lot of data *available* at startup for > position init. Parsing it from apt.dat and nav.dat is 'slow', but has been > optimised over the years. (Parsing 20MB of text data each launch is still > kind of crazy, though) Collecting it from many XML files would also be > slow, but there's a general point that we should be decoupling > *availability* from *loading*. > > I've had (in the past, it's bit-rotted now) a binary cache of the navdata > and airport-data (stored into $FG_HOME), so that assuming the stat() data > on files hasn't changed, no time is spent rebuilding the cache on launch - > which makes the FGFS launch time dramatically better, for me. Having such > a cache takes a major constraint off how the data is structured and > parsed, so I think it needs to be revisited. > > (Quite a lot of the structuring of FGPositioned and related classes is to > make such a scheme possible, especially the fact everything is ref-counted > - another benefit of the cache is not needing to have every airport, > navaid, runway and taxiway from apt.dat in RAM) > > To repeat what I said in some other places - on the C++ side I can > tolerate (and am happy to write the code!) to deal with nearly any format > - XML files in the scenery, single files in XML or the X-plane 810 or 850 > format - whatever. It's not that hard, I understand the issues and we have > plenty of supporting code. My concern is that 'the community' agree a > design that fits most people's needs. > > (And can generate / get / maintain the data!) > > Thorsten's point about matching apt.dat and nav.dat into TerraSync makes a > lot of sense to me, for example. I'd also be happy looking for navaids in > the scenery structure (in the w010n040 dirs?), looking for *all* airport > data in the Airports/E/G/P/ structure, or anything else. I really don't > mind, and I can support several approaches with some schemes taking > precedence, but deciding what design is right, I have not much clue about > :) > > James > >
Hi James Maybe its also worth to compare whats in FGx here. A lot of all this C++ code is already in. The cache, a very fast apt.dat parser, a xml parser etc. Cheers, Yves ------------------------------------------------------------------------------ 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
