ThorstenB wrote:

> 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...

But we can't guarantee backwards compatibility forever for future world 
scenery releases. The main problem I currently see is a different one 
however...

> 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).

Now, it's good to see these issues getting some attention, but that is not 
the only issue we are facing:
Taxiway signs are distributed via terrasync as stg entries. apt.dat 850 
contains the taxiway definitions along with the rest of the airport data. 
What we do now in genapts850 is to convert the sign format from apt.dat to 
stg and write the corresponding files. No problem so far (and we always get 
the correct hight for the signs along the way). If a user wants to edit the 
signs, he can do it in stg, but that is a one way road. Ideally the edits 
should go back to upstream so everyone can profit from them. But there is no 
(official) way back from stg to apt.dat. I was in this situation yesterday 
and hacked together a quick script to be able to convert the signs.

Xplane's WorldEditor (WED), an opensource program, BTW, is perfectly able to 
create airport layouts, signs and taxiway routes. All of this is read and 
written back to apt.dat. So our general question should be how to handle 
this situation in the most optimal way. Should we continue implementing our 
own xml versions of the apt.dat entries or should we rather try to read as 
many properties as possible directly from an apt.dat file? And how do we 
secure the exchange of data between stg and apt.dat?

This topic is very complex and I'm sure i forgot many other important 
aspects, but this is just what i'm currently thinking about.

Chris

------------------------------------------------------------------------------
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

Reply via email to