On Tue 10 Apr 2012 10:23:23 PM CEST, ThorstenB wrote: > Am 10.04.2012 21:08, schrieb Martin Spott: >> And there's still one thing to consider: Having one central set of >> apt./nav.dat files in the Base Package still doesn't address the trend >> of the FlightGear project and Scenery development proceeding >> asynchronously. > > But to be honest, it neither works with central terrasync scenery. We > could never push any updates (such as introducing terrasync scenery with > the new EDDF runway) without immediately breaking consistency with all > previously released FG versions (= their base packages). And we cannot > expect all users to run the same FG version - or to even update their FG > setups (base packages) on the same day. A bunch of Linux distros still > haven't switched to FG 2.6.0...
As far as I know terrasync uses svn. So for every release we could fork a new branch which is automatically selected by the terrasync client. This would prevent all version conflicts and issues. > > Since we somehow "hard-code" navigation data into the generated scenery > tiles, it really makes sense to couple them closely. > > Terrasync already syncs a global "/Models" directory, so terrasync > scenery can use newer or updated models. We could do the same for nav > data. I'd be happy to extend terrasync to sync another global directory, > i.e. "/Nav" (or "/Nav810", "/Nav850") and then extend FG to consider > these directories first, before defaulting to (old) nav/airport/airway > data from the base package - which then would only need to match the > (old) base package scenery (i.e. before the users pulls terrasync data > for the first time). > > This would avoid consistency issues, unless the nav data format itself > changes - like it will with the 810/850 change. But this seems a less > frequent event - hopefully not happening every 3 months or every year. > > It wouldn't help with any individual, regional scenery projects though: > these could still rely on different, conflicting versions of nav data - > and we can only load one version into FG. But we probably don't need to > (nor could, maybe neither should ;-) ) address this anyway... Beside serving a global nav.dat/apt.dat through terrasync, we could extend fgfs with the possibility to load custom scenery specific nav.dat. For example through patch files which are applied to the terrasync nav.dat when fgfs starts. > > cheers, > Thorsten > > ------------------------------------------------------------------------------ > 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 Best Regards, scosu ------------------------------------------------------------------------------ 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
