Hi Crhis, Torsten What is really needed at the moment is someone starting to verify if some changes to "our" apt.dat from the past have to come to recent apt.dat shipped with FlightGear. Martin Spott prepared an updated apt.dat on the mapserver, but the changes in there have to be verified if its worth to "commit" this to Robin Peels database first. Some airports have probably better or more improvements in flightgear apt.dat version (i.e. taxiways). There are ~250 airports to check (see the link posted in my former post).
> > In this case it would make sense to unpack apt.dat, too, as many changes > need to be done to the two files (ILS changes i.e.) Chris, you mean nav.dat here, do you? > > The central repository would be Robin Peels xplane database, which still > contains nav.dat files compatible with FG. BUT as they depend on a certain > apt.dat version we can't just copy them over as a whole. > > In the future, when our scenery is created with apt.dat 850 data, we still > have to keep one apt.dat file, as it has to match the distributed scenery. > Isnt it possible to commit flightgear apt.dat/nav.dat changes directly to Robin Peel/xplane database, without serving an own apt.dat and spreading derivatives? This caused a lot of problems the last years I guess. I.e. there was never a proper solution what happens to changes made by flightgear contributors. It would be so much easier to have ONE apt.dat/nav.dat source, maybe someone can contact Robin Peel to get a shared flightgear/xplane repository? Cheers, Yves Cheers, Yves ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
