Traditionally, the "three main sources of FlightGear users' joy" (TM)
are tightly coupled together:
The Base Package depends on the Sim-/FlightGear source mainly because
aircraft features are being developed in sync with the available FDM-
and rendering facilities. The Scenery on the other hand depends on the
Base Package because we rely on deriving runway threshold positions and
other geographic entities from the files which are shipped as a part of
the Base Package.
We all know about the related downsides: The enthusiastic developer is
adjusting the layout of his local airfield, submits his change to Robin
Peel - and has to wait one or two years until his change makes it into
the official Scenery .... maybe he has to wait even longer, because
almost nobody cares about updating the respective data files in the
Base Package during the release process.
So, we didn't spare any effort to hold a democratic election among the
main active Scenery developers and surprisingly we came to the
conclusion that it's time to untie the Scenery from this dependency
chain :-))
We plan to achieve this goal by a solution as minimalistic as possible,
still keeping compilance with traditional rules in the FlightGear
development process.
In other words, we're deriving an absolute minimal subset, basically:
the geographic information that is required to match with the Scenery
airport layout, from the respective sources and store this in a
'traditional' file format that, as usual, allows every contributor to
verify his contributions before submitting to some general repository.
Those entities we identified as overlapping between the visual
representation of airfields in the Scenery and the respective data
files in the Base Package are:
1.) Threshold positions and orientation (typical startup positions),
2.) ILS positions and orientation (apparently depends on runways),
3.) Taxiway ground network (we don't want AI airliners to taxi off the
tarmac),
4.) Aircraft parking positions (to avoid airliners parking on the grass
or inside the terminal building).
We're storing this information in a couple of XML files in a newly
created 'Airports/' directory alongside the well known 'Terrain/' and
'Objects/' directories. The new directory is being organized using sort
of a poor-man's alphabetical index, using three stages of
subdirectories.
Note, this directory structure is not meant to be used primarily as a
datasource during runtime. Instead, this directory structure is
designed as a transport to be editable by the average developer. A tool
to create a condensed runtime-extract is being prepared and is expected
to get introduced until the next FlightGear software release is due.
Even though there's no immediate use of this feature, we'll add it to
the upcoming Scenery release in order to allow the software adapting to
it and to have everything in place until the next software release.
You'll find an example of the mentioned structure in CVS.
Regards,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
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
