FlightGear wiki - User contributions [en]

Fr/Options de ligne de commande

2017-10-22T10:49:05Z

F-ojac: Fixing a 404 error on the former link.

'''Les options de ligne de commande''' sont un moyen usuel d'indiquer aux applications quoi faire / comment réagir au démarrage. Avec [[:fr:FlightGear | FlightGear]] elles sont utilisées pour un grand nombre d'opérations, des plus simples comme la sélection d'un aéronef jusqu'à des formules complexes comme la définition du trafic réseau et des paramètres météo.

La manière la plus simple de traiter ces options pour FlightGear (''fgfs'') est d'utiliser un outil avec une interface utilisateur graphique comme ''[[fgrun]]'' sous Windows et GNU/Linux ou le lanceur d'interface graphique sous Mac OS X. Avec cette méthode, nul besoin de s'en soucier. 
Néanmoins, il existe des utilisateurs qui ne veulent ou ne peuvent pas exécuter l'interface graphique et qui s'intéressent donc à ce sujet. Ceux qui en ont besoin, ou qui veulent simplement en savoir plus sur FlightGear, mais qui n'ont aucune idée de ce dont nous parlons ici, sont invités à lire la page wiki sur l'usage général de la [[command line | ligne de commande]].

L'emplacement approprié pour stocker ses options personnelles est un fichier nommé [[fgfsrc]]. Ce fichier est lu par ''fgfs'' à chaque démarrage.

Les listes ci-dessous fournissent les options pour ''fgfs'' en incluant une courte description et sont triées par catégories. Gardez bien à l'esprit que le maintien à jour de ces listes sur le wiki n'est pas une tâche facile. De plus, il existe différentes versions de FlightGear qui ne partagent pas exactement les mêmes options. Par conséquent, il vaut mieux vérifier votre version avec <code>fgfs --help --verbose</code>. Si cette commande échoue, vous devez ajouter l'option <code>--fg-root=[path]</code>, voir ci-dessous. 
C'est triste à dire mais vrai : même cette commande, au moins sous Git, n'est pas tout le temps à jour. A l'heure où nous écrivons cet article, au moins une option supportée n'est pas listée en faisant <code>fgfs --help --verbose</code>. Alors si vous avez de sérieux problèmes avec une option, le code source est, comme toujours, la meilleure source d'information. Dans le fichier ''src/Main/options.cxx'', toutes les options sont listées avec leur valeur et leur type par défaut "en dur". 
Le fichier [[$FG_ROOT]]/options.xml est utilisé pour générer la sortie pour <code>fgfs --help [--verbose]</code>. C'est la raison pour laquelle <code>--fg-root=[path]</code> doit être ajouté, s'il n'est pas défini comme variable d'environnement ou comme une option dans fgfsrc.

''Note du traducteur : la liste suivante est inspirée de celle figurant dans l'article Wiki original en anglais, mais adaptée d'après le contenu du dernier manuel officiel FlightGear en vigueur à la date de la traduction, en l'occurrence pour la version 2.10.0.''
''C'est pourquoi il existe des différences entre la présente liste et celle figurant dans l'article original en anglais.''
''En outre, certains éléments sont repris de l'excellent travail de traduction du manuel FlightGear commencé par David Mézière et autres.''

Usage : <code>fgfs [OPTION [OPTION ...]]</code>

==== Options générales ====

--help Afficher les options de ligne de commande les
plus courantes.
--help--verbose Afficher toutes les options de ligne de commande.
--version Afficher la version courante de FlightGear.
--fg-root=chemin Indiquer à FlightGear où rechercher ses fichiers
de données racine si vous ne l'avez pas compilé
avec les options par défaut.
--fg-scenery=rep[:rep...] Spécifier le(s) répertoire(s) des scènes de base,
dans le cas où celles-ci ne se trouvent pas à
l'emplacement par défaut [[$FG_ROOT]]/Scenery ;
ceci peut être particulièrement utile dans le cas
où les scènes se trouvent sur un CD-ROM.
--fg-aircraft=chemin Spécifier le(s) répertoire(s) des aéronefs ;
valeur par défaut : [[$FG_ROOT]]/Aircraft.
--language=code Sélectionner la langue pour la session courante ;
par exemple : pl, nl, it, fr, en, de.
--restore-defaults Réinitialiser tous les réglages utilisateur
à leurs valeurs par défaut.
--enable-save-on-exit Activer la sauvegarde des préférences utilisateur
à la sortie du simulateur.
--disable-save-on-exit Désactiver la sauvegarde des préférences utilisateur
à la sortie du simulateur.
--disable-freeze Démarrer FlightGear en mode normal.
--enable-freeze Démarrer FlightGear en pause.
--control=mode Définir le mode de contrôle principal (joystick,
clavier, souris).
--enable-auto-coordination Activer l'auto-coordination : la gouverne de
direction et les ailerons seront contrôlés
conjointement ; recommandé pour les utilisateurs
ne disposant pas de pédales ni de joystick avec
axe de torsion pour le contrôle du palonnier.
--disable-auto-coordination Désactiver l'auto-coordination (valeur par défaut).
--browser-app=chemin Spécifier le chemin de votre navigateur web.
--config=path Charger d'autres propriétés depuis le répertoire
spécifié.
--units-feet Mesurer les distances en pieds.
--units-meters Mesurer les distances en mètres.

==== Fonctionnalités ====

--disable-ai-models Désactiver la génération de trafic artificiel.
--enable-ai-models Activer la génération de trafic artificiel.
--ai-scenario=nom Activer un scénario intelligent spécifique
(par exemple : --ai-scenario=vinson-demo).
Peut être utilisé plusieurs fois.

==== Options sonores ====

--disable-sound Désactiver les effets sonores.
--enable-sound Activer les effets sonores.
--show-sound-devices Afficher les périphériques audio disponibles.
--disable-intro-music Désactiver la musique d'introduction.
--enable-intro-music Activer la musique d'introduction.

==== Aéronefs ====

--aircraft=nom Charger l'aéronef spécifié, par exemple :
--aircraft=c172p.
Vérifiez les choix disponibles dans le répertoire
[[$FG_ROOT]]/Aircraft et recherchez les fichiers dont
les noms se terminent par "-set.xml".
Pour spécifier un appareil, indiquez le nom du
fichier en supprimant le «-set.xml".
Voir aussi l'option --show-aircraft décrite
ci-dessous pour lister les appareils disponibles.
--show-aircraft Afficher la liste des aéronefs disponibles.
--min-status=statut Afficher uniquement les appareils dont le statut
déclaré est au moins celui spécifié,
parmi les statuts suivants : alpha, beta,
early-production, production.
Pour une utilisation avec l'option --show-aircraft.
--aircraft-dir=répertoire Emplacement relatif du répertoire des aéronefs
par rapport au répertoire de l'exécutable ;
valeur par défaut : [[$FG_ROOT]]/Aircraft.
--vehicle=nom Synonyme de --aircraft.
--livery=nom Définir la livrée de l'appareil.

==== Modèle de vol ====

--fdm=nom Sélectionner le modèle dynamique de vol.
Le nom peut être jsb, larcsim, yasim, magic,
balloon, external, pipe, ada, ou null.
Cette option peut normalement être ignorée,
puisque l'option --aircraft sélectionne le bon
modèle de vol.
--aero=name Spécifie le modèle aéronautique d'avion à charger.
Cette option peut normalement être ignorée,
puisque l'option --aircraft définit le bon modèle.
--model-hz=n Exécuter le modèle dynamique de vol avec le
taux 'n' spécifié (itérations par seconde).
--speed=n Exécuter le modèle dynamique de vol avec un
taux 'n' fois plus rapide que le taux réel.
--trim Activer l'application de compensation ("trim")
sur le modèle de vol.
--notrim Empêcher l'application de compensation ("trim")
sur le modèle de vol (applicable uniquement
si fdm=jsbsim).
--on-ground Démarrer au niveau du sol (valeur par défaut).
--in-air Démarrer dans les airs (implique d'utiliser aussi
l'option --altitude)
--disable-fuel-freeze Autoriser la consommation normale de carburant.
--enable-fuel-freeze Geler la consommation de carburant : la quantité
de carburant dans le réservoir reste constante.

==== Position et orientation initiales ====

--airport=ID Démarrer dans un aéroport donné. L'aéroport est
spécifié par son code OACI, par exemple
--airport=KJFK pour l'aéroport JFK de New York.
Pour un aéroport américain sans code OACI, essayez
en préfixant son code de 3 caractères par 'K'.
--parking-id=ABCD Démarrer sur un stationnement spécifique dans l'aéroport.
--runway=rwy_no Démarrer sur un seuil de piste spécifique
(par exemple 28L) ; il faut aussi spécifier un
aéroport. Si aucun ID de piste ni de stationnement
n'est spécifié, une piste face au vent sera choisie
pour le décollage.
--vor=ID Spécifier une position de démarrage relative à
un VOR ; utile pour s'entraîner aux approches.
--ndb=ID Spécifier une position de démarrage relative à
un NDB ; utile pour s'entraîner aux approches.
--fix=ID Spécifier une position de démarrage relative à
un point fixe ; utile pour s'entraîner aux approches.
--carrier=nom Démarrer sur un porte-avions.
--parkpos=nom Démarrer à une position particulière sur le
porte-avions ; doit être utilisé avec --carrier.
Par défaut sur une position de catapultage.
--offset-distance=nm Démarrer à une distance particulière d'un point
de référence (en milles nautiques).
--offset-azimuth=degrés Démarrer avec un cap spécifique par rapport à un
point de référence (en degrés).
--lon=degrés Démarrer à une longitude particulière, en degrés
décimaux (valeur négative pour l'ouest).
--lat=degrés Démarrer à une latitude particulière, en degrés
décimaux (valeur négative pour le sud).
--altitude=valeur Démarrer à une altitude spécifique. Implique
d'utiliser aussi l'option --in-air.
Altitude spécifiée en pieds sauf si vous avez aussi
sélectionné --units-meters, auquel cas elle est
en mètres. Vous devrez aussi positionner une
vitesse initiale avec l'option --vc pour éviter
de décrocher immédiatement.
--heading=degrés Spécifier l'angle de cap initial (lacet) en degrés.
--roll=degrés Spécifier l'angle de roulis initial en degrés.
--pitch=degrés Spécifier l'angle de tangage initial en degrés
--uBody=unités_par_sec Définir la vitesse initiale le long de l'axe X
(en pieds par seconde sauf si vous avez sélectionné
également --units-meters, auquel cas elle est en
mètres par seconde).
--vBody=unités_par_sec Définir la vitesse initiale le long de l'axe Y
(en pieds par seconde sauf si vous avez sélectionné
également --units-meters, auquel cas elle est en
mètres par seconde).
--wBody=unités_par_sec Définir la vitesse initiale le long de l'axe Z
(en pieds par seconde sauf si vous avez sélectionné
également --units-meters, auquel cas elle est en
mètres par seconde).
--vNorth=N Définir la vitesse initiale le long de l'axe Nord-Sud
(en pieds par seconde sauf si vous avez sélectionné
également --units-meters, auquel cas elle est en
mètres par seconde).
--vEast=E Définir la vitesse initiale le long de l'axe Ouest-Est
(en pieds par seconde sauf si vous avez sélectionné
également --units-meters, auquel cas elle est en
mètres par seconde).
--vDown=D Définir la vitesse initiale le long de l'axe vertical
(en pieds par seconde sauf si vous avez sélectionné
également --units-meters, auquel cas elle est en
mètres par seconde).
--vc=noeuds Spécifier la vitesse initiale par rapport à l'air
(en noeuds) ; utile si vous avez sélectionné
l'option --altitude, sinon vous allez décrocher
immédiatement !
--mach=num Spécifier la vitesse initiale par rapport à l'air
(en mach) ; utile si vous avez sélectionné l'option
--altitude, sinon vous allez décrocher immédiatement !
--glideslope=degrés Régler l'angle de descente initial en degrés ;
peut être positif ou négatif.
--roc=fpm Régler le taux de montée initial en pieds par minute ;
peut être positif ou négatif.

==== Options d'environnement ====

--ceiling=HAUT[:EPAISS] Fixer le plafond à une hauteur spécifique, avec
en option une épaisseur spécifique, exprimées en
pieds (valeur par défaut : 2000 pieds).
--disable-real-weather-fetch Désactiver les données météo en temps réel basées
sur le METAR.
--enable-real-weather-fetch Activer les données météo en temps réel basées sur
le METAR (nécessite une connexion Internet ouverte).
--metar=chaîne METAR Utiliser une chaîne METAR spécifique, par exemple
--metar=~XXXX012345Z 00000KT 99SM CLR 19/M01 A2992~.
Le METAR peut être spécifié dans la plupart des
formats courants (américain, européen).
Incompatible avec l'option --enable-real-weather-fetch.
--random-wind Définir une direction et une force du vent aléatoires.
--turbulence=0.0 à 1.0 Spécifier les turbulences de 0.0 (calme) à 1.0 (sévère).
--wind=DIR@VIT Spécifier le vent de surface avec une direction DIR
en degrés et une vitesse VIT en noeuds.
Les valeurs peuvent être spécifiées comme une plage
en utilisant le séparateur ':', par exemple
--wind=180:220@10:15.
--season=param Définir la saison simulée ; les paramètres valides
sont summer (par défaut) et winter.
--visibility=meters Spécifier la visibilité initiale en mètres.
--visibility-miles=miles Spécifier la visibilité initiale en milles.

==== Options de rendu ====

--aspect-ratio-multiplier=N Définir un multiplicateur pour le format d'affichage.
--bpp=profondeur Spécifier le nombre de bits par pixel.
--enable-clouds Activer les couches de nuages en 2D.
--disable-clouds Désactiver les couches de nuages en 2D.
--enable-clouds3d Activer les couches de nuages en 3D.
--disable-clouds3d Désactiver les couches de nuages en 3D.
--disable-distance-attenuation
Désactiver l'atténuation de lumière de piste due
à la distance.
--enable-distance-attenuation
Activer l'atténuation de lumière de piste due à
la distance.
--disable-enhanced-lighting Désactiver l'éclairage de piste amélioré.
--enable-enhanced-lighting Activer l'éclairage de piste amélioré.
--disable-fullscreen Désactiver le mode plein écran.
--enable-fullscreen Activer le mode plein écran.
--disable-game-mode Désactiver l'affichage plein écran pour les cartes
graphiques 3DFX.
--enable-game-mode Activer l'affichage plein écran pour les cartes
graphiques 3DFX.
--disable-horizon-effect Désactiver l'illusion de grossissement des corps
célestes près de l'horizon.
--enable-horizon-effect Activer l'illusion de grossissement des corps
célestes près de l'horizon.
--disable-mouse-pointer Désactiver le pointeur de souris supplémentaire.
--enable-mouse-pointer Activer le pointeur de souris supplémentaire
(utile en mode plein pour les anciennes cartes
graphiques type Voodoo).
--disable-panel Désactiver le panneau des instruments.
--enable-panel Activer le panneau des instruments.
--disable-random-buildings Désactiver la génération de bâtiments aléatoires.
--enable-random-buildings Activer la génération de bâtiments aléatoires ;
notez que ceci prend beaucoup de mémoire.
--disable-random-objects Désactiver la génération d'objets aléatoires
du paysage.
--enable-random-objects Activer la génération d'objets aléatoires
du paysage.
--disable-random-vegetation Désactiver la génération de végétation aléatoire
comme les arbres.
--enable-random-vegetation Activer la génération de végétation aléatoire
comme les arbres ; nécessite une carte graphique
supportant les Shaders GLSL, certaines cartes
anciennes ou moins puissantes ne les supportent pas.
--disable-rembrandt Désactiver la fonctionnalité expérimentale Rembrandt
qui permet l'éclairage amélioré et les ombres
en temps réel.
--enable-rembrandt Activer la fonctionnalité expérimentale Rembrandt
qui permet l'éclairage amélioré et les ombres en
temps réel.
--disable-skyblend Désactiver la mise à jour de l'aspect du ciel en
fonction du temps et de l'environnement.
--enable-skyblend Activer la mise à jour de l'aspect du ciel en
fonction du temps et de l'environnement.
--disable-specular-highlight
Désactiver les réflexions spéculaires sur les
objets texturés.
--enable-specular-highlight Activer les réflexions spéculaires sur les
objets texturés.
--disable-splash-screen Désactiver l'écran de démarrage.
--enable-splash-screen Activer l'écran de démarrage.
--disable-textures Désactiver le texturage du terrain.
--enable-textures Activer le texturage du terrain.
--disable-wireframe Désactiver le mode "fil de fer".
--enable-wireframe Activer le mode "fil de fer" ; si vous souhaitez
savoir à quoi ressemble le monde de FlightGear
vu de l'intérieur, essayez cela !
--fog-disable Désactiver le brouillard / la brume ; pour réduire
la puissance nécessaire au rendu, les régions
éloignées disparaissent dans le brouillard par
défaut. Si vous désactivez le brouillard, vous
verrez plus loin, mais votre taux de
rafraîchissement va baisser.
--fog-fastest Activer la gestion rapide du rendu de brouillard
/ brume ; affichera un brouillard moins réaliste
mais augmentera votre taux de rafraîchissement.
--fog-nicest Activer la qualité du rendu de brouillard / brume ;
affichera un brouillard plus réaliste mais
diminuera votre taux de rafraîchissement.
--fov=degrés Définir le champ de vision en degrés.
Valeur par défaut : 55,0.
--materials-file=fichier Spécifier le fichier des matériaux utilisé pour
le rendu du paysage ; par défaut :
Materials/regions/materials.xml.
--geometry=WxH Définir la résolution de la fenêtre / de l'écran.
Par exemple : --geometry=1024x768.
--shading-flat Utiliser l'ombrage plat (ombrage de Lambert) ;
plus rapide mais moins beau.
--shading-smooth Utiliser l'ombrage lissé.
--texture-filtering=N Configurer le filtrage de texture anisotrope.
Les valeurs sont 1 (par défaut), 2, 4, 8 ou 16.
--view-offset=valeur Définir la direction par défaut de la vue avant
en spécifiant son décalage par rapport à une vue
droit devant.
Les valeurs possibles sont LEFT, RIGHT, CENTER,
ou une valeur spécifiée en degrés.
Utile dans le cas d'un affichage multi-écrans.

==== Options de l'affichage tête haute (HUD) ====

--disable-anti-alias-hud Désactiver l’anticrénelage sur l'affichage
tête-haute (HUD).
--enable-anti-alias-hud Activer l’anticrénelage sur l'affichage tête-haute
(HUD).
--disable-hud Désactiver l'affichage tête-haute (HUD).
--enable-hud Activer l'affichage tête-haute (HUD).
--disable-hud-3d Désactiver l'affichage tête-haute (HUD) en 3D.
--enable-hud-3d Activer l'affichage tête-haute (HUD) en 3D.
--hud-tris Afficher le pourcentage de triangles rendus.
Offre principalement un intérêt pour les
développeurs graphiques.
--hud-culled Afficher le pourcentage de triangles élagués.
Offre principalement un intérêt pour les
développeurs graphiques.

==== Options d'avionique ====

--adf=[radiale:]fréquence Régler la fréquence radio ADF, éventuellement
précédée d'une radiale.
--com1=frequency Régler la fréquence radio COM1.
--com2=frequency Régler la fréquence radio COM2.
--dme={nav1|nav2|fréquence} Asservir l'ADF sur l'une des radios NAV, ou
définir sa fréquence interne.
--failure=système Simuler la panne d'un système avionique spécifique.
Les valeurs valides sont pitot, static, vacuum,
electrical. Spécifier cette option plusieurs fois
pour provoquer des pannes multiples.
--nav1=[radiale:]fréquence Régler la fréquence radio NAV1, éventuellement
précédée d'une radiale.
--nav2=[radiale:]fréquence Régler la fréquence radio NAV2, éventuellement
précédée d'une radiale.

==== Options du temps ====

--disable-clock-freeze Fonctionnement normal de l'horloge.
--enable-clock-freeze Gel de l'horloge.
--start-date-sys=aaaa:mm:jj:hh:mm:ss
Spécifier la date et l'heure au démarrage en prenant
comme référence l'heure de votre système.
--start-date-gmt=aaaa:mm:jj:hh:mm:ss
Spécifier la date et l'heure au démarrage en prenant
comme référence le fuseau horaire de Greenwich.
--start-date-lat=aaaa:mm:jj:hh:mm:ss
Spécifier la date et l'heure au démarrage en prenant
comme référence le fuseau horaire où se trouve l'avion.
--time-match-real Synchroniser l'horloge sur l'heure internationale.
--time-match-local Synchronise l'horloge sur l'heure locale.
--time-offset=[+-]hh:mm:ss Spécifier un décalage de l'heure par rapport à
la référence ; cette dernière dépend des autres
options choisies.
--timeofday=param Spécifier le moment de la journée. Les paramètres
valides sont real (heure réelles), dawn (aube),
morning (matin), noon (midi), afternoon (afternoon),
dusk (crépuscule), evening (soir), midnight (nuit).

==== Options réseau ====

--multiplay={in|out},hz,adresse,port
Spécifier les paramètres de communication multi-pilote ;
plusieurs instances peuvent être utilisées.
--callsign Attribuer un nom unique à un joueur.
--httpd=port Activer le serveur http sur le port spécifié.
--telnet=port Activer le serveur telnet sur le port spécifié.
--jpg-httpd=port Activer le serveur http de capture d'écran sur
le port spécifié
--proxy=[user:password@]host:port
Spécifier un serveur proxy à utiliser.

==== Options de route / points de passage ====

--wp=ID[@alt] Spécifier un point de passage pour le pilote
automatique ; il est possible de spécifier
plusieurs points de passage (donc une route)
par l'intermédiaire de plusieurs instances de
cette commande.
--flight-plan=fichier Lire tous les points de passage depuis un fichier.
NB: Ces options sont plutôt destinées aux utilisateurs avancés qui savent ce qu'ils font.

==== Options d'entrée/sortie ====

--atlas=params Ouvrir une connexion en utilisant le protocole
Atlas (utilisé par Atlas et TerraSync).
--atcsim=params Ouvrir une connexion en utilisant le protocole
ATC Sim (atc610x).
--AV400=params Ouvrir une connexion pour piloter un GPS Garmin
série 196/296.
--generic=params Ouvrir une connexion en utilisant le protocole
générique (défini par XML).
--garmin=params Ouvrir une connexion en utilisant le protocole
GPS Garmin.
--joyclient=params Ouvrir une connexion à un joystick Agwagon.
--jsclient=params Ouvrir la connexion à un joystick distant.
--native-ctrls=params Ouvrir une connexion en utilisant le protocole
de commande natif de FG.
--native-fdm=params Ouvrir une connexion en utilisant le protocole
FDM natif de FG.
--native-gui=params Ouvrir une connexion en utilisant le protocole
FDM natif de FG.
--native=params Ouvrir une connexion en utilisant le protocole
natif de l'interface graphique utilisateur.
--nmea=params Ouvrir une connexion en utilisant le protocole NMEA.
--opengc=params Ouvrir une connexion en utilisant le protocole OpenGC.
--props=params Ouvrir une connexion en utilisant le gestionnaire
interactif de propriétés.
--pve=params Ouvrir une connexion en utilisant le protocole PVE.
--ray=params Ouvrir une connexion en utilisant le protocole
du siège mobile de Ray Woodworth.
--rul=params Ouvrir une connexion en utilisant le protocole RUL.

Sous Windows, vous devez utiliser une séquence d'échappement spécifique si vous voulez spécifier un port COM supérieur à 9.

Par exemple : --generic=\\.\COM10,out,1,/tmp/data.xml,myproto

Ceci est issu de l'article Microsoft KB suivant : http://msdn.microsoft.com/en-us/library/aa363858%28v=vs.85%29.aspx

==== Options de mise au point (debug) ====

--enable-fpe Activer l'arrêt sur exception de virgule flottante.
--fgviewer Au lieu de charger le simulateur complet, charger
un espion OSG léger ; utile pour vérifier des
modèles d'aéronefs.
--log-level=niveau Régler le niveau de journalisation. Les valeurs
valides sont bulk, debug, info, warn, alert.
--prop:[type:]name=value Assigner une valeur à une propriété.
--trace-read=prop Trace les lectures d'une propriété donnée ;
plusieurs instances sont autorisées.
--trace-write=property Trace les écritures d'une propriété donnée ;
plusieurs instances sont autorisées.

[[FlightGear 1.0 aircraft names for command line | Les noms des avions FlightGear 1.0 pour la ligne de commande]] peuvent être utiles selon la version et les avions installés.

[[Category:Lists]]

[[de:Command Line Options]]
[[en:Command Line Options]]

TerraGear CORINE

2016-07-21T17:05:41Z

F-ojac: Fixing with proper filename.

{{Main article|CORINE}}

= '''Building Europe scenery with SRTM v4, Corine landclass and OpenStreetMap data''' =

This is intended to complete and add up-to-date information on the [[Using TerraGear]] tutorial.

Important note: In case you want to contribute to official FlightGear Scenery: Some data sources mentioned in this tutorial are '''not compatible with FlightGear GPL licence'''. Scenery created with SRTM 4 elevation data from CGIAR (no commercial use) can’t be released under GPL terms and therefore unfortunately can not come to official scenery releases.

I will assume you are using the Linux build of Terragear. For instructions on how to get it compiled and installed, see [[Building terragear-cs in Ubuntu 64]]
Replace all paths where appropriate.

First step after you have finished compiling terragear is to go to the file '''BuildTiles/Main/main.cxx''' and make sure CPU '''rlimit''' is a large number. I suggest 600000, this will let fgfs-construct run for almost a week. If you don't perform this check '''fgfs-construct''' will exit with error after a short time.
Make sure you edit the right values, there are two sets one below another. The first ones are not used.

== ''Acquiring data'' ==

=== I. Elevation ===
Note: SRTM version 4 is an updated and free available elevation dataset by CGIAR. Unfortunately the licence is not compatible with FlightGear GPL licence, when you’re going to use this data for scenery creation it can not come to official scenery releases. When you want to use GPL compliant data please download elevation data from USGS (SRTM 3, version 2_1).

SRTM 4 Download:
[http://srtm.geog.kcl.ac.uk/portal/srtm41/elevation.kmz this file] and open it in Google Earth.
In Temporary Places select elevation and choose the 5x5 degrees tiles or the 1x1 degrees subtiles.
Make sure you download GEOTIFF files. I suggest doing 10x10 degrees areas, this means 4 files. It takes longer to compile scenery but on the whole the process is more efficient. Later you will see why.

Better suggestion for up-to-date data would be to use the heightmaps (1" and 3") from [http://www.viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm viewfinderpanoramas.org]
FlightGear is not listed in the list of ''individuals and sites that have contributed to, acknowledged use of, or discussed products on this site'' so it might be best to credit him invidually for the moment if you plan on using that site.

=== II. Landmass ===
Get VMAP0 landmass from [http://mapserver.flightgear.org/download.psp here] (v0_landmass) for the 10 by 10 degrees terrain area you selected. Alternatively use other sources for landmass areas like [http://openstreetmapdata.com/data/land-polygons OpenStreetMap Data Land Polygons] Download the biggest file and if you are not trying to build the world in one go, use ''ogr2ogr'' to make yourself a suitable slice:
./ogr2ogr -clipsrc 21.2695 57.4568 28.3887 60.0539 land_polygons_slice.shp land_polygons.shp

=== III. Corine landclass ===
Get the full Corine set from [http://www.eea.europa.eu/data-and-maps/data/clc-2006-vector-data-version-3]

=== IV. Road, railroad and coastline data ===
Download shapefiles only for countries inside the 10x10 tile from [http://download.geofabrik.de/osm/ here].
This will give you roads and railroads. For coastline, go to [http://downloads.cloudmade.com/ this site].
Download the same files for your country but you will only use coastline for landmass adjustments.

Other datasources can be found [http://wiki.openstreetmap.org/wiki/Planet.osm here].

== Preparing data ==

=== I. Elevation ===
:Assuming you are following the directory structure from [[Using TerraGear]] , run '''srtmchop''' on each TIF file from data/srtm.
There is a catch here: work/SRTM-3 has to be named exactly like that. Otherwise '''genapts''' won't find the elevation required for airport surfaces. This name is hardcoded inside the program.

I suggest to run '''srtmchop''' manually for each file to check for errors.
Ignore warnings generated, some header data cannot be decoded correctly but it won't affect the result.

:On certain TIF files, '''srtmchop''' will terminate with a memory free() error. We have not figured yet what causes this error only on some files. Until a fix is commited to GIT, you can run srtmchop through '''valgrind''':
valgrind --leak-check=yes ./srtmchop <file> <output dir>
This will stop the program from exiting and will get the job done, albeit 10 times slower.

:After you are finished with generating arr files, you can run '''terrafit.py''':
./terrafit.py -m 50 -x 4000 -e 2 work/SRTM-3

=== II. Airports ===
:This is a tedious step. '''genapts''' has to be run for each airport inside your 10x10 degree area. Copy '''apt.dat.gz''' from fgdata/Airports to data/airports. Extract it. For a quick look of which airports are in your area, open [http://bbs.keyhole.com/ubb/ubbthreads.php?ubb=download&Number=77221&filename=168950-ICAO.kmz this file] in Google Earth and remove all other markers, also check view -> grid in menu.
It is best to make a list and iterate through each of the elements. Make sure you have all .arr and .fit files inside work/SRTM-3.

#!/bin/sh
for i in LROP LRBS LRSB
do
./genapts --input=./data/airports/apt.dat --work=./work --airport=$i
done

=== III. Landcover ===
First open the SRTM files as raster layers in QGis. Edit project properties to set on the fly CRS transformation.

:SRTM will serve as a cropping aid, so you can crop the other layers to the size needed.
Edit properties for each SRTM layer and set transparency well above 50% so you can see other layers.
After that open each Corine shapefile and make sure the layer really has elements in your area. Not all layers may have. Use the select tool to select a rectangle around SRTM borders.
Right click on layer and choose Save Selection As.

:After cropping all needed layers, open them again and reproject on WGS84. Perform this operation from the menu Vector -> Data management tools-> Export to new projection. This step may not be necessary as I could gather from the source code, but it's easier to work with all data on the same projection.

:Next you will need to move all files for a layer to its own directory inside data/shapefiles. You can perform mapping between Corine classes this way too. For instance I have put all shapefiles for "Green urban areas" in "DeciduousBroadCover" so urban green areas are filled with trees. You can put several shapefiles inside a data/shapefile/*** directory and they will be processed as the same material. You can get creative with roads too, put Corine polygons for roads, railroads etc. inside GrassCover or DeciduousForest, so OSM roads will have a buffer around them made up of trees or grass.

:One problem I have faced with Corine is that "Continuous urban fabric" which is mapped to Urban is simply not present in my area. To avoid having only Towns, you can create a new layer in QGis and open the "Discontinuous urban fabric" layer (112) at the same time. Select edit mode for both layers, go to options and set the program to only show vectors from selected area. Then, select cities you would like to be mapped to Urban by holding down CTRL. After you are done, cut the selected polys and paste them into the new layer. Now you have both Town and Urban.

:You can then open roads and railroads from OSM and make sure they are ok and have WSG84 as CRS.
One big issue is that '''fgfs-construct''' can't handle big street networks. To eliminate them and reduce scene complexity, open the attribute table for the shapefile. Search for features of type "residential", "track", "path", "pedestrian", "footway", "service", "steps" and other unimportant features. Once selected, delete these lines to simplify the shapefile. The process of deleting these features could take a long type if the number is large. During this time QGis may appear to be frozen. If you need something quickier (expecially with large shape files) you can use the utility ogr2ogr to select only the shape you want to keep:
./ogr2ogr -where "type in ('motorway','motorway_link','primary','primary_link','secondary','secondary_link','tertiary','tertiary_link','trunk','trunk_link','road','rest_area')" roads_new.shp roads.shp

Try to simplify the Road shapefile as much as you can, eliminating dense areas of streets. This way you will also decrease your build time. The roads will be simulated by the urban shader anyway.
If you have to correct the coastline, open v0_landmass in QGis and the coastline shapefile from OSM.
In edit mode you can modify landmass shape to conform to OSM data.

When all shapefiles are arranged properly inside the directory structure, you can run '''ogr-decode''' and set materials. But first you may have to edit default_priorities.txt and usgsmap.txt in share/TerraGear to add missing landclasses. Check with materials.xml and [[CORINE to materials mapping]]

On normal polygon shapefiles '''ogr-decode''' takes the usual parameters:
./ogr-decode --max-segment 500 --area-type Default work/Landmass data/shapefiles/v0_landmass
For roads and railroads, add a third option: '''--line-width 10'''
Streams will be covered by Corine polys so don't worry about that.

<s>When building roads and/or railroads, ogr-decode may terminate with some error because elements do not have the correct coordinates. If it does, check the work directory, chances are most of the polys in your area have compiled fine and you don't need to worry about it.</s>
To prevent bogus data from killing ogr-decode, you may patch the following file in two places:
'''terragear/src/Lib/terragear/tg_chopper.cxx'''

:Line 85 replace with:

if ( (dx > 2880) || (dy > 1440) )
//throw sg_exception("something is really wrong in split_polygon()!!!!");
return;

Bogus data will be skipped, ogr-decode will continue.
In order to use OSM road data at maximum potential, you can also use SQL-like queries on the dataset using the '''--where''' option.
Eg:

./ogr-decode --max-segment 500 --line-width 12 --area-type Freeway --where "TYPE=trunk" work/Freeway data/shapefiles/road

./ogr-decode --max-segment 500 --line-width 14 --area-type Freeway --where "TYPE=motorway" work/Freeway data/shapefiles/road

./ogr-decode --max-segment 500 --line-width 10 --area-type Road --where "TYPE=primary" work/Road data/shapefiles/road

./ogr-decode --max-segment 500 --line-width 7 --area-type Road --where "TYPE!=primary AND TYPE!=motorway AND TYPE!=trunk" work/Road data/shapefiles/road

These are suggested road and freeway widths for SE Europe. Your local mileage may vary. At this time, Road and Freeway are mapped as the same material in materials.xml but that may change in the future so build your scenery with that in mind.

According to which lines have been tagged in OSM data, you could even extract bridge segments and asign them a specific landclass which can then have the physical model of a bridge (this may require some hardcoding to ensure proper orientation).

In order to proceed with your own custom landclass mappings, you should also edit the following files to insert your own:
'''install/terragear-cs/share/TerraGear/default_priorities.txt''' and
'''install/terragear-cs/share/TerraGear/usgsmap.txt'''

(local paths may vary according to your own installation)

=== Build process ===
If all data has been prepared without errors, check inside each directory in work/ and delete folders which do not fit your 10x10 degree tiles.
Time to run fgfs-construct and generate the scenery. This may take a very long time depending on your machine, so let it run over the night.

./fgfs-construct --work-dir=./../work --output-dir=./../output --lon=XX --lat=XX --xdist=5 --ydist=5 \
AirportArea AirportObj BarrenCover BuiltUpCover CropGrassCover \
CropWoodCover DeciduousBroadCover DryCropPastureCover EvergreenBroadCover \
GolfCourse GrassCover HerbTundraCover IrrCropPastureCover Lake Landmass Marsh MixedCropPastureCover\
MixedForestCover OpenMining \
Road Railroad Rock Sand ShrubCover SRTM-3 Stream Town Urban Freeway

The whole process can take 2-3 full days to complete. Still, it is possible to have the whole Europe in one or two months.

== General comments from forum discussion ==
{{cquote|f-ojac, you are right, the parameters used in scenery 2.0 were "-e 5 -x 20000" according to the wiki. I don't know why I had the impression these parameters were not public. In any case, it does not matter because using the same parameters will create closer results, but they are not guaranteed to be the same.

The parameters used to create scenery 2,0 seem to be:

-m ??: the minimum number of vertices in a tile. In FG, any number bellow 100 (and probably, any number below 1000) will do. I don't think there is any surface on the world perfectly flat for several kilometers. The default value is 50 and I'm sure is ok for any normal use.
-e 5: the max allowed error for elevation, in meters. That is: if terrafit calculates a simplification of the terrain where all points are at most this distance from the real elevation, no more vertices are created. The default value is 40 meters: a point may have an elevation error up to 40m (~100ft) High values for this parameter create less detailed mountains and smaller (in disk size) and more efficient (in FPS) terrain.
-x 20000: the max number of vertices in a tile. If this number of vertices is reached, terrafit stop regardless the max error of the vertices. The default value is 1000

Keep in mind you can set values that do not make sense:

* "-e 1 -x 100" does not make sense because it is going to be impossible to calculate errors less than 1 meters using only 100 vertices. The max number of vertices will be reached always and the max error will be probably ignored.
* "-e 300 -x 20000" does not make sense, tiles are going to use for sure much less vertices than 20,000 because you are allowing huge elevation errors.

If you want an efficient scenery (less vertices), use the default values "-e 40 -x 1000". If you want more accurate elevation at the cost of disk space and FPS, use values similar to scenery 2.0 ("-e 5 -x 20000") Anything in the middle will produce performance and disk use in the middle.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=5&t=24681#p225363
|title=Re: Terrasync Help (surprinsingly!) :)
|author=ludomotico |date= Mon Nov 24, 2014 4:28 am}}</ref>|ludomotico}}

<references/>

{{Terra}}

[[Category:Scenery enhancement]]
[[fr:TerraGear CORINE]]

User:F-ojac

2016-07-21T16:27:33Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material !! Final EUR/FR choice
|-
| 244/Agro-forestry areas || *_agroforest || AgroForest || CLC
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts) || XPlane via genapts
|-
| None || *_asphalt || Aspĥalt || None
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover || CLC
|-
| 412/Peat bogs || *_bog || Bog || CLC
|-
| 334/Burnt areas || *_burnt || Burnt || CLC
|-
| None || *_canal || Canal || None
|-
| None || *_cemetery || Cemetery || None
|-
| 242/Complex cultivation patterns || *_complexcrop || ComplexCrop || CLC
|-
| 133/Construction sites || *_construction || Construction || CLC
|-
| 243/Principally occupied by agriculture, with significant natural vegetation || *_cropgrass || CropGrass || CLC
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest || CLC
|-
| None || *_default || Default || None
|-
| None || *_dirt || Dirt || None
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop || CLC
|-
| 132/Dump sites || *_dump || Dump || CLC
|-
| 522/Estuaries || *_estuary || Estuary || CLC
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest || CLC
|-
| None || *_floodland || FloodLand || None
|-
| 122/Road and rail networks and associated land || *_freeway || Freeway || OSM
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier || CLC
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse || CLC
|-
| 321/Natural grasslands || *_grassland || Grassland || CLC
|-
| 141/Green urban areas || *_greenspace || Greenspace || CLC
|-
| 322/Moors and heathland || *_heath || Heath || CLC
|-
| None || *_herbtundra || HerbTundra || None
|-
| 121/Industrial or commercial units || *_industrial || Industrial || CLC
|-
| None || *_intermittentlake || IntermittentLake || None
|-
| None || *_intermittentstream || IntermittentStream || None
|-
| 212/Permanently irrigated land || *_irrcrop || IrrCrop || CLC
|-
| 521/Coastal lagoons || *_lagoon || Lagoon || CLC
|-
| 512/Water bodies || *_lake || Lake || CLC
|-
| None || *_landmass || Default || None
|-
| None || *_lava || Lava || None
|-
| 122/Road and rail networks and associated land || *_light_rail || Railroad || OSM
|-
| 423/Intertidal flats|| *_littoral || Littoral || CLC
|-
| 411/Inland marshes || *_marsh || Marsh || CLC
|-
| 241/Annual crops associated with permanent crops || *_mixedcrop || MixedCrop || CLC
|-
| 313/Mixed forest || *_mixedforest || MixedForest || CLC
|-
| 122/Road and rail networks and associated land || *_motorway || Freeway || OSM
|-
| 231/Pastures || *_naturalcrop || NaturalCrop || OSM
|-
| 523/Sea and ocean || *_ocean || Ocean || CLC
|-
| 223/Olive groves || *_olives || Olives || CLC
|-
| 131/Mineral extraction site || *_openmining || OpenMining || CLC
|-
| 222/Fruit trees and berry plantations || *_orchard || Orchard || CLC
|-
| None || *_packice || PackIce || None
|-
| None || *_polarice || PolarIce || None
|-
| 123/Port areas || *_port || Port || CLC
|-
| 122/Road and rail networks and associated land || *_primary || Road || OSM
|-
| 122/Road and rail networks and associated land || *_rail || Railroad || OSM
|-
| 122/Road and rail networks and associated land || *_railroad1 || Railroad || OSM
|-
| 122/Road and rail networks and associated land || *_railroad2 || Railroad || OSM
|-
| None || *_rainforest || RainForest || None
|-
| 122/Road and rail networks and associated land || *_residential || Road || OSM
|-
| 213/Rice fields || *_rice || Rice || CLC
|-
| None || *_river || Canal || None
|-
| 122/Road and rail networks and associated land || *_road || Road || OSM
|-
| 332/Bare rocks || *_rock || Rock || CLC
|-
| 422/Salines || *_saline || Saline || CLC
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh || CLC
|-
| 331/Beaches, dunes, sands || *_sand || Sand || CLC
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous || CLC
|-
| 324/Transitional woodland-shrub || *_scrub || ScrubCover || CLC
|-
| 122/Road and rail networks and associated land || *_secondary || Road || OSM
|-
| 122/Road and rail networks and associated land || *_service || Road || OSM
|-
| None || *_stream || Stream || None
|-
| None || *_suburban || Suburban || None
|-
| 122/Road and rail networks and associated land || *_tertiary || Road || OSM
|-
| 112/Discontinuous urban fabric|| *_town || Town || CLC
|-
| 122/Road and rail networks and associated land || *_transport || Transport || OSM
|-
| 122/Road and rail networks and associated land || *_trunk || Road || OSM
|-
| 111/Continuous urban fabric || *_urban || Urban || CLC
|-
| 221/Vineyards || *_vineyard || Vineyard || CLC
|-
| 511/Water courses || *_watercourse || Watercourse || CLC
|}

User:F-ojac

2016-07-21T16:15:02Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material !! Final EUR/FR choice
|-
| 244/Agro-forestry areas || *_agroforest || AgroForest || CLC
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts) || XPlane via genapts
|-
| None || *_asphalt || Aspĥalt || None
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover || CLC
|-
| 412/Peat bogs || *_bog || Bog || CLC
|-
| 334/Burnt areas || *_burnt || Burnt || CLC
|-
| None || *_canal || Canal ||
|-
| None || *_cemetery || Cemetery ||
|-
| 242/Complex cultivation patterns || *_complexcrop || ComplexCrop || CLC
|-
| 133/Construction sites || *_construction || Construction || CLC
|-
| 243/Principally occupied by agriculture, with significant natural vegetation || *_cropgrass || CropGrass || CLC
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest || CLC
|-
| None || *_default || Default || None
|-
| None || *_dirt || Dirt || None
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop || CLC
|-
| 132/Dump sites || *_dump || Dump || CLC
|-
| 522/Estuaries || *_estuary || Estuary || CLC
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest || CLC
|-
| None || *_floodland || FloodLand || None
|-
| 122/Road and rail networks and associated land || *_freeway || Freeway || OSM
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier || CLC
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse || CLC
|-
| 321/Natural grasslands || *_grassland || Grassland || CLC
|-
| 141/Green urban areas || *_greenspace || Greenspace || CLC
|-
| 322/Moors and heathland || *_heath || Heath || CLC
|-
| None || *_herbtundra || HerbTundra || None
|-
| 121/Industrial or commercial units || *_industrial || Industrial || CLC
|-
| None || *_intermittentlake || IntermittentLake || None
|-
| None || *_intermittentstream || IntermittentStream || None
|-
| 212/Permanently irrigated land || *_irrcrop || IrrCrop || CLC
|-
| 521/Coastal lagoons || *_lagoon || Lagoon || CLC
|-
| 512/Water bodies || *_lake || Lake || CLC
|-
| None || *_landmass || Default || None
|-
| None || *_lava || Lava || None
|-
| 122/Road and rail networks and associated land || *_light_rail || Railroad || OSM
|-
| 423/Intertidal flats|| *_littoral || Littoral || CLC
|-
| 411/Inland marshes || *_marsh || Marsh || CLC
|-
| 241/Annual crops associated with permanent crops || *_mixedcrop || MixedCrop || CLC
|-
| 313/Mixed forest || *_mixedforest || MixedForest || CLC
|-
| 122/Road and rail networks and associated land || *_motorway || Freeway || OSM
|-
| 231/Pastures || *_naturalcrop || NaturalCrop || OSM
|-
| 523/Sea and ocean || *_ocean || Ocean || CLC
|-
| 223/Olive groves || *_olives || Olives || CLC
|-
| 131/Mineral extraction site || *_openmining || OpenMining || CLC
|-
| 222/Fruit trees and berry plantations || *_orchard || Orchard || CLC
|-
| None || *_packice || PackIce || None
|-
| None || *_polarice || PolarIce || None
|-
| 123/Port areas || *_port || Port || CLC
|-
| 122/Road and rail networks and associated land || *_primary || Road || OSM
|-
| 122/Road and rail networks and associated land || *_rail || Railroad || OSM
|-
| 122/Road and rail networks and associated land || *_railroad1 || Railroad || OSM
|-
| 122/Road and rail networks and associated land || *_railroad2 || Railroad || OSM
|-
| None || *_rainforest || RainForest || None
|-
| 122/Road and rail networks and associated land || *_residential || Road || OSM
|-
| 213/Rice fields || *_rice || Rice || CLC
|-
| None || *_river || Canal || None
|-
| 122/Road and rail networks and associated land || *_road || Road || OSM
|-
| 332/Bare rocks || *_rock || Rock || CLC
|-
| 422/Salines || *_saline || Saline || CLC
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh || CLC
|-
| 331/Beaches, dunes, sands || *_sand || Sand || CLC
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous || CLC
|-
| 324/Transitional woodland-shrub || *_scrub || ScrubCover || CLC
|-
| 122/Road and rail networks and associated land || *_secondary || Road || OSM
|-
| 122/Road and rail networks and associated land || *_service || Road || OSM
|-
| None || *_stream || Stream
|-
| None || *_suburban || Suburban
|-
| 122/Road and rail networks and associated land || *_tertiary || Road || OSM
|-
| 112/Discontinuous urban fabric|| *_town || Town || CLC
|-
| 122/Road and rail networks and associated land || *_transport || Transport || OSM
|-
| 122/Road and rail networks and associated land || *_trunk || Road || OSM
|-
| 111/Continuous urban fabric || *_urban || Urban || CLC
|-
| 221/Vineyards || *_vineyard || Vineyard || CLC
|-
| 511/Water courses || *_watercourse || Watercourse || CLC
|}

User:F-ojac

2016-07-21T15:53:53Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material
|-
| 244/Agro-forestry areas || *_agroforest || AgroForest
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts)
|-
| None || *_asphalt || Aspĥalt
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover
|-
| 412/Peat bogs || *_bog || Bog
|-
| 334/Burnt areas || *_burnt || Burnt
|-
| None || *_canal || Canal
|-
| None || *_cemetery || Cemetery
|-
| 242/Complex cultivation patterns || *_complexcrop || ComplexCrop
|-
| 133/Construction sites || *_construction || Construction
|-
| 243/Principally occupied by agriculture, with significant natural vegetation || *_cropgrass || CropGrass
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest
|-
| None || *_default || Default
|-
| None || *_dirt || Dirt
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop
|-
| 132/Dump sites || *_dump || Dump
|-
| 522/Estuaries || *_estuary || Estuary
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest
|-
| None || *_floodland || FloodLand
|-
| 122/Road and rail networks and associated land || *_freeway || Freeway
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse
|-
| 321/Natural grasslands || *_grassland || Grassland
|-
| 141/Green urban areas || *_greenspace || Greenspace
|-
| 322/Moors and heathland || *_heath || Heath
|-
| None || *_herbtundra || HerbTundra
|-
| 121/Industrial or commercial units || *_industrial || Industrial
|-
| None || *_intermittentlake || IntermittentLake
|-
| None || *_intermittentstream || IntermittentStream
|-
| 212/Permanently irrigated land || *_irrcrop || IrrCrop
|-
| 521/Coastal lagoons || *_lagoon || Lagoon
|-
| 512/Water bodies || *_lake || Lake
|-
| None || *_landmass || Default
|-
| None || *_lava || Lava
|-
| 122/Road and rail networks and associated land || *_light_rail || Railroad
|-
| 423/Intertidal flats|| *_littoral || Littoral
|-
| 411/Inland marshes || *_marsh || Marsh
|-
| 241/Annual crops associated with permanent crops || *_mixedcrop || MixedCrop
|-
| 313/Mixed forest || *_mixedforest || MixedForest
|-
| 122/Road and rail networks and associated land || *_motorway || Freeway
|-
| 231/Pastures || *_naturalcrop || NaturalCrop
|-
| 523/Sea and ocean || *_ocean || Ocean
|-
| 223/Olive groves || *_olives || Olives
|-
| 131/Mineral extraction site || *_openmining || OpenMining
|-
| 222/Fruit trees and berry plantations || *_orchard || Orchard
|-
| None || *_packice || PackIce
|-
| None || *_polarice || PolarIce
|-
| 123/Port areas || *_port || Port
|-
| 122/Road and rail networks and associated land || *_primary || Road
|-
| 122/Road and rail networks and associated land || *_rail || Railroad
|-
| 122/Road and rail networks and associated land || *_railroad1 || Railroad
|-
| 122/Road and rail networks and associated land || *_railroad2 || Railroad
|-
| None || *_rainforest || RainForest
|-
| 122/Road and rail networks and associated land || *_residential || Road
|-
| 213/Rice fields || *_rice || Rice
|-
| None || *_river || Canal
|-
| 122/Road and rail networks and associated land || *_road || Road
|-
| 332/Bare rocks || *_rock || Rock
|-
| 422/Salines || *_saline || Saline
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh
|-
| 331/Beaches, dunes, sands || *_sand || Sand
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous
|-
| 324/Transitional woodland-shrub || *_scrub || ScrubCover
|-
| 122/Road and rail networks and associated land || *_secondary || Road
|-
| 122/Road and rail networks and associated land || *_service || Road
|-
| None || *_stream || Stream
|-
| None || *_suburban || Suburban
|-
| 122/Road and rail networks and associated land || *_tertiary || Road
|-
| 112/Discontinuous urban fabric|| *_town || Town
|-
| 122/Road and rail networks and associated land || *_transport || Transport
|-
| 122/Road and rail networks and associated land || *_trunk || Road
|-
| 111/Continuous urban fabric || *_urban || Urban
|-
| 221/Vineyards || *_vineyard || Vineyard
|-
| 511/Water courses || *_watercourse || Watercourse
|}

User:F-ojac

2016-07-21T15:40:37Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material
|-
| 244/Agro-forestry areas || *_agroforest || AgroForest
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts)
|-
| None || *_asphalt || Asĥalt
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover
|-
| 412/Peat bogs || *_bog || Bog
|-
| 334/Burnt areas || *_burnt || Burnt
|-
| None || *_canal || Canal
|-
| None || *_cemetery || Cemetery
|-
| 242/Complex cultivation patterns || *_complexcrop || ComplexCrop
|-
| 133/Construction sites || *_construction || Construction
|-
| || *_cropgrass || CropGrass
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest
|-
| None || *_default || Default
|-
| None || *_dirt || Dirt
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop
|-
| 132/Dump sites || *_dump || Dump
|-
| 522/Estuaries || *_estuary || Estuary
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest
|-
| None || *_floodland || FloodLand
|-
| 122/Road and rail networks and associated land || *_freeway || Freeway
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse
|-
| 321/Natural grasslands || *_grassland || Grassland
|-
| 141/Green urban areas || *_greenspace || Greenspace
|-
| 322/Moors and heathland || *_heath || Heath
|-
| None || *_herbtundra || HerbTundra
|-
| 121/Industrial or commercial units || *_industrial || Industrial
|-
| None || *_intermittentlake || IntermittentLake
|-
| None || *_intermittentstream || IntermittentStream
|-
| 212/Permanently irrigated land || *_irrcrop || IrrCrop
|-
| 521/Coastal lagoons || *_lagoon || Lagoon
|-
| 512/Water bodies || *_lake || Lake
|-
| None || *_landmass || Default
|-
| None || *_lava || Lava
|-
| 122/Road and rail networks and associated land || *_light_rail || Railroad
|-
| 423/Intertidal flats|| *_littoral || Littoral
|-
| 411/Inland marshes || *_marsh || Marsh
|-
| 241/Annual crops associated with permanent crops || *_mixedcrop || MixedCrop
|-
| 313/Mixed forest || *_mixedforest || MixedForest
|-
| 122/Road and rail networks and associated land || *_motorway || Freeway
|-
| 231/Pastures || *_naturalcrop || NaturalCrop
|-
| 523/Sea and ocean || *_ocean || Ocean
|-
| 223/Olive groves || *_olives || Olives
|-
| 131/Mineral extraction site || *_openmining || OpenMining
|-
| None || *_orchard || Orchard
|-
| None || *_packice || PackIce
|-
| None || *_polarice || PolarIce
|-
| 123/Port areas || *_port || Port
|-
| 122/Road and rail networks and associated land || *_primary || Road
|-
| 122/Road and rail networks and associated land || *_rail || Railroad
|-
| 122/Road and rail networks and associated land || *_railroad1 || Railroad
|-
| 122/Road and rail networks and associated land || *_railroad2 || Railroad
|-
| || *_rainforest || RainForest
|-
| 122/Road and rail networks and associated land || *_residential || Road
|-
| 213/Rice fields || *_rice || Rice
|-
| || *_river || Canal
|-
| 122/Road and rail networks and associated land || *_road || Road
|-
| 332/Bare rocks || *_rock || Rock
|-
| 422/Salines || *_saline || Saline
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh
|-
| 331/Beaches, dunes, sands || *_sand || Sand
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous
|-
| || *_scrub || ScrubCover
|-
| 122/Road and rail networks and associated land || *_secondary || Road
|-
| 122/Road and rail networks and associated land || *_service || Road
|-
| || *_stream || Stream
|-
| || *_suburban || Suburban
|-
| 122/Road and rail networks and associated land || *_tertiary || Road
|-
| 112/Discontinuous urban fabric|| *_town || Town
|-
| 122/Road and rail networks and associated land || *_transport || Transport
|-
| 122/Road and rail networks and associated land || *_trunk || Road
|-
| 111/Continuous urban fabric || *_urban || Urban
|-
| 221/Vineyards || *_vineyard || Vineyard
|-
| 511/Water courses || *_watercourse || Watercourse
|}

243 Principally occupied by agriculture, with significant natural vegetation CropWoodCover
222/Fruit trees and berry plantations
324 Transitional woodland-shrub ShrubCover

User:F-ojac

2016-07-21T15:30:21Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material
|-
| || *_agroforest || AgroForest
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts)
|-
| || *_asphalt || Asĥalt
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover
|-
| 412/Peat bogs || *_bog || Bog
|-
| 334/Burnt areas || *_burnt || Burnt
|-
| || *_canal || Canal
|-
| || *_cemetery || Cemetery
|-
| || *_complexcrop || ComplexCrop
|-
| 133/Construction sites || *_construction || Construction
|-
| || *_cropgrass || CropGrass
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest
|-
| || *_default || Default
|-
| || *_dirt || Dirt
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop
|-
| 132/Dump sites || *_dump || Dump
|-
| 522 Estuaries || *_estuary || Estuary
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest
|-
| || *_floodland || FloodLand
|-
| || *_freeway || Freeway
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse
|-
| 321/Natural grasslands || *_grassland || Grassland
|-
| 141/Green urban areas || *_greenspace || Greenspace
|-
| 322/Moors and heathland || *_heath || Heath
|-
| || *_herbtundra || HerbTundra
|-
| 121/Industrial or commercial units || *_industrial || Industrial
|-
| || *_intermittentlake || IntermittentLake
|-
| || *_intermittentstream || IntermittentStream
|-
| || *_irrcrop || IrrCrop
|-
| 521/Coastal lagoons || *_lagoon || Lagoon
|-
| 512/Water bodies || *_lake || Lake
|-
| || *_landmass || Default
|-
| || *_lava || Lava
|-
| || *_light_rail || Railroad
|-
| 423/Intertidal flats|| *_littoral || Littoral
|-
| 411/Inland marshes || *_marsh || Marsh
|-
| || *_mixedcrop || MixedCrop
|-
| 313/Mixed forest || *_mixedforest || MixedForest
|-
| || *_motorway || Freeway
|-
| 231/Pastures || *_naturalcrop || NaturalCrop
|-
| 523/Sea and ocean || *_ocean || Ocean
|-
| 223/Olive groves || *_olives || Olives
|-
| 131/Mineral extraction site || *_openmining || OpenMining
|-
| || *_orchard || Orchard
|-
| || *_packice || PackIce
|-
| || *_polarice || PolarIce
|-
| 123/Port areas || *_port || Port
|-
| || *_primary || Road
|-
| || *_rail || Railroad
|-
| || *_railroad1 || Railroad
|-
| || *_railroad2 || Railroad
|-
| || *_rainforest || RainForest
|-
| || *_residential || Road
|-
| 213/Rice fields || *_rice || Rice
|-
| || *_river || Canal
|-
| || *_road || Road
|-
| 332/Bare rocks || *_rock || Rock
|-
| 422/Salines || *_saline || Saline
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh
|-
| 331/Beaches, dunes, sands || *_sand || Sand
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous
|-
| || *_scrub || ScrubCover
|-
| || *_secondary || Road
|-
| || *_service || Road
|-
| || *_stream || Stream
|-
| || *_suburban || Suburban
|-
| || *_tertiary || Road
|-
| 112/Discontinuous urban fabric|| *_town || Town
|-
| || *_transport || Transport
|-
| || *_trunk || Road
|-
| 111/Continuous urban fabric || *_urban || Urban
|-
| 221/Vineyards || *_vineyard || Vineyard
|-
| 511/Water courses || *_watercourse || Watercourse
|}

122 Road and rail networks and associated land
141 Green urban areas Urban
212 Permanently irrigated land IrrCropPastureCover
222 Fruit trees and berry plantations IrrCropPastureCover
241 Annual crops associated with permanent crops
242 Complex cultivation patterns MixedCropPastureCover
243 Principally occupied by agriculture, with significant natural vegetation CropWoodCover
244 Agro-forestry areas
324 Transitional woodland-shrub ShrubCover

User:F-ojac

2016-07-21T15:29:24Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material
|-
| || *_agroforest || AgroForest
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts)
|-
| || *_asphalt || Asĥalt
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover
|-
| 412/Peat bogs || *_bog || Bog
|-
| 334/Burnt areas || *_burnt || Burnt
|-
| || *_canal || Canal
|-
| || *_cemetery || Cemetery
|-
| || *_complexcrop || ComplexCrop
|-
| 133/Construction sites || *_construction || Construction
|-
| || *_cropgrass || CropGrass
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest
|-
| || *_default || Default
|-
| || *_dirt || Dirt
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop
|-
| 132/Dump sites || *_dump || Dump
|-
| 522 Estuaries || *_estuary || Estuary
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest
|-
| || *_floodland || FloodLand
|-
| || *_freeway || Freeway
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse
|-
| 321/Natural grasslands || *_grassland || Grassland
|-
| || *_greenspace || Greenspace
|-
| 322/Moors and heathland || *_heath || Heath
|-
| || *_herbtundra || HerbTundra
|-
| 121/Industrial or commercial units || *_industrial || Industrial
|-
| || *_intermittentlake || IntermittentLake
|-
| || *_intermittentstream || IntermittentStream
|-
| || *_irrcrop || IrrCrop
|-
| 521/Coastal lagoons || *_lagoon || Lagoon
|-
| 512/Water bodies || *_lake || Lake
|-
| || *_landmass || Default
|-
| || *_lava || Lava
|-
| || *_light_rail || Railroad
|-
| 423/Intertidal flats|| *_littoral || Littoral
|-
| 411/Inland marshes || *_marsh || Marsh
|-
| || *_mixedcrop || MixedCrop
|-
| 313/Mixed forest || *_mixedforest || MixedForest
|-
| || *_motorway || Freeway
|-
| 231/Pastures || *_naturalcrop || NaturalCrop
|-
| 523/Sea and ocean || *_ocean || Ocean
|-
| 223/Olive groves || *_olives || Olives
|-
| 131/Mineral extraction site || *_openmining || OpenMining
|-
| || *_orchard || Orchard
|-
| || *_packice || PackIce
|-
| || *_polarice || PolarIce
|-
| 123/Port areas || *_port || Port
|-
| || *_primary || Road
|-
| || *_rail || Railroad
|-
| || *_railroad1 || Railroad
|-
| || *_railroad2 || Railroad
|-
| || *_rainforest || RainForest
|-
| || *_residential || Road
|-
| 213/Rice fields || *_rice || Rice
|-
| || *_river || Canal
|-
| || *_road || Road
|-
| 332/Bare rocks || *_rock || Rock
|-
| 422/Salines || *_saline || Saline
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh
|-
| 331/Beaches, dunes, sands || *_sand || Sand
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous
|-
| || *_scrub || ScrubCover
|-
| || *_secondary || Road
|-
| || *_service || Road
|-
| || *_stream || Stream
|-
| || *_suburban || Suburban
|-
| || *_tertiary || Road
|-
| 112/Discontinuous urban fabric|| *_town || Town
|-
| || *_transport || Transport
|-
| || *_trunk || Road
|-
| 111/Continuous urban fabric || *_urban || Urban
|-
| 221/Vineyards || *_vineyard || Vineyard
|-
| 511/Water courses || *_watercourse || Watercourse
|}

122 Road and rail networks and associated land
141 Green urban areas Urban
212 Permanently irrigated land IrrCropPastureCover
222 Fruit trees and berry plantations IrrCropPastureCover
241 Annual crops associated with permanent crops
242 Complex cultivation patterns MixedCropPastureCover
243 Principally occupied by agriculture, with significant natural vegetation CropWoodCover
244 Agro-forestry areas
324 Transitional woodland-shrub ShrubCover

User:F-ojac

2016-07-21T15:25:06Z

F-ojac:

{| class="wikitable"
|-
! CLC Code/Class name !! CS Shape !! CS/FG Material
|-
| Example || *_agroforest || AgroForest
|-
| 124/Airports || *_airport || Airport (will be overriden by genapts)
|-
| Example || *_asphalt || Asĥalt
|-
| 333/Sparsely vegetated areas || *_barrencover || BarrenCover
|-
| 412/Peat bogs || *_bog || Bog
|-
| 334/Burnt areas || *_burnt || Burnt
|-
| Example || *_canal || Canal
|-
| Example || *_cemetery || Cemetery
|-
| Example || *_complexcrop || ComplexCrop
|-
| 133/Construction sites || *_construction || Construction
|-
| Example || *_cropgrass || CropGrass
|-
| 311/Broad-leaved forest || *_deciduousforest || DeciduousForest
|-
| Example || *_default || Default
|-
| Example || *_dirt || Dirt
|-
| 211/Non-irrigated arable land || *_drycrop || DryCrop
|-
| 132/Dump sites || *_dump || Dump
|-
| Example || *_estuary || Estuary
|-
| 312/Coniferous forest || *_evergreenforest || EvergreenForest
|-
| Example || *_floodland || FloodLand
|-
| Example || *_freeway || Freeway
|-
| 335/Glaciers and perpetual snow || *_glacier || Glacier
|-
| 142/Sport and leisure facilities || *_golfcourse || GolfCourse
|-
| 321/Natural grasslands || *_grassland || Grassland
|-
| Example || *_greenspace || Greenspace
|-
| 322/Moors and heathland || *_heath || Heath
|-
| Example || *_herbtundra || HerbTundra
|-
| 121/Industrial or commercial units || *_industrial || Industrial
|-
| Example || *_intermittentlake || IntermittentLake
|-
| Example || *_intermittentstream || IntermittentStream
|-
| Example || *_irrcrop || IrrCrop
|-
| 521/Coastal lagoons || *_lagoon || Lagoon
|-
| 512/Water bodies || *_lake || Lake
|-
| Example || *_landmass || Default
|-
| Example || *_lava || Lava
|-
| Example || *_light_rail || Railroad
|-
| 423/Intertidal flats|| *_littoral || Littoral
|-
| 411/Inland marshes || *_marsh || Marsh
|-
| Example || *_mixedcrop || MixedCrop
|-
| 313/Mixed forest || *_mixedforest || MixedForest
|-
| Example || *_motorway || Freeway
|-
| 231/Pastures || *_naturalcrop || NaturalCrop
|-
| 523/Sea and ocean || *_ocean || Ocean
|-
| 223/Olive groves || *_olives || Olives
|-
| 131/Mineral extraction site || *_openmining || OpenMining
|-
| Example || *_orchard || Orchard
|-
| Example || *_packice || PackIce
|-
| Example || *_polarice || PolarIce
|-
| 123/Port areas || *_port || Port
|-
| Example || *_primary || Road
|-
| Example || *_rail || Railroad
|-
| Example || *_railroad1 || Railroad
|-
| Example || *_railroad2 || Railroad
|-
| Example || *_rainforest || RainForest
|-
| Example || *_residential || Road
|-
| 213/Rice fields || *_rice || Rice
|-
| Example || *_river || Canal
|-
| Example || *_road || Road
|-
| 332/Bare rocks || *_rock || Rock
|-
| 422/Salines || *_saline || Saline
|-
| 421/Salt marshes || *_saltmarsh || SaltMarsh
|-
| 331/Beaches, dunes, sands || *_sand || Sand
|-
| 323/Sclerophyllous vegetation || *_sclerophyllous || Sclerophyllous
|-
| Example || *_scrub || ScrubCover
|-
| Example || *_secondary || Road
|-
| Example || *_service || Road
|-
| Example || *_stream || Stream
|-
| Example || *_suburban || Suburban
|-
| Example || *_tertiary || Road
|-
| 112/Discontinuous urban fabric|| *_town || Town
|-
| Example || *_transport || Transport
|-
| Example || *_trunk || Road
|-
| 111/Continuous urban fabric || *_urban || Urban
|-
| 221/Vineyards || *_vineyard || Vineyard
|-
| 511/Water courses || *_watercourse || Watercourse
|}

122 Road and rail networks and associated land
141 Green urban areas Urban
212 Permanently irrigated land IrrCropPastureCover
222 Fruit trees and berry plantations IrrCropPastureCover
241 Annual crops associated with permanent crops
242 Complex cultivation patterns MixedCropPastureCover
243 Principally occupied by agriculture, with significant natural vegetation CropWoodCover
244 Agro-forestry areas
324 Transitional woodland-shrub ShrubCover
522 Estuaries Ocean

User:F-ojac

2016-07-21T14:57:03Z

F-ojac:

{| class="wikitable"
|-
! CLC !! CS Shape !! CS/FG Material
|-
| Example || *_agroforest || AgroForest
|-
| Example || *_airport || Airport
|-
| Example || *_asphalt || Asĥalt
|-
| Example || *_barrencover || BarrenCover
|-
| Example || *_bog || Bog
|-
| Example || *_burnt || Burnt
|-
| Example || *_canal || Canal
|-
| Example || *_cemetery || Cemetery
|-
| Example || *_complexcrop || ComplexCrop
|-
| Example || *_construction || Construction
|-
| Example || *_cropgrass || CropGrass
|-
| Example || *_deciduousforest || DeciduousForest
|-
| Example || *_default || Default
|-
| Example || *_dirt || Dirt
|-
| Example || *_drycrop || DryCrop
|-
| Example || *_dump || Dump
|-
| Example || *_estuary || Estuary
|-
| Example || *_evergreenforest || EvergreenForest
|-
| Example || *_floodland || FloodLand
|-
| Example || *_freeway || Freeway
|-
| Example || *_glacier || Glacier
|-
| Example || *_golfcourse || GolfCourse
|-
| Example || *_grassland || Grassland
|-
| Example || *_greenspace || Greenspace
|-
| Example || *_heath || Heath
|-
| Example || *_herbtundra || HerbTundra
|-
| Example || *_industrial || Industrial
|-
| Example || *_intermittentlake || IntermittentLake
|-
| Example || *_intermittentstream || IntermittentStream
|-
| Example || *_irrcrop || IrrCrop
|-
| Example || *_lagoon || Lagoon
|-
| Example || *_lake || Lake
|-
| Example || *_landmass || Default
|-
| Example || *_lava || Lava
|-
| Example || *_light_rail || Railroad
|-
| Example || *_littoral || Littoral
|-
| Example || *_marsh || Marsh
|-
| Example || *_mixedcrop || MixedCrop
|-
| Example || *_mixedforest || MixedForest
|-
| Example || *_motorway || Freeway
|-
| Example || *_naturalcrop || NaturalCrop
|-
| Example || *_ocean || Ocean
|-
| Example || *_olives || Olives
|-
| Example || *_openmining || OpenMining
|-
| Example || *_orchard || Orchard
|-
| Example || *_packice || PackIce
|-
| Example || *_polarice || PolarIce
|-
| Example || *_port || Port
|-
| Example || *_primary || Road
|-
| Example || *_rail || Railroad
|-
| Example || *_railroad1 || Railroad
|-
| Example || *_railroad2 || Railroad
|-
| Example || *_rainforest || RainForest
|-
| Example || *_residential || Road
|-
| Example || *_rice || Rice
|-
| Example || *_river || Canal
|-
| Example || *_road || Road
|-
| Example || *_rock || Rock
|-
| Example || *_saline || Saline
|-
| Example || *_saltmarsh || SaltMarsh
|-
| Example || *_sand || Sand
|-
| Example || *_sclerophyllous || Sclerophyllous
|-
| Example || *_scrub || ScrubCover
|-
| Example || *_secondary || Road
|-
| Example || *_service || Road
|-
| Example || *_stream || Stream
|-
| Example || *_suburban || Suburban
|-
| Example || *_tertiary || Road
|-
| Example || *_town || Town
|-
| Example || *_transport || Transport
|-
| Example || *_trunk || Road
|-
| Example || *_urban || Urban
|-
| Example || *_vineyard || Vineyard
|-
| Example || *_watercourse || Watercourse
|}

User:F-ojac

2016-07-21T14:56:13Z

F-ojac:

{| class="wikitable"
|-
! CLC !! CS Shape !! CS Material
|-
| Example || *_agroforest || AgroForest
|-
| Example || *_airport || Airport
|-
| Example || *_asphalt || Asĥalt
|-
| Example || *_barrencover || BarrenCover
|-
| Example || *_bog || Bog
|-
| Example || *_burnt || Burnt
|-
| Example || *_canal || Canal
|-
| Example || *_cemetery || Cemetery
|-
| Example || *_complexcrop || ComplexCrop
|-
| Example || *_construction || Construction
|-
| Example || *_cropgrass || CropGrass
|-
| Example || *_deciduousforest || DeciduousForest
|-
| Example || *_default || Default
|-
| Example || *_dirt || Dirt
|-
| Example || *_drycrop || DryCrop
|-
| Example || *_dump || Dump
|-
| Example || *_estuary || Estuary
|-
| Example || *_evergreenforest || EvergreenForest
|-
| Example || *_floodland || FloodLand
|-
| Example || *_freeway || Freeway
|-
| Example || *_glacier || Glacier
|-
| Example || *_golfcourse || GolfCourse
|-
| Example || *_grassland || Grassland
|-
| Example || *_greenspace || Greenspace
|-
| Example || *_heath || Heath
|-
| Example || *_herbtundra || HerbTundra
|-
| Example || *_industrial || Industrial
|-
| Example || *_intermittentlake || IntermittentLake
|-
| Example || *_intermittentstream || IntermittentStream
|-
| Example || *_irrcrop || IrrCrop
|-
| Example || *_lagoon || Lagoon
|-
| Example || *_lake || Lake
|-
| Example || *_landmass || Default
|-
| Example || *_lava || Lava
|-
| Example || *_light_rail || Railroad
|-
| Example || *_littoral || Littoral
|-
| Example || *_marsh || Marsh
|-
| Example || *_mixedcrop || MixedCrop
|-
| Example || *_mixedforest || MixedForest
|-
| Example || *_motorway || Freeway
|-
| Example || *_naturalcrop || NaturalCrop
|-
| Example || *_ocean || Ocean
|-
| Example || *_olives || Olives
|-
| Example || *_openmining || OpenMining
|-
| Example || *_orchard || Orchard
|-
| Example || *_packice || PackIce
|-
| Example || *_polarice || PolarIce
|-
| Example || *_port || Port
|-
| Example || *_primary || Road
|-
| Example || *_rail || Railroad
|-
| Example || *_railroad1 || Railroad
|-
| Example || *_railroad2 || Railroad
|-
| Example || *_rainforest || RainForest
|-
| Example || *_residential || Road
|-
| Example || *_rice || Rice
|-
| Example || *_river || Canal
|-
| Example || *_road || Road
|-
| Example || *_rock || Rock
|-
| Example || *_saline || Saline
|-
| Example || *_saltmarsh || SaltMarsh
|-
| Example || *_sand || Sand
|-
| Example || *_sclerophyllous || Sclerophyllous
|-
| Example || *_scrub || ScrubCover
|-
| Example || *_secondary || Road
|-
| Example || *_service || Road
|-
| Example || *_stream || Stream
|-
| Example || *_suburban || Suburban
|-
| Example || *_tertiary || Road
|-
| Example || *_town || Town
|-
| Example || *_transport || Transport
|-
| Example || *_trunk || Road
|-
| Example || *_urban || Urban
|-
| Example || *_vineyard || Vineyard
|-
| Example || *_watercourse || Watercourse
|}

User:F-ojac

2016-07-21T14:52:36Z

F-ojac:

{| class="wikitable"
|-
! CLC !! CS Shape !! CS Material
|-
| Example || *_agroforest || AgroForest
|-
| Example || *_airport || Airport
|-
| Example || *_asphalt || Asĥalt
|-
| Example || *_barrencover || BarrenCover
|-
| Example || *_bog || Bog
|-
| Example || *_burnt || Burnt
|-
| Example || *_canal || Canal
|-
| Example || *_cemetery || Cemetery
|-
| Example || *_complexcrop || ComplexCrop
|-
| Example || *_construction || Construction
|-
| Example || *_cropgrass || CropGrass
|-
| Example || *_deciduousforest || DeciduousForest
|-
| Example || *_default || Default
|-
| Example || *_dirt || Dirt
|-
| Example || *_drycrop || DryCrop
|-
| Example || *_dump || Dump
|-
| Example || *_estuary || Estuary
|-
| Example || *_evergreenforest || EvergreenForest
|-
| Example || *_floodland || FloodLand
|-
| Example || *_freeway || Freeway
|-
| Example || *_glacier || Glacier
|-
| Example || *_golfcourse || GolfCourse
|-
| Example || *_grassland || Grassland
|-
| Example || *_greenspace || Greenspace
|-
| Example || *_heath || Heath
|-
| Example || *_herbtundra || HerbTundra
|-
| Example || *_industrial || Industrial
|-
| Example || *_intermittentlake || IntermittentLake
|-
| Example || *_intermittentstream || IntermittentStream
|-
| Example || *_irrcrop || IrrCrop
|-
| Example || *_lagoon || Lagoon
|-
| Example || *_lake || Lake
|-
| Example || *_landmass || Default
|-
| Example || *_lava || Lava
|-
| Example || *_light_rail || Railroad
|-
| Example || *_littoral || Littoral
|-
| Example || *_marsh || Marsh
|-
| Example || *_mixedcrop || MixedCrop
|-
| Example || *_mixedforest || MixedForest
|-
| Example || *_motorway || Freeway
|-
| Example || *_floodland ||
|-
| Example || *_naturalcrop || NaturalCrop
|-
| Example || *_ocean || Ocean
|-
| Example || *_olives || Olives
|-
| Example || *_openmining || OpenMining
|-
| Example || *_orchard || Orchard
|-
| Example || *_packice || PackIce
|-
| Example || *_polarice || PolarIce
|-
| Example || *_port || Port
|-
| Example || *_primary || Road
|-
| Example || *_rail || Railroad
|-
| Example || *_railroad1 || Railroad
|-
| Example || *_railroad2 || Railroad
|-
| Example || *_rainforest || RainForest
|-
| Example || *_residential || Road
|-
| Example || *_rice || Rice
|-
| Example || *_river || Canal
|-
| Example || *_road || Road
|-
| Example || *_rock || Rock
|-
| Example || *_saline || Saline
|-
| Example || *_saltmarsh || SaltMarsh
|-
| Example || *_sand || Sand
|-
| Example || *_sclerophyllous || Sclerophyllous
|-
| Example || *_scrub || ScrubCover
|-
| Example || *_service || Road
|-
| Example || *_stream || Stream
|-
| Example || *_suburban || Suburban
|-
| Example || *_tertiary || Road
|-
| Example || *_town || Town
|-
| Example || *_transport || Transport
|-
| Example || *_trunk || Road
|-
| Example || *_urban || Urban
|-
| Example || *_vineyard || Vineyard
|-
| Example || *_watercourse || Watercourse
|}

User:F-ojac

2016-07-21T14:50:17Z

F-ojac: Created page with "{| class="wikitable" |- ! CLC !! CS Shape !! CS Material |- | Example || *_agroforest || AgroForest |- | Example || *_airport || Airport |- | Example || *_asphalt || Asĥalt |..."

{| class="wikitable"
|-
! CLC !! CS Shape !! CS Material
|-
| Example || *_agroforest || AgroForest
|-
| Example || *_airport || Airport
|-
| Example || *_asphalt || Asĥalt
|-
| Example || *_barrencover || BarrenCover
|-
| Example || *_bog || Bog
|-
| Example || *_burnt || Burnt
|-
| Example || *_canal || Canal
|-
| Example || *_cemetery || Cemetery
|-
| Example || *_complexcrop || ComplexCrop
|-
| Example || *_construction || Construction
|-
| Example || *_cropgrass || CropGrass
|-
| Example || *_deciduousforest || DeciduousForest
|-
| Example || *_default || Default
|-
| Example || *_dirt || Dirt
|-
| Example || *_drycrop || DryCrop
|-
| Example || *_dump || Dump
| -
| Example || *_estuary || Estuary
| -
| Example || *_evergreenforest || EvergreenForest
| -
| Example || *_floodland || FloodLand
| -
| Example || *_freeway || Freeway
| -
| Example || *_glacier || Glacier
| -
| Example || *_golfcourse || GolfCourse
| -
| Example || *_grassland || Grassland
| -
| Example || *_greenspace || Greenspace
| -
| Example || *_heath || Heath
| -
| Example || *_herbtundra || HerbTundra
| -
| Example || *_industrial || Industrial
| -
| Example || *_intermittentlake || IntermittentLake
| -
| Example || *_intermittentstream || IntermittentStream
| -
| Example || *_irrcrop || IrrCrop
| -
| Example || *_lagoon || Lagoon
| -
| Example || *_lake || Lake
| -
| Example || *_landmass || Default
| -
| Example || *_lava || Lava
| -
| Example || *_light_rail || Railroad
| -
| Example || *_littoral || Littoral
| -
| Example || *_marsh || Marsh
| -
| Example || *_mixedcrop || MixedCrop
| -
| Example || *_mixedforest || MixedForest
| -
| Example || *_motorway || Freeway
| -
| Example || *_floodland ||
| -
| Example || *_naturalcrop || NaturalCrop
| -
| Example || *_ocean || Ocean
| -
| Example || *_olives || Olives
| -
| Example || *_openmining || OpenMining
| -
| Example || *_orchard || Orchard
| -
| Example || *_packice || PackIce
| -
| Example || *_polarice || PolarIce
| -
| Example || *_port || Port
| -
| Example || *_primary || Road
| -
| Example || *_rail || Railroad
| -
| Example || *_railroad1 || Railroad
| -
| Example || *_railroad2 || Railroad
| -
| Example || *_rainforest || RainForest
| -
| Example || *_residential || Road
| -
| Example || *_rice || Rice
| -
| Example || *_river || Canal
| -
| Example || *_road || Road
| -
| Example || *_rock || Rock
| -
| Example || *_saline || Saline
| -
| Example || *_saltmarsh || SaltMarsh
| -
| Example || *_sand || Sand
| -
| Example || *_sclerophyllous || Sclerophyllous
| -
| Example || *_scrub || ScrubCover
| -
| Example || *_service || Road
| -
| Example || *_stream || Stream
| -
| Example || *_suburban || Suburban
| -
| Example || *_tertiary || Road
| -
| Example || *_town || Town
| -
| Example || *_transport || Transport
| -
| Example || *_trunk || Road
| -
| Example || *_urban || Urban
| -
| Example || *_vineyard || Vineyard
| -
| Example || *_watercourse || Watercourse
|}

Fr/Osm2city.py

2016-01-30T09:50:55Z

F-ojac: Initial import.

== Installation sous Windows ==
Le mode opératoire ci-dessous est basé sur Windows 10, mais devrait être applicable pour les autres versions de ce système d'exploitation.

=== Installation de Python ===
Python est l'interpréteur qui permettra d'exécuter les commandes de Osm2city.py pour générer les objets. Nous l'installerons par exemple dans le répertoire D:\Python27.
Quand vous aurez chargé les modules complémentaires, fichiers .whl, il faudra les compiler pour les ajouter à Python.
Voici la syntaxe pour installer un module, une ligne pour chaque :

<syntaxhighlight lang="bash">
..\..\scripts\pip install networkx-1.10-py27-none-any.whl
..\..\scripts\pip install networkx-1.10-py3-none-any.whl
..\..\scripts\pip install networkx-1.9.1-py2.py3-none-any.whl
</syntaxhighlight>

Vous pouvez gagner du temps en les intégrant dans un fichier de commandes : se positionner dans le répertoire Python27\lib\site-package où se trouvent les modules chargés et exécuter la commande :

<syntaxhighlight lang="bash">
dir /B *.whl>compile.cmd
</syntaxhighlight>

Cela va créer une ligne avec le nom de chaque fichier .whl dans un fichier nommé compile.cmd . Editer le fichier et ajouter ..\..\scripts\pip install au début de chaque ligne.
Enregistrer et exécuter le fichier de commandes : cela créera un répertoire pour chaque module.
Vous aurez des erreurs car certains modules ne sont pas pris en charge par Windows, mais ce n'est pas grave.

=== Installation de osm2city et osm2city-data ===
Vous pouvez régler le PYTHONPATH ou gérer les appels en indiquant le chemin des exécutables dans un script.
Ici ils sont installés sous la racine du disque, d:\osm2city et d:\osm2city-data.
Voici les commandes pour créer les liens symboliques pour les répertoires des textures sous Windows en étant dans le répertoire d:\osm2city :

<syntaxhighlight lang="bash">
MKLINK /D /J .\tex ..\osm2city-data\tex
MKLINK /D /J .\tex.src ..\osm2city-data\tex.src
</syntaxhighlight>

Cela vous donnera l'arborescence indiquée dans le wiki.

=== Installation de FGElev ===
Vous aurez besoin du programme fgelev.exe pour réaliser le calcul des élévations.
Le wiki indique qu'il est fourni dans les versions de FG supérieures à 3.3.
Si vous ne le trouvez pas dans la version 3.4, chargez une version 3.6 RC ou supérieure qui l'intègrent.

=== Installation de wget ===

Avant de pouvoir télécharger en masse les données OSM, vous devrez installer wget pour Windows.
Ici il est installé dans d:\wgetwin-1_5_3_1-binary
Dans ce répertoire, créez un sous-répertoire download dans lequel vous chargerez les données OSM avec un fichier de commande getosm.cmd dont le contenu est, par exemple :

<syntaxhighlight lang="bash">
..\wget -O buildings.osm http://www.overpass-api.de/api/xapi?*[bbox=0.5,46.75,0.75,46.875]
</syntaxhighlight>

Il suffira de changer les coordonnées de la tuile dans bbox= pour récupérer le fichier buildings.osm de la tuile voulue.
Dans ce même répertoire download, créez le fichier params.ini avec la commande

<syntaxhighlight lang="bash">
d:\python27\python.exe D:\osm2city\parameters.py -d>params.ini
</syntaxhighlight>

=== Utilisation ===
Créez un répertoire pour la tuile sous d:\osm2city, exemple d:\osm2city\LFBI et déplacez le fichier buildings.osm dedans.
Copiez le fichier params.ini créé ci-dessus dans ce dossier et configurez-le comme indiqué dans le wiki.
Le paramètre ELEV_MODE a été laissé en "FgelevCaching" et n'a pas posé de souci.
Créez un répertoire Output sous votre répertoire de tuile et configurez la sortie dedans : osm2city

<syntaxhighlight lang="bash">
PATH_TO_OUTPUT = " d:\osm2city\LFBI \Output"
</syntaxhighlight>

En fin, il faut exécuter le script osm2city.py pour générer les bâtiments de la tuile.
Créez un fichier de commandes, run.cmd, dans osm2city:

<syntaxhighlight lang="bash">
@echo off
SET $FG_ROOT=D:\Flightgear\data
SET FG_ROOT=D:\Flightgear\data
echo Traitement de %1
d:\python27\python osm2city.py -f %1\params.ini
</syntaxhighlight>

Dans le dossier de tuile, ici LFBI, créez un fichier de commandes pour appeler ce run.cmd en donnant le répertoire de la tuile en paramètre :

<syntaxhighlight lang="bash">
@echo off
cd..
run.cmd LFBI
</syntaxhighlight>

Le résultat est créé dans le répertoire Output \Objects, ici \e000n40\e000n46

Copiez le dans un dossier Custom Scenery que vous indiquerez en tête dans la rubrique scenery de FGRUN.
Créez un lien symbolique vers les textures à partir du dossier de Custom Scenery :

<syntaxhighlight lang="bash">
MKLINK /D /J .\tex ..\osm2city-data\tex
</syntaxhighlight>

=== Voir le résultat ===
Osm2city.py génère plusieurs types de fichiers :
Les fichiers .stg contiennent les appels aux fichiers xml.
Les fichiers .xml gèrent les animations et font appel aux fichiers .ac qui génèrent les bâtiments.

Vous pouvez mixer vos bâtiments personnels d'aéroport avec ceux générés par Osm2city.
Pour cela indiquez le chemin de votre répertoire Custom Scenery dans le paramètre PATH_TO_SCENERY du fichier params.ini
Osm2city en tiendra compte en ne générant pas de bâtiment à proximité des vôtres.

Il se peut qu'Osm2city en génère quelques-uns trop près ou sur les vôtres.
Pour rectifier, vous pourrez commenter des lignes dans les fichiers .stg
Cette méthode est radicale pour éviter d'avoir des bâtiments écrasés mais en supprime d'autres de la scène finale. C'est un compromis à faire.

Osm2city.py

2016-01-17T16:50:42Z

F-ojac: Typo

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitlab.com/fg-radi/osm2city repository] is hosted on <del>gitorious</del> gitlab.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/Linux. It should also run on Mac OSX. Windows users, see [[Osm2city.py#Install_on_Windows|below.]]

It's at a rather early stage of development. There's no GUI, everything is controlled by an input file. But it produces realistic city layouts (after all, it uses realistic data). The whole process -- from scratch to flying in FG -- for a city the size of LOWI takes perhaps 30 min, including maybe a total of 15 min manual work.

It has been tested with Dresden, Germany (EDDC) and Innsbruck, Austria (LOWI). Both areas are now populated with about 50,000 buildings. Rendering this in FG is quite demanding. The FG process eats ~2.8GB RAM when flying in those areas, the download is ~50 MB each.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitlab.com/fg-radi/osm2city-data]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]]
Following Mathias' suggestion at FS Weekend 2013, I've now changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10). That indeed gives a nice speed-up. In fact, I'm overwhelmed by what's possible now -- here's a scene looking down at LOWI from FL300 showing 60k buildings. Plain Scenery 2.0 gives 19 fps on i7 Intel HD 5000 2560x1440. With buildings framerate goes down to 14.

[[File:LOWI with OSM buidings one object per tile.jpg|thumb|Approaching LOWI, with 60k OSM buildings]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. Basically, it parses the OSM
xml, generates a list of building outlines, discards some based on their area,
simplifies the outlines, clusters them into ~500x500m blocks and different LODs,
then writes .ac, .xml, and .stgs. <del>OSM parsing is by far the most expensive,
easily taking 10 minutes for 50k buildings. Once that's done, the remaining parts take maybe 1 minute in total.
</del> (Some optimization gave a huge speedup).

At the moment, the code knows only the floor plans. <del>No streets</del>, no runways, no
land-use. But it'll certainly process such data in the future, and then could
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* reads buildings from OSM. Honors height and level tags, reads relations ('buildings with holes')
* reads existing .stg, won't place OSM building if there's a static model nearby
* reads pre-calculated terrain elevation: places buildings at correct elevation
* simplify/automate elevation probing by using fgelev
* LOD animation based on building height and area (see below)
* cluster a number of buildings into a single .ac files. Clusters overlap to alleviate sharp LOD borders
* complex sloped roof generation (using Olivier Teboul's implementation of the straight skeleton algorithm)
* texture manager: DB of facade/roof textures
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* writes .ac, .xml, .stg

== Planned Features ==
(in random order)
* more complex facade generation. Currently, all sides get same texture {{not done}}
* Rembrandt lighting {{not done}}
* put a piece of matching ground texture around buildings ('garden') {{progressbar|10}}
* put shared models if/where OSM indicates so: gas stations... {{not done}}
* geometry cleanup, simplify too complex buildings {{done}}
* use residential/industrial/commercial tags/areas. ATM, all is residential. {{not done}}
* geometry cleanup, simplify too complex buildings {{done}}
* Batch processing of greater areas including downloads {{done}}
* use more LOD levels, write them to different .ac so users can easily reduce building density, therefore improve performance {{progressbar|50}}
:* put large buildings into one ac, sort/rate buildings by stand-out-ness {{done}}
:* then ship light/med/full .stg {{not done}}
* mid-term: develop this into a city-engine that procedurally generates a city based on OSM roads. {{not done}}
:* read, drape, texture roads and railways {{progressbar|70}}
:* texture road intersections {{not done}}
:* illuminate roads {{not done}}
:* procedural bridges {{progressbar|50}}
:* place shared models along roads if no OSM data available {{not done}}
* long-term: integrate into FG to do all this on the fly. {{not done}}

== LOD Scheme ==
FlightGear knows three standard LOD: bare, rough and detail. 'Bare' sets the drawing distance of the terrain, which may easily be 50 km or more. Drawing buildings 50 km out makes little sense (unless they are ''really'' tall), so we shouldn't use this level here. Of the remaining two standard levels, 'rough' is used for large and/or tall buildings, and 'detail' for smaller ones.

Osm2city can generate complex roof shapes. This increases the poly count further, and I believe it's a good idea to use another LOD 'roof' for complex roofs. Fortunately, we can change every aspect of FlightGear, and adding another LOD is easy. Use the FG command line
--prop:double:/sim/rendering/static-lod/roof=2000
to set the distance for 'roof' to 2 km. If you want to adjust it via FG's GUI, copy static-lod.xml (from osm2city's git repo) to $FGDATA/gui/dialogs.

== Ideas ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* bump map/reflection effects?
* a mode that generally uses shared models? If we find a shared models of matching floorplan, use this instead of creating a new, individual building? Will break clusters.
* a terrasync-like thing? Users get OSM buildings
(where available) on-the-fly? Might be quite costly in terms of runtime performance and bandwidth. The OSM download (buildings only!) is
~40MB for the 25x25km LOWI area.

== Install ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx curl
2. get [https://gitlab.com/fg-radi/osm2city osm2city] and [https://gitlab.com/fg-radi/osm2city-data osm2city-data] from gitlab.

3. add the directory with osm2city modules to your [http://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH PYTHONPATH] (unless your PYTHONPATH already contains . (the dot))
You can add
<syntaxhighlight lang="bash">
PYTHONPATH=$PYTHONPATH:/path/of/osm2city
</syntaxhighlight>
or
<syntaxhighlight lang="bash">
PYTHONPATH=$PYTHONPATH:.
</syntaxhighlight>
into your hidden configuration file .bashrc located in your home directory.

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/. Typically you will have to "adapt" and execute these commands.
<syntaxhighlight lang="bash">
cd osm2city
ln -sf ../osm2city-data/tex.src
ln -sf ../osm2city-data/tex
</syntaxhighlight>
Then the sub-directory of osm2city will appears like that
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python, so install Python if you have not already done so https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

* http://www.lfd.uci.edu/~gohlke/pythonlibs/#networkx
* http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
* http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely
* http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack
* https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a template download URL that you can fetch with wget:

wget -O buildings.osm http://www.overpass-api.de/api/xapi?*[key=value][bbox=11.16898,47.20837,11.79108,47.38161]

Note that you either need to give a valid ''key=value'' pair, or remove ''[key=value]'' altogether. The alternative

wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

will result in a file compatible with JOSM, at the cost of a larger download. If unsure, use the first option.

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = "Manual".}}

* ELEV_MODE = "FgelevCaching"
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = "/usr/local/fg/bin/fgelev" or just FG_ELEV = "fgelev" if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = "Manual"
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = "Telnet"
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them. On Windows it is sufficient to have one copy in $FG_ROOT.

=== ImportError: No module named calc_tile ===

Copy calc_tile.py into batch_processing folder

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related content ==
=== Wiki articles ===
* [[Areas populated with osm2city scenery]]
* [[AutoGen Scenery for FlightGear]]
* [[OpenStreetMap buildings]]
* [[Random Buildings]]
* [[Using OSM Vector Data in FlightGear]]

=== Forum topics ===
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=19625 LOWI city buildings]
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 <nowiki>[</nowiki>Proposal<nowiki>]</nowiki> Autogen Cities using PixelCity]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=17598 Procedural buildings in OSM before part of Scenery]

=== Mailing list threads ===
* [http://sourceforge.net/p/flightgear/mailman/message/30825768/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> osm2city.py]

[[Category:Scenery software]]

AI Traffic

2016-01-16T14:01:03Z

F-ojac: Slight news update

{{AI Navbar}}

'''Interactive Traffic''', or '''AI-Traffic''' (Artificial Intelligence) has come to life with [[FlightGear]] version 0.9.5. Since then FlightGear has an interactive traffic system that is based on the AI-Models subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.

In essence, setting-up the AI controlled traffic system involves three steps:
# Create Traffic files,
# Build ground networks for the Airports containing traffic.
# Create the appropriate Departure / Arrival procedures for each airport involved.

Notice that the "Download all AI aircraft" is no longer necessary, because most, if not all, AI aircraft are now part of the base package.

{{Note|
{{FGCquote
|the rendering logic for AI aircraft has changed recently. If they are drawn depends on the projected size on the screen and not on their distance. 
Please check the properties
* /sim/rendering/static-lod/ai-range-model-pixel (should be true)
* /sim/rendering/static-lod/ai-detailed (should be 30)
With this configuration, AI aircraft bigger than 30pixels on the screen should show up.

There are other factors in OpenSceneGraph that decide if the Paged LOD nodes get rendered. It may sometimes take a couple of minutes or some view panning for the models to pop up.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33271362/
|title=<nowiki>Re: [Flightgear-devel] Flightgear next (3.5.0) Does not render MP
aircraft</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2015-01-26</nowiki>
}}
}}
{{FGCquote
|aircraft disappearing from view but still being present in the pilot list may be due to OSG paging out the aircraft too aggressively.
Try increasing <code>/sim/rendering/max-paged-lod</code> to 200 and see if that helps
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/34211674/
|title=<nowiki>Re: [Flightgear-devel] The 707 on the multiplayer servers</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2015-06-16</nowiki>
}}
}}
}}

== Building Traffic Files ==
Traffic patterns are stored in data files in extended markup language (.xml) format. The actual location of these files are version dependent. For FlightGear 0.9.x, traffic files are stored in a sudirectory called '''Traffic''' in FlightGear's main data directory, hereafter referred to with it's technical name:

<tt>[[$FG ROOT]]/Traffic/</tt>

In FlightGear 1.0, the traffic files can be found in a subdirectory of:

<tt>[[$FG ROOT]]/AI/Aircraft/</tt>

For example, traffic belonging to a united airlines 737 would be located in: <tt>[[$FG ROOT]]/AI/Aircraft/737/737-UnitedAirlines-traffic.xml</tt>

FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in:

<tt>[[$FG ROOT]]/AI/Traffic/</tt>

For FlightGear 1.9.0 and later, a new traffic file format was introduced (henceforth referred to as "traffic manager II" format (TM-II), in which aircraft and flights are no longer directly coupled, leading to more flexibility.

Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.

== Some Details: TrafficManager, Aircraft, and Flights ==
As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by [[McDonnell Douglas MD11]] aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.

In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.

The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database was originally constructed on the basis of a fixed routing table that was assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and these FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remained the same, unless a major update to the database were to take place. Real aircraft require maintenance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintenance in this respect.

There were still some significant drawbacks to this approach, nevertheless. Consider the MD11 a little further. In real life, KLM operates this aircraft on many routes that are serviced at relatively irregular intervals. For example, many flights to the Carribean are served only two or three times a week, making it extremely complicated to build completely accurate traffic files for these routes.

To circumvent these problems, a new database format was introduced in FlightGear 1.9.0. In this new format, flights are no longer directly and rigidly assigned to specific aircraft. Instead, a more generic description of a fleet is given, along with a series of flights that need to be carried out. The routing is then taken care of by FlightGear itself.

== An example of a traffic file ==

Below is a complete and working example of a traffic manager II file, as it can be used with FlightGear 1.9.0 and later:
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCB</registration>
<heavy>true</heavy>
</aircraft>

<flight>
<callsign>KLM0765</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>0/12:35:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>TNCM</port>
<time>0/21:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>

<flight>
<callsign>KLM0769</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>TNCM</port>
<time>3/01:25:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
<time>3/10:50:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</trafficlist>
</syntaxhighlight>
== Dissecting the traffic file ==
Here I will discuss the general structure of a traffic file in more detail. As discussed, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.

=== General layout ===
The general layout of each file should look like the above example.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<trafficlist>

</trafficlist>
</syntaxhighlight>
The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a '''<trafficlist>''' statement. Also, the last line in the file should close off the trafficlist section using the '''</trafficlist>''' statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.

=== Defining the aircraft ===
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<home-port>EHAM</home-port>
<required-aircraft>MD11KLM</required-aircraft>
<actype>MD11/P</actype>
<offset>25</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
</aircraft>
<aircraft>
...
</aircraft>
</trafficlist>
</syntaxhighlight>
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.

* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.
* '''<livery>''' This line is currently unused, and will likely remain unused. The original idea was to combine this with the '''<model>''' line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
* '''<airline>''' This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter [[ICAO]] airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
* '''<home-port>''' Each FlightGear aircraft is assigned to a home airport. Internally, this is used to ensure that routes are setup that will eventually lead back to the home airport. This is done to maintain some sensibility into the routing algorithm. '''[New for traffic manager II]'''
* '''<required-aircraft>''' This value is a key that binds aircraft and flights together. In case of this example, the key MD11KLM. Indicates that this aircraft will only carry out flights containing the same key. Usually, a combination of aircraft type, and airline will suffice for this key. In some cases, in particular, when specific aircraft / airlines are distributed across multiple hubs (i.e. home ports), it may be necessary to specify a key containing the home airport as well. For example, Delta Airlines operates 767's out of Atlanta, as well as out of New York. To separate between these two cases, it would be advisable to use two keys; one for KATL (e.g. 767DALKATL), and one for KJFK (e.g., 767DALKJFK). '''[NEW for traffic manager II]'''
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the '''<model>''' keyword refers to.
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
* '''<flighttype>''' In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)
* '''<performance-class>''' This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:
** '''light_aircraft''' (prop driven single or twin),
** '''ww2_fighter''' (world war two fighter),
** '''jet_transport''' (modern commercial jet),
** '''jet_fighter''' (modern fighter aircraft)
** '''tanker''' (tanker aircraft), or.
** '''ufo''' (allows extreme accel/decel capabilities).
* '''<registration>''' The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.
* '''<heavy>''' Can be true or false. Reserved for future use by ATC, to determine whether the postfix "Heavy" should be appended to the aircraft's callsign.

=== Defining a flight ===
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,
<syntaxhighlight lang="xml">
<aircraft>
...
<flight>
</flight>
</aircraft>
</syntaxhighlight>
One major difference from this format is that the traffic manager II file formats now contain separate sections for aircraft and flight information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a traffic manager II file looks something like this:
<syntaxhighlight lang="xml">
<aircraft>
...
<required-aircraft>MD11KLM</required-aircraft>
...
</aircraft>

<flight>
...
<required-aircraft> MD11KLM </required-aircraft>
...
</flight>
</syntaxhighlight>
Each flight is defined between the '''<flight>''' and '''</flight>''' statements. For example, let's have a look at a randomly selected flight from our KLM.xml example.
<syntaxhighlight lang="xml">
<flight>
<callsign>KLM0769</callsign>
<required-aircraft>MD11KLM</required-aircraft>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
<time>2/12:35:00</time>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>TNCB</port>
<time>2/22:15:00</time>
</arrival>
<repeat>WEEK</repeat>
</flight>
</syntaxhighlight>
The '''<flights>''' section is slightly more complex than the aircraft definition itself, because it has a few nested levels, however, these should mostly be self-explanatory. The following keywords should be specified:
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.
* '''<callsign>''' The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. '''KLM''' for KLM, or '''Springbok''' for South African Airways), and the flight number (e.g. '''KLM0605''', or '''Springbok0033''').
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section.
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<time>''' keywords.
* '''<cruise-alt>''' Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
* '''<arrival>''' Same as '''<departure>''', but now defining the port of arrival.
* '''<repeat>''' Repeat period. This can be either the keyword ''WEEK'', or a number followed by ''Hr''. ''WEEK'' means that the whole schedule repeats itself on a weekly basis. ''Hr'' means that the whole schedule repeats after the number of hours specified directly before it (e.g. ''24Hr'' means that the schedule repeats after 24 hours). With traffic manager II, it is generally recommended not to mix schedules that rotate on different frequencies. In general, the best results are obtained when using only weekly rotating flights. For flights that are in reality operated on a daily basis, it is recommended to just specify multiple entries, i.e. one separate flight for every weekday.
* '''<port>''' This should be the international ICAO airport code. This keyword should be specified only within the '''<departure>''' or '''<arrival>''' sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
* '''<nowiki><time></nowiki>''' Used to specify the '''<departure>''' or '''<arrival>''' time. The format of this string is ''hour:minute:second''. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).

== Putting it all together: Including a traffic file ==
After creating a traffic file, all we need to do is make sure FlightGear knows how to use this. In earlier versions of FlightGear, this used to involve quite a bit of editing, because every file had to be referenced in a master traffic file, named fgtraffic.xml.

Those days are gone, however, since FlightGear 1.0.0, when a directory scanning mechanism was put in place. Both FlightGear 1.0.0., and 1.9.0 and beyond use this directory scanning mechanims, however, in order to separate between the traffic manager 1 format used by FlightGear 1.0.0, and the traffic manager II format used by later versions, these files are located in two different locations. In FlightGear 1.0.0, traffic files should be located in a subdirectory of the [[$FG_ROOT]]/AI/Aircraft directory. For example, traffic for a Boeing 737 could be located in in an xml file in [[$FG_ROOT]]/AI/Aircraft/737, and traffic for a 747 should be located in [[$FG_ROOT]]/AI/Aircraft/747.

Since traffic files for FlightGear 1.9.0 are stricktly speaking no longer tied to one particular aircraft, or aircraft type, the traffic files were moved to a different directory, namely [[$FG_ROOT]]/AI/Traffic. Again, the actual traffic files should be stored in a subdirectory one level below /AI/Traffic. In the demo that is provided with FlightGear 1.9.0, all traffic is organized by airline, and stored in a single letter directory. For example, KLM traffic can be found in [[$FG_ROOT]]/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in [[$FG_ROOT]]/AI/Traffic/U/UAL.xml. Although currently no formal definition exists for military or general aviation traffic, a similar scheme could be adapted. For instance, military traffic could be placed in [[$FG_ROOT]]/AI/Traffic/mil/USAF.xml

== Tools ==
One major motivation for introducing the traffic manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custom scenery project is working on extending their scenemodel database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory or get it via Terrasync.

Secondly, the author of the traffic manager code has written some scripts, mainly for private use, that will allow one to input the flight data into a simple text format and then convert the resulting text file to xml. The most important of these scripts can be found in the flightgear source package under scripts/perl/traffic/.

Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project):

###HOMEP RegNo TypeCode Type AirLine Livery Offset Radius FltType Perf.Class Heavy Model
############################################################################################################################################

AC WMKK TF-ARN 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ARJ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
AC WMKK TF-ATZ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml

Then, you need to define all the flights according to the following layout:

########Flt.No Flt.Rules Days Departure Arrival FltLev. A/C type
################### ######### ####### ############### ############### #################

# London Heathrow (EGLL; UTC+1 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0001 IFR 0123456 21:00 EGLL 09:25 WMKK 360 747MAS
FLIGHT Malaysian0002 IFR 0123456 15:40 WMKK 04:50 EGLL 360 747MAS
FLIGHT Malaysian0003 IFR 0123456 11:00 EGLL 23:25 WMKK 360 747MAS
FLIGHT Malaysian0004 IFR 0123456 09:05 WMKK 08:15 EGLL 360 747MAS

# Frankfurt (EDDF; UTC+2 ) to Kuala Lumpur (WMKK +8:00) vv.
FLIGHT Malaysian0005 IFR 0.2.456 10:30 EDDF 22:25 WMKK 360 777MAS
FLIGHT Malaysian0006 IFR .1.3456 15:50 WMKK 04:25 EDDF 360 777MAS

Note that the flight information laid out above resembles that of a standard airline schedule table as close as possible, with a few known exceptions:
- Weekdays are in the range 0 to 6, but do follow standard airline conventions (0 = monday; 6 is sunday)
- All times in the table are in UTC; to convert from local time, as given in the airline table, subtract the airport in question's UTC offset).
- The last entry in each line (A/C type) should correspond to the ''combination'' of the '''TypeCode''' and '''Airline''' entries in the aircraft sections.

The resulting table can now easily be converted to xml output by running the conf2xml.pl (conv2xml.pl - check) script.

For Operating Systems of the Unix family, simply run conf2xml.pl from the directory where you unpacked the trafficdata.zip archive:

./conf2xml.pl

will give the output:

Writing to ADR.xml
Writing to AFL.xml
...
Writing to VLG.xml
Writing to VLM.xml

When the script encounters an error, it will stop prematurely.

The [[AI Schedule manager]] is a GUI based application that uses a database backend to store and perform operations on flights, fleets and aircraft for airlines.

== Ground networks ==
The next major aspect of the AI traffic system contains taxiway information. Although the physical layout of each airport is contained in FlightGear's airport database, this information is not sufficient to provide taxiway information. Therefore AI aircraft pickup this type of routing information from an xml file inside the <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml</tt>, where ICAO stands for the 4 letter ICAO code for the airport in question.

For example, see the ground network for EHAM, which is found in <tt>[[$FG_SCENERY]]/Airports/E/H/A/EHAM.groundnet.xml</tt>. See the end of this page for a small excerpt from this file.

FlightGear versions older than 2.4.0 look up the ground network in <tt>[[$FG_ROOT]]/AI/Airports/[ICAO]/parking.xml</tt>.

=== A technical perspective ===
A ground network file consists of four major sections:
* The first section is optional, although recent versions of TaxiDraw add this section automatically. This section contains a list of all the radio frequencies for the airport in question. FlightGear currently (as of 1.9.0) uses these frequencies to display some ATC messages. As of FlightGear 1.9.0, only startup approval requests are implemented. You can "hear" these by tuning to the first ground frequency listed in the frequencies section.
* The second section of the file contains the parameters of the airport's parking locations.
* The third section contains a list of all the nodes in the ground network.
* The fourth and final section contains a list of segments, or "arcs" as David Luff called them initially, which basically describe which node is connected to which other node.

Each parking and AI node has a unique index number, which is used by the
segments to link the startup location and the taxiways together. Parkings and
AI nodes have the following parameters:
* '''index (unique, consecutively numbered id)
* '''lat''' (latitude in decimal minutes format, for example <code>N50 56.988</code>)
* '''lon''' (longitude in decimal minutes format, for example <code>W01 21.756</code>)
* '''name''' (name as found on airport charts, for example <code>D23</code> or <code>C1</code>).

In addition, each parking has a number of additional parameters:
* '''type:''' specifies what type of aircraft can use this parking bay. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:
** '''ga''' (general aviation),
** '''cargo''' (cargo)
** '''gate''' (commercial passenger traffic)
** '''mil-fighter''' (military fighter)
** '''mil-cargo''' (military transport)

* '''number:''' Currently used in combination with the <name> parameter to determine the full name of the gate.
* '''heading:''' The heading at which the aircraft are parked in this bay.
* '''radius:''' A value used to determine whether the aircraft will fit in this bay: see also the description of the '''<radius>''' parameter in the traffic pattern description above. FlightGear uses a standard list of [[aircraft radii]] for gate assignment.
* '''airlineCodes:''' a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here.
* '''pushBackRoute:''' A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below.

Taxiway nodes contain two additional parameters:
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, or 0 otherwise
* '''holdPointType''' Describes wether the current point should be considered a holding point. This parameter can have the following values:
** '''none''' No holding point
** '''normal''' A regular holding point. This point should be placed just before the runway entrance / exit points, so that traffic will not enter the runway before receiving clearance to enter the runway. Note that support for this type of holding point is not implemented yet, but should appear sometime during 2009.
** '''CAT II/III''' A special holding point for IFR conditions. Currently not supported yet.
** '''PushBack''' A push back hold point type. Each parking can be connected to maximally one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can maximally only be one connected to each gate.

Finally, the taxiway segments contain three parameters.
* '''begin''' The id of the parking or AINode where this segment starts
* '''end''' The id of the parking or AINode where this segment ends
* '''IsPushBackRoute''' a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise.
* '''name''' Name of the taxiway.

=== Creating a ground network, a practical approach ===
Having finished the technical description of the parking file format, the good news is that one probably doesn't need to know too much about the technical side of the file structure to create a ground network. Advanced editing capabilities are currently available in TaxiDraw, a separately available utility for airport layout, and ground network editing. This document describes the functionality of the NEW_GUI_CODE version of TaxiDraw.

=== TaxiDraw ===
Although currently no officially released version of [[TaxiDraw]] exists with the ground editing capability, the current CVS version is capable of doing so. Network editing capabilities in TaxiDraw are currently about as stable as the other editing features, however, the ground network module is still somewhat separate from the rest of the airport project code, and ground networks will 'not' automatically be saved together with the airport project. Therefore, do regular exports while editing, to prevent loss of work.

See the [[TaxiDraw]] article for instructions on how to obtain a working copy of TaxiDraw.

=== Getting good reference material ===
The first step in preparation of creating a ground network consists of getting some reference material. Ideally, You'd like to find a good satellite or aerial image. If you can't find that, using a schematic diagram might also work. For airports in the United States, you can simply load USGS imagery by clicking the "USGS" button, however, for the rest of the world, this service is not available. Perhaps the best way to get a decent reference image is to use the standalone GoogleEarth program. GoogleEarth lets you zoom in to any location of the world. Center your view on the airport, and zoom to encompass the entire area. Then, save a jpg snapshot of the screen. This image can be imported in TaxiDraw. After importing, right click, goto the "lock layers" submenu and unselect the background image. Next, select the background image, right click and select the "calibrate background image". Typically, the "Uniform scale / rotation option" works best.

Although a google earth snapshot will usually give a good reference for the actual location of airport parkings, it still doesn't give much information about some of the logical aspects of the parking infrastructure. In particular, information about gate names / airline operations is not provided. Typically, this information is hard to find, but can be compiled from various sources, including wikipedia, random airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!

=== Creating the network ===
The current documentation describes the procedure for the TaxiDraw NEW_GUI_CODE branch, which is rather drastically different from the procedure used by the original TaxiDraw, previously documented here. This section describes some of the general procedures involved in building a ground network.

Note: export your work regularly: Although ground network editing capabilities have improved dramatically, this part of TaxiDraw is still somewhat separate from the rest of the code, and ground networks are not automatically saved together with the project. When exporting, TaxiDraw asks wether the ground network should be saved directly into FlightGear's data directory. Usually, this is okay, so just clicking "yes" takes care of saving the file in the correct location. Likewise, while importing an existing network, TaxiDraw first looks in FlightGear's data directory, to check for an existing default file to be inported.

[Scenery v2]: For 850 Airports, a python script is available, to automatically create a basic groundnet out of WED's earth.wed file. It converts Yellow Markings and Park Positions into a groundnet which can be read, and refined by Taxidraw. Note that both Centerline and borders are converted (remove border nodes once in Taxidraw) See [http://forum.flightgear.org/viewtopic.php?f=23&t=17990 HERE]

==== Set up a rough outline ====
To make best use of the background image, right click, choose the "view" menu, and unselect "taxiways", this way, all network drawing can be based on the real airport location. First, select the "Insert startup location" edit mode. This way, each left mouse click will place a startup location at the position of the mouse cursor. Once the major startup locations have been placed, switch back to "selection" mode, by clicking the little arrow button.

Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking's radius can be changed by clicking anywhere on the big red circle allows one to change the parking's radius by dragging the mouse. Although this usually works for setting up a rough draft, these parameters can directly be changed in the properties dialog. If the properties dialog is not visible, press [cntrl-p] to bring it up. It is possible to select multiple startup locations by pressing the shift key while selecting, and the parameters for each selected startup location can be changed at the same time. This is a powerful feature for editing the parameters of a whole series of parking locations, and also for equating and orienting gate radius and heading.

With the startup locations in place, select one of them. The next step will be to connect this parking area to each runway end. After selecting the parking, click on the "insert bidirectionally connected network nodes" (the two green dots icon), and start drawing. Place nodes at strategic locations, such as intersections, corners, and arcs. finally, place one node at the centerline of one of the runways. Once this is finished, one gate is connected to one end of one runway. The next job is to extend the network by connecting more gates and more runways.

Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-a] to deselect all objects. Then, select the point where you want to branch off from. Select this point using a left mouse click, while holding down the shift key. Since TaxiDraw is still in node connect mode, simply left-clicking would have resulted in placing a new node. With this node selected, continue drawing. Repeat this procedure until all runways are connected.

Then, start adding the additional gates to the network. Press [cntrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse, and start drawing unil the the gate in question is one segment away from being connected. Then, [shift left-click] the network node that this route segment should be connected to, and make sure that the correct node is selected. Then, right click, and select "connect nodes bidirectionally" from the AI nodes menu.

Repeat this procedure until all parking locations are connected to each runway.

==== Refining the network: Mark points on the runway as such ====
With the basic infrastructure in place, the next step is to fine-tune the network. The first step in this process is to mark the network nodes that are located on a runway. This is important for a number of reasons: Taxidraw needs these OnRunway points for it's network verification tool. Secondly, the use of the type of runway marking will be used in future versions of FlightGear for runway entrance / exit calculations, in addition to a host of other possible uses in routing (such as blocking a certain node then a crossing runway is in use, etc, etc).

It should be noted that there is no reason why TaxiDraw should not be able to mark the runway points as such automatically. After all, the geometry information of both runways and AI nodes is available. Although this automatic feature is planned, the TaxiDraw developers have as of yet not found the opportunity to implement this feature. Until that time, on runway marking has to be done by hand.

==== Refining the network: Set Holding points ====
Holding points are nodes in the network that do something special. They can be used by FlightGear to make traffic wait at certain specific locations. As a matter of fact, the 'normal' and 'Cat II/III' hold points are not yet used by FlightGear, but are part of the development plan. Currently, hold points are implicitly assigned by the FlightGear AI code. For instance, traffic waiting for takeoff clearance is holding at the first point before the runway. Likewise, traffic can receive a hold position instruction just before an intersection in the taxiway system, when traffic is approaching at the other leg. While these implicit hold points work reasonably, there are some limitations. Consider for example runway 07 at CYYC (Calgary Intl, Canada). In the FlightGear rendition of this airport, there are no taxiways leading to this runway, so departing aircraft should back track the runway from an entrance point at the middle of the runway. Currently that point will also become the runway entrance holding point. This is clearly undesirable, because it means that traffic is actually waiting ''on the runway'' in order to get clearance to enter it. For this reason, airport ground network designers should have a means to have explicit control over holding points. The normal hold point is meant for just that.

The Cat II/III hold point type is meant as an extension to this scheme for special IFR conditions. Support for these types in FlightGear is planned for a later stage of development though.

==== Refining the network: Pushback routes ====
With the above-mentioned refinements, the ground network should be fully working, with one notable exception. Aircraft will be driving forward when leaving the gate, making a sharp turn (while probably destroying themselves and the terminal building in the process). To prevent this, a ''push back'' route should be created. A push back route consists of at least one or more taxiway segments that have the "PushBack Route" property set to true. The last of these segments should be terminated by a PushBack HoldPoint network node.

Notice that a push back route is optional, but that parkings may never have more than one push back route. The formal criterium for a valid push back route is that each gate should have a maximum of one pushback node associated with it, which can be reached using one route only. From an editing point of view, it is sufficient to just mark a number of taxiway segments as push back, and mark the ending node as such as well.

It is important to note that the "Verify Ground network" process ''should be run'' in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups.

Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work.

[[File:TaxiDraw2.png|500px]]

==== Verifying the network ====
Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu.

Notice that TaxiDraw does not automatically fix problems. It is left to the user to fix the problems manually. TaxiDraw does select the offending node(s) / segments(s) for easier identification. Also note that TaxiDraw stops verifying at the first problem encountered, so it is worthwhile to continue checking until no further errors are found. Currently, the following checks are performed.

* '''On runway points''' Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function.
* '''Duplicate Taxiway Segments''' It's easy to connect two network nodes twice. While this doesn't really hurt, it does add dead weight, so checking for duplicates is not a bad thing.
* '''Routing''' One of the most persisting problems, headache causing problems is that of a disconnected parking in the network. FlightGear will happily place an aircraft there, but bail out when that aircraft cannot reach the runway. The routing check attempts to prevent this. Notice that it is of utmost importance that the OnRunway points are set correctly, because TaxiDraw relies on these points for it's route finding algorithm. Because the route finding algorithm is rather computationally intensive, some progress information is currently written to the console (a proper progress bar would be nice). When a disconnected parking is found, TaxiDraw selects both the parking and the runway node. It is still left to the user to trace a route between these two points and find where the two pieces are disconnected.
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.

=== Editing the startup location parameters ===
Once you have created a ground network, you'll find that it probably won't work yet in FlightGear. The main reason for this is that the default gate
size is set to a fairly small size, and most aircraft won't fit into the gate. Therefore, you'd need to edit the parking parameters. In addition,
you'd also need to give each parking a name, and a heading, and probably airlines codes. Changing name, and heading can be done in TaxiDraw, by right
clicking on the startup location. This will bring up a dialog, in which you can change latitude, longitude, heading, and name. Once you're done editing, click okay to accept the new values, or cancel to discard.

Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

You can edit the remaining parameters by loading this groundnet.xml file into a text editor. Once you are done editing make sure you import these changes into TaxiDraw immediately. Do this by going to [File| Import FlightGear AI Network]. This will open a file selection dialog. Choose the file you just edited and click okay. TaxiDraw will ask for confirmation to overwrite existing ground network data and confirm this by clicking on "yes".

=== Copying the ground network into FlightGear's scenery directory ===
Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in your <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory, with the three first letters of the ICAO code of your airport. For example <tt>[[$FG_SCENERY]]/Airports/E/H/A/</tt>. Next, locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to <tt>[ICAO].groundnet.xml</tt>.

=== Testing the network ===
Startup flightGear at the airport for which you have just created the network, and make sure you have traffic for that aircraft. FlightGear will check the network and report errors on the console. Aircraft than can't be placed at one of the parking locations will be placed at a default location.

If the FlightGear AI system can't find a valid route between startup location and runway, it will list which nodes are not connected and exit.

=== Airports with ground networks ===
As of Sep.2015 Flightgear has 90 airports that were made with Taxidraw.
Here is a List: [[Airports with ground networks]]
[[user:laserman]] is offering additional groundnet.xml files for 900 airports that were automatically converted from apt.dat at this URL: http://media.lug-marl.de/flightgear/Airports.tgz

== SIDs / STARs ==
SID is an acronym for Standard Instrument Departure. Likewise, STAR is an acronym for [[Standard Terminal Arrival Route]]. Directly after takeoff, in particular at busy airports, aircraft follow a standard flightpath, that will keep them safely separated from arriving traffic, avoid ground obstructions, and also keeps traffic away from populated areas as much as possible. Currently, steps are in progress to allow FlightGear traffic to follow SIDs. Ultimately, the plan is to provide SID and star data in a format that can also be used by the user controlled Aircraft's Flight Management Computer. Currently, some sample data exist in the form of a PropertyList formatted xml file that contains a list of waypoints.

This section of the AI Traffic documentation is meant as a stub that keeps track of the current development. At the moment of writing, some proof-of-principle data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of these data. Note that these data are meant to be just that; a proof of principle. User contributions will be accepted as soon as the format has stabilized.

== Appendix: Special Notes ==
=== Realism ===
With [[FGFS 1.0.0]] Interactive Traffic also responds to other Non-AI aircraft.
The [[Airbus A320|A320]] ( and maybe some others) has working flaps and gears.

=== Perfomance ===
With the recent versions, we have much better performance than before, so realistic density of traffic is currently possible even for slower computers. For those who are still afraid, there is an, as of yet, unpublished feature: set a new property "/sim/traffic-manager/proportion" to any value between 0 and 1 in your preferences.xml. During program start up, the traffic manager draws a random number (between 0 and 1) for each aircraft, and if that random number is smaller than the value specified in /sim/traffic-manager/proportion, the aircraft is added, otherwise it is discarded. In essence, only the specified proportion of aircraft will be loaded.

Unfortunately you can't change this at runtime yet, so you need a little bit trial and error! However, it should allow the combination of slower computers and dense traffic files.

== Related content ==
* [[Flightplan XML formats]]
* [[Status of AI in FlightGear]]

== External link ==
* [http://www.xs4all.nl/~dtalsma/FlightGear.html The FlightGear AI aircraft download page]{{dead link|2012-11}}

[[de:Interaktiver Verkehr]]

[[Category:Artificial intelligence]]
[[Category:FlightGear feature]]

Fr/TerraGear

2016-01-06T09:41:10Z

F-ojac: /* Avec le script download_and_compile.sh */

<div style="padding-left:20px;">''Ne pas confondre avec [[Fr/TerraSync|TerraSync]], outil de téléchargement de scènes à la volée.''</div>

[[File:TerraGear The Hague wireframe.png|thumb|270px|Une vue en fil de fer d'une scène détaillée avec données [[CORINE]] et [[OSM]] (OpenStreetMap), générée par TerraGear.]]
'''TerraGear''' est un ensemble d'outils open source et de librairies de rendu qui peut transformer les données SIG disponibles publiquement en représentations 3D (c'est à dire des modèles 3D ou des cartes 3D) de la Terre leur utilisation dans des projets de rendu en temps réel. TerraGear peut importer des données 3D comme les grilles de terrain DEM, des ensembles de données 2D polygonales comme les contours des côtes, les délimitations des villes, le contour des lacs, et les ensembles de données raster 2D comme les plans d'occupation des sols NAOO 1 km. Il comprend également les outils pour générer des [[Airport|aéroports]] réalistes, des pistes et des éclairages selon les données FAA disponibles.
TerraGear est l'outil de base principal pour générer les [[Fr/Scenery|scènes]] du projet [[Fr/FlightGear|FlightGear]].

== Introduction ==
Pour de nombreuses raisons, vous pourriez vouloir construire vous-même le terrain, plutôt que de le télécharger à partir des scènes disponibles sur FlightGear. Par exemple, si vous utilisez [[WED]] pour créer ou modifier l'agencement d'un aéroport, vous pourriez vouloir visualiser comment l'aéroport une fois modifié se présente dans les scènes, avant de décider si vous êtes content du résultat. Et normalement, pour visualiser et utiliser l'aéroport dans les scènes, il faut soumettre les modifications à XPlane et attendre la prochaine mise à jour de la zone concernée via [[TerraSync]] ou dans les [http://www.flightgear.org/Downloads/scenery.html données officielles de scènes de FlightGear]. Si vous parvenez à construire le terrain vous-même, vous pouvez commencer à l'utiliser immédiatement.

Peut-être que les scènes officielles sont trop détaillées pour votre machine un peu ancienne, et que vous voudriez construire un terrain avec un DEM (modèle numérique de terrain) de plus faible résolution, afin de diminuer le nombre de polygones et ainsi augmenter votre taux de rafraichissement d'image. Soit vous avez une machine ultra-rapide, et vous voulez construire votre propre terrain avec des données vectorielles de plus haute résolution (vmap1, Tiger) pour obtenir de meilleures routes/rivières. Pour toutes ces raisons, utiliser TerraGear est une bonne idée.

== Obtenir TerraGear ==
=== Avec le script download_and_compile.sh ===
Téléchargez le script download_and_compile.sh si vous ne l'avez pas déjà. Copiez-le dans un répertoire particulier, il n'est pas nécessaire d'être root pour l'exécuter.
<syntaxhighlight lang="bash">
wget http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
mv download_and_compile.sh?format=raw download_and_compile.sh
chmod 755 download_and_compile.sh
./download_and compile.sh SIMGEAR TERRAGEAR
</syntaxhighlight>
Cela compilera SIMGEAR (pré-requis) et TERRAGEAR, ainsi que leurs dépendances respectives si nécessaire et vous aurez terminé la partie compilation.

=== Versions pré-compilées ===
* [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip dernières versions pour Windows], construites par le [[FlightGear Build Server]].
* [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32 Binaires Windows] (anciens)

=== Sources ===
Les sources sont maintenues dans un dépôt [[Fr/FlightGear_et_Git|git]] de Sourceforge.
git clone git://git.code.sf.net/p/flightgear/terragear flightgear-terragear

== Compilation ==
=== Dépendances ===
* TerraGear
** [[SimGear]] - '''Pas''' simgear-cs! (paquetage simgear-dev)
*** SimGear peut être compilé sans support OSG, éliminant ainsi de nombreuses dépendances. Utilisez l'option "-DSIMGEAR_HEADLESS=YES" pour une construction minimale.
** libnewmat - au moins version newmat11 (qui est en version beta actuellement). Voir [http://mapserver.flightgear.org/git/?p=terragear-cs;a=blob;f=README.newmat;h=95570b6b279d3d00bd7664cd4f00d6c4802aed1b;hb=HEAD README.newmat] pour plus d'informations sur comment l'obtenir/l'installer
** [http://pocoproject.org/ POCO] - Pour support multiprocesseurs
** [http://www.cgal.org/ CGAL] - Pour les calculs géométrique de haute précision
** [http://www.gdal.org/ libgdal]
** libexpat

=== Construction ===
cmake . [options]
make install
Options pour <tt>cmake</tt>:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Plate-formes spécifiques ===
* Debian : [[Building FlightGear - Debian#TerraGear]]
* Gentoo : <tt>emerge -av terragear</tt> Voir [[Building Flightgear - Gentoo]].
* Ubuntu : [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== Interface graphique ==
L'interface graphique [[TerraGear GUI]] est disponible pour ceux qui ne savent pas utiliser ou n'utilisent pas les options en lignes de commande.

== Contenu connexe ==
* [[Fr/Utiliser_TerraGear|Utiliser TerraGear]]
* [[Fr/TerraGear_CORINE|TerraGear CORINE]]
* [[TerraGear Documentation]]

{{Terra}}
{{Building}}

[[Category:Scenery enhancement]]
[[en:TerraGear]]
[[es:TerraGear]]

TerraGear

2016-01-05T21:20:22Z

F-ojac: /* Using the download_and_compile.sh script (Linux distros using apt) */

{{Hatnote|Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.}}

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[WED]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Using the download_and_compile.sh script (Linux distros using apt) ===
Get the script download_and_compile.sh if you don't already have it. Copy it into a specific directory, no need to be root.
<syntaxhighlight lang="bash">
wget http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
mv download_and_compile.sh\?format\=raw download_and_compile.sh
chmod 755 download_and_compile.sh
./download_and compile.sh SIMGEAR TERRAGEAR
</syntaxhighlight>
This will build SIMGEAR (pre-requisite) and TERRAGEAR properly, installing dependencies if necessary and you will be done for the TG compilation part of the process.

=== Pre-compiled builds ===
* [http://build.flightgear.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[Git]] repository at SourceForge and a mirror at mapserver.
<syntaxhighlight lang="bash">
git clone http://mapserver.flightgear.org/git/terragear
</syntaxhighlight>

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
* Debian: [[Building FlightGear - Debian#TerraGear]]
* Gentoo: <tt>emerge -av terragear</tt> See [[Building Flightgear - Gentoo]].
* Ubuntu: [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear]]

[[es:TerraGear]]
[[fr:TerraGear]]

TerraGear

2016-01-05T21:19:18Z

F-ojac: /* Using the download_and_compile.sh script (Linux distros using apt) */

{{Hatnote|Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.}}

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[WED]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Using the download_and_compile.sh script (Linux distros using apt) ===
Get the script download_and_compile.sh if you don't already have it. Copy it into a specific directory, no need to be root.
<syntaxhighlight lang="bash">
wget http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
mv download_and_compile.sh?format=raw download_and_compile.sh
chmod 755 download_and_compile.sh
./download_and compile.sh SIMGEAR TERRAGEAR
</syntaxhighlight>
This will build SIMGEAR (pre-requisite) and TERRAGEAR properly, installing dependencies if necessary and you will be done for the TG compilation part of the process.

=== Pre-compiled builds ===
* [http://build.flightgear.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[Git]] repository at SourceForge and a mirror at mapserver.
<syntaxhighlight lang="bash">
git clone http://mapserver.flightgear.org/git/terragear
</syntaxhighlight>

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
* Debian: [[Building FlightGear - Debian#TerraGear]]
* Gentoo: <tt>emerge -av terragear</tt> See [[Building Flightgear - Gentoo]].
* Ubuntu: [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear]]

[[es:TerraGear]]
[[fr:TerraGear]]

Release plan

2016-01-05T20:37:07Z

F-ojac: Typo

{{Note|1=As of December 2015, the release plan is in the process of being changed so that the description below will no longer be accurate:

{{FGCquote
|1= Hi Everybody,

Today, December 17th would be the day to announce the feature freeze for
3.8 if we were following the usual release schedule.

A while ago I proposed a change in that schedule and I have spent some time
on preparing the scripts for an automated release process since then. I
think I have pretty much everything ready to go for automated releases and
now I'd like to give it a first try for the 3.8 release next year.

For the first execution, I'd like to trigger the scripts manually on my
local machine instead of Jenkins to have some better control of it. If it
works out as expected, I'll put this onto our Jenkins server afterwards to
be executed automatically for the release following after 3.8.

For now, I propose the following and would do so if nobody objects:
* There is no feature freeze for the next (3.8) and the following releases
* On Jan., 17th I trigger my first script to create release/3.8 branches with version 3.8.1 (!)
* Immediately after that I let Jenkins create the binaries for 3.8.1 and we have our first release
* Patches going into the release/3.8 branch automatically trigger a new build with a previous increase of the micro version number (3.8.2, 3.8.3,..) and we immediately have a bugfix release
* On 'next', version numbers go to 3.9.0
* Nightly builds are created from next after every push in that branch

After a to-be-defined period (my proposal: 3 month) we start over:
* Create a release/3.9 branch with version 3.9.1
* etc. etc.

Note: there will be no odd-even version number scheme (odd equals unstable,
even equals stable). Instead, x.x.0 is unstable, nightly from next and
x.x.n where n >= 1 is a stable release.

If everything works as expected, we have a major release every
to-be-defined months, a bugfix release after every push to the release
branch and a nightly build after every push to 'next'.

I hope this sounds reasonable and keeps everybody happy.

Feedback welcome.

Torsten
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34701971/
| title = <nowiki>[Flightgear-devel] Relesae 3.8</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Dec 17th, 2015
}}
}}
}}

{{GitStatus}}

The '''release plan''' is the process by which a new version of [[FlightGear]] is released. The release plan is actually a continual work-in-progress, and is refined with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
The current release plan was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{fullurl:{{FULLPAGENAME}}|action=edit}} edit this page]. In particular, improvements should be based on [[Release plan/Lessons learned|lesson learned]] from past releases. Please discuss this concept on the [[mailing list]].

== General release concept ==
New FlightGear releases are scheduled twice a year. The magic number to remember is 17. On the 17th of January (the first month) and July (the seventh month), a new release branch is created for [[SimGear]], the FlightGear source, and [[fgdata]].

{{Cquote
|As a clarification: We do not enter a code freeze but a feature freeze. Code changes are welcome after December 17th as long as it is guaranteed (not just "unlikely") that they do not introduce any side effects and become a release blocker. It is the sole responsibility of the committer to decide if that is the case or not. Every new feature that didn't make it into the repository by the deadline may probably easily wait for another four weeks to get committed. Remember: most aircraft are not affected by the feature freeze and aircraft developers quickly adopt and use new features as they become available
| {{cite web
| url = http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html
| title = <nowiki>[Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki>
| author = Torsten Dreyer
| date = 16th Nov 2012
}}
}}

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and fgdata takes place around the 18th of February and the 18th of August. Allowing a few days for distribution of the files, new versions should be publicly available around the 20th of February and August.

The development stream of [[SimGear]], FlightGear, and fgdata is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

== Version numbers ==
FlightGear version numbers consist of three digits, seperated by dots:
* '''Major''' (2.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).
* '''Minor''' (2.4.1): has two applications:
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release was 2.8.0, the current development stream is 2.9.0.
* '''Revision''' (2.4.1): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.

When referring to a major release in general, only the first two digits should be used, i.e. 2.6 refers to 2.6.0, 2.6.1 etc.

== Detailed time schedule and checklist ==
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state, add a call for screenshots
##Create a "release preperations" topic at the forum and make it a "Global Announcement", add a call for screenshots
##Ask for translator for a review of the translations of the menu, help and startup entries in case there have been some mods on those files
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next, fgrun/next and fgdata/master to an even number (2.9.0 -> 3.0.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear+fgrun) and master(fgdata)
##Tag (annotated) flightgear, simgear, fgrun and fgdata with <tt>version/3.0.0</tt>
##:<code>git tag -a version/3.0.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.0.0</code>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgrun/fgdata):
##:<code>git pull</code>
##:<code>git branch release/3.0.0</code>
##On the next/master branches, bump up the version-number of simgear, flightgear, fgrun and fgdata to an odd number (3.0.0 -> 3.1.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear, fgrun and fgdata with "version/2.9.0"
##:<code>git tag -a version/2.9.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream
##:for flightgear, simgear, fgrun and fgdata: <code>git push origin release/3.0.0</code>
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.1.0</code>
##Declare dev-streams "open" or "green"
##: Ask a [http://wiki.flightgear.org/index.php?title=Special:ListUsers&group=sysop wiki admin] to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James or Clément for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
##:in fgmeta:
##:<code>git checkout release/3.0.0</code>
##:<code>git submodule foreach git checkout release/3.0.0</code>
##:<code>git submodule foreach git pull -r</code>
##:<code>git add .</code>
##:<code>git commit -m "Bump revision"</code>
##:<code>git push origin release/3.0.0</code>
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/3.0.0 branches of simgear, flightgear, fgrun and fgdata and push the tags.
##:for flighgear, simgear, fgrun and fgdata: <code>git tag version/3.0.0-final</code>
##:for flighgear, simgear, fgrun and fgdata: <code>git push origin version/3.0.0-final</code>
##Merge the branch release/3.0.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear, fgrun and simgear:
##:<code>git checkout -b master origin/master</code> or <code>git checkout master</code> if you already have the local branch
##:<code>git merge version/3.0.0-final</code>
##:<code>git push origin master</code>
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.

== To bump up the version number ==
* fgdata
** edit the {{fgdata file|version|t=version}} file
* SimGear
** edit the {{simgear file|version|t=version}} file
* FlightGear
** edit the {{flightgear file|version|t=version}} file
* FGRun
** edit the [http://sourceforge.net/p/flightgear/fgrun/ci/next/tree/version version] file

== Definition of repository states ==
{| class="wikitable"
!
! State
! Description
|-
! [[File:Traffic light green.png|20px]]
! Open/Green
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five months after the release branches were created.
|-
! [[File:Traffic light yellow.png|20px]]
! Frozen/Yellow
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.
|-
! [[File:Traffic light red.png|20px]]
! Closed/Red
| Nothing shall be pushed to the development streams (simgear, flightgear, fgrun and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.
|}

== Bug fix committing policy ==
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

== Bug tracking ==
The [http://sourceforge.net/p/flightgear/codetickets/ bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.12.0 the list of fixed bugs].

=== Tasks and owners ===

The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.

{| class="wikitable"
! Stage
! width="500px" | Task
! Owner(s)
|-
! rowspan="7" | Preparation
| Announce the state-change of the dev-streams, '''cross-post to JSBSim list''' (see lessons learned!)
| TorstenD
|-
| Create/maintain the git branches
| TorstenD
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Sync the language files so they can be translated
| ThorstenB, James
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|-
| Pack RC and final version of fgdata
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|-
| MacOS
| Tat/James
|-
| Distribute files to download servers
| Curt
|-
! rowspan="3" | Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
| Generate aircraft page
| Curt, Gijs
|-
| Tag the [http://wiki.flightgear.org/index.php?title=Talk:Next_newsletter&action=edit&section=45 newsletter template] according to the released version
<nowiki>[[Category:Changes after 2.12]]</nowiki>
| Hooray, Gijs, Stuart (other wiki admins)
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Next changelog]]
| All developers/contributors
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazines.
| '''EVERYBODY'''
|}

== Open items, questions ==
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it."<ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html |title=<nowiki>Re: [Flightgear-devel] Release candidates</nowiki> |author=Torsten Dreyer |date=29 January 2013}}</ref>
* <del>Automate the creation of Windows and Mac installers</del> {{Done}} <ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40650.html</ref> (see [[FlightGear Build Server]])
* Automate the creation of fgdata distribution
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests <ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40201.html |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
{{Cite web |url=http://sourceforge.net/p/flightgear/mailman/message/31762085/
|title=<nowiki>Release preparations - feature freeze starts today</nowiki> |author=Anders Gidenstam |date=2013-12-17 19:46:48}}
</ref>

== Lessons learned ==
See [[Release plan/Lessons learned]] for a list of things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.

{{Appendix}}

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Scenery infrastructure

2015-11-18T20:46:10Z

F-ojac: /* The webserver */

The logical and physical infrastructure on which the scenery (terrain, objects) relies on is quite a mistery for a lot of FG users.
This article aims to detail how the infrastructure works.

= Physical Infrastructure =
The current infrastructure relies on one server, called Sphere, hosted freely and gracefully by the people at [http://www.telascience.org/project-definition Telascience].
Some users also freely and gracefully set up servers to host Terrasync to speed up and cache the data depending on the location. Squid configuration file for those are stored here : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/Squid

= Logical Infrastructure =
As you may already know, scenery is a combination of terrain and objects. However, they all share common resources, mainly a PostGIS database.
All those services are, at the moment, hosted on the same server.
== The PostGIS database ==
This geospatial database contains .
* all geographical layers, whether generic (VMAP0, Corine LandCover, OSM...) or specific to FG (custom landcovers) in specific tables ;
* common geographical data (countries definitions...) ;
* all objects and models created by FG users and uploaded to the website scenemodels.flightgear.org (which interfaces with some tables in this PostGIS database, via PHP).
Functions are available on git : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/SQL/
== The webserver ==
It serves the following scenery websites:
* the [http://mapserver.flightgear.org/ Mapserver] website, sourcecode is here: http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/scenemodels/ ;
* the [http://scenemodels.flightgear.org/ Scenemodels] website, which sourcecode is available on git http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/scenemodels/ . The size of the backup is approximately 1.4 Gb ;
* the TGWeb tool, used to test new/updated airport layouts, before submitting them : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/tgweb/
* the main Terrasync SVN repository : http://scenery.flightgear.org/websvn/listing.php?repname=repos+1
* it also hosts the FG manual in various languages.
The Apache configuration is mostly hosted on Git : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/Apache

== The programming interface ==
Most tools used on this server use PHP to interface between Apache and the PostGIS database. The sourcecode of the site is here: http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/
== Various tools ==
Given the hosting performances and the data available on that server, it is also used as FG [[Terragear]] server with the full toolchain. This is where the [[World Scenery]] sets are created (takes a while and a lot of CPU/RAM/disk resources!).
Terrasync is in fact an regular automatic process looking for updates in the PostGis database and creating the corresponding .stg files and pushing the whole (.stg updates, 3D models, png and xml files) onto the Terrasync svn repository, which is grabbed, via the proxies, when a user starts a new FG session.
== LaTeX ==
This server also hosts the LaTeX building infrastructure for the manual. The source code of the manual is here: http://sourceforge.net/p/flightgear/getstart/ci/master/tree/ .

Scenery infrastructure

2015-11-18T20:16:15Z

F-ojac: Update

The logical and physical infrastructure on which the scenery (terrain, objects) relies on is quite a mistery for a lot of FG users.
This article aims to detail how the infrastructure works.

= Physical Infrastructure =
The current infrastructure relies on one server, called Sphere, hosted freely and gracefully by the people at [http://www.telascience.org/project-definition Telascience].
Some users also freely and gracefully set up servers to host Terrasync to speed up and cache the data depending on the location. Squid configuration file for those are stored here : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/Squid

= Logical Infrastructure =
As you may already know, scenery is a combination of terrain and objects. However, they all share common resources, mainly a PostGIS database.
All those services are, at the moment, hosted on the same server.
== The PostGIS database ==
This geospatial database contains .
* all geographical layers, whether generic (VMAP0, Corine LandCover, OSM...) or specific to FG (custom landcovers) in specific tables ;
* common geographical data (countries definitions...) ;
* all objects and models created by FG users and uploaded to the website scenemodels.flightgear.org (which interfaces with some tables in this PostGIS database, via PHP).
Functions are available on git : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/SQL/
== The webserver ==
It serves the following scenery websites:
* the [http://mapserver.flightgear.org/ Mapserver] website, sourcecode is here: http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/scenemodels/ ;
* the [http://scenemodels.flightgear.org/ Scenemodels] website, which sourceode is available on git http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/scenemodels/ ;
* the TGWeb tool, used to test new/updated airport layouts, before submitting them : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/tgweb/
* the main Terrasync SVN repository : http://scenery.flightgear.org/websvn/listing.php?repname=repos+1
* it also hosts the FG manual in various languages.
The Apache configuration is mostly hosted on Git : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/Apache
== The programming interface ==
Most tools used on this server use PHP to interface between Apache and the PostGIS database. The sourcecode of the site is here: http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/
== Various tools ==
Given the hosting performances and the data available on that server, it is also used as FG [[Terragear]] server with the full toolchain. This is where the [[World Scenery]] sets are created (takes a while and a lot of CPU/RAM/disk resources!).
Terrasync is in fact an regular automatic process looking for updates in the PostGis database and creating the corresponding .stg files and pushing the whole (.stg updates, 3D models, png and xml files) onto the Terrasync svn repository, which is grabbed, via the proxies, when a user starts a new FG session.
== LaTeX ==
This server also hosts the LaTeX building infrastructure for the manual. The source code of the manual is here: http://sourceforge.net/p/flightgear/getstart/ci/master/tree/ .

Scenery infrastructure

2015-11-18T19:58:03Z

F-ojac: Page creation. Bit of a stub right now.

The logical and physical infrastructure on which the scenery (terrain, objects) relies on is quite a mistery for a lot of FG users.
This article aims to detail how the infrastructure works.

= Physical Infrastructure =
The current infrastructure relies on one server, called Sphere, hosted freely and gracefully by the people at [http://www.telascience.org/project-definition Telascience].
Some users also freely and gracefully set up servers to host Terrasync to speed up and cache the data depending on the location. Squid configuration file for those are stored here : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/Squid

= Logical Infrastructure =
As you may already know, scenery is a combination of terrain and objects. However, they all share common resources, mainly a PostGIS database.
All those services are, at the moment, hosted on the same server.
== The PostGIS database ==
This geospatial database contains :
- all geographical layers, whether generic (VMAP0, Corine LandCover, OSM...) or specific to FG (custom landcovers) in specific tables ;
- common geographical data (countries definitions...) ;
- all objects and models created by FG users and uploaded to the website scenemodels.flightgear.org (which interfaces with some tables in this PostGIS database, via PHP).
Functions are available on git : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/SQL/
== The webserver ==
It serves the following scenery websites:
- the [http://mapserver.flightgear.org/ Mapserver] website, sourcecode is here: http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/scenemodels/ ;
- the [http://scenemodels.flightgear.org/ Scenemodels] website, which sourceode is available on git http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/scenemodels/ ;
- the TGWeb tool, used to test new/updated airport layouts, before submitting them : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/tgweb/
- the main Terrasync SVN repository : http://scenery.flightgear.org/websvn/listing.php?repname=repos+1
- it also hosts the FG manual in various languages.
The Apache configuration is mostly hosted on Git : http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/Apache
== The programming interface ==
Most tools used on this server use PHP to interface between Apache and the PostGIS database. The sourcecode of the site is here: http://sourceforge.net/p/flightgear/sceneryweb/ci/master/tree/WWW/
== Various tools ==
Given the hosting performances and the data available on that server, it is also used as FG [[Terragear]] server.
Terrasync is in fact an regular automatic process looking for updates in the PostGis database and creating the corresponding .stg files and pushing the whole (.stg updates, 3D models, png and xml files) onto the Terrasync svn repository, which is grabbed, via the proxies, when a user starts a new FG session.
== LaTeX ==
This server also hosts the LaTeX building infrastructure for the manual. The source code of the manual is here: http://sourceforge.net/p/flightgear/getstart/ci/master/tree/ .

Howto:Edit a livery

2015-08-04T19:24:24Z

F-ojac: Typos

[[File:PC-9M Slovenian Livery.png|150px|thumb|right|Slovenian livery for pjedvaj's second version of the [[Pilatus PC-9M]].]]
[[File:Finished Slovenian PC-9M livery (3DViewer screenshot).png|150px|thumb|right|3DViewer screen shot of a finished livery draped over the model.]]
[[File:Finished Slovenian PC-9M livery (in-game screenshot).png|150px|thumb|right|FlightGear 2.0.0 in-game screen shot with the finished livery.]]

By '''editing a livery''' you can give an aircraft a new paint job, a new ''livery''. In some other flight simulators and games a livery can be called a ''paint (scheme)'' or ''repaint''. A livery consists of one or more textures, wrapped around the 3D model representing the aircraft, together with an XML file needed for FlightGear to know which texture(s) to use.

This [[:Category:howto|howto]] is intended to be a help guiding potential livery artists as well as the more experienced ones needing a refresher.

== Where to find an aircraft livery ==
The installed aircraft can be found in <tt>$FG_ROOT/data/Aircraft</tt>, where <tt>$FG_ROOT</tt> is where FlightGear is installed. Each aircraft has a directory that contains a few text, 3D model and image files organized in several subdirectories. In that structure is one or more liveries and one or more text files, XML files, describing it's use. The liveries can usually be found in the <tt>../Models</tt>, <tt>../Liveries</tt>, <tt>../Models/Liveries</tt> or some other directory, depending on how the aircraft's author organized the files and directories.

== General work flow ==
There are a few ways to make a new livery. First of all have a look at the [[FlightGear livery database]], to make sure you don't duplicate someones else's work. You can also download templates for liveries, called ''paintkits'', there for a few aircraft, but usually paintkits are included with the aircraft.

When creating the livery, the work flow is basically in this order:
# Check the FlightGear Livery Database, to avoid duplicate work,
# Find reference images,
# Get a paintkit, if available,
# Make the livery,
# Share the livery.

== Finding reference images ==
To do a good livery based on a real aircraft you simply have to have reference images to look at while making the livery. You will need images from both sides of the fuselage, images of the top and bottom, and a lot of close in images of details. Make sure you also have images from an angle. Having a three way drawing can be helpful, specially if you want to add rivet lines, or if there was no paintkit available.

Make sure you have a lot of good reference images of the aircraft livery you want to make. A list of websites containing such images can be found at the bottom of this article.

== Editing the texture ==
[[File:Vector vs Raster Graphics.png|150px|thumb|right|One pixel line width square and circle together with a gradient. Left side is a vector image, right side a raster image. Both are exported 20 times larger.]]
[[File:Livery layers in Inkscape (Slovenian PC-9M).png|150px|thumb|right|Inkscape layer dialogue. The four top top layers are the paintkit, while the rest of the layers are the livery.]]

To be on the safe side copy the aircraft folder to some other place and work on the livery in the copied directory.

=== Vector or raster ===
There are in general two ways to edit the livery: Using a raster image editor such as GIMP or Photoshop or using a vector graphics editor such as Inkscape or Illustrator. GIMP and Inkscape are both free and open source software. If you don't have experience with a vector editor there's a bit of a learning curve, but after you have passed it a vector editor can be more rewarding, as you can more easily adjust, scale and rotate elements in the livery such as warning labels, stripes and cabin windows. Vector images also have the great advantage of having the possibility to later make a higher resolution livery in a snap.

=== Using layers ===
When editing the livery, have the template in one or more layer, adding the elements of your livery in other layers. Another good idea if you are using a raster editor is to have individual elements as separate layers to be able to move them around if necessary.

=== Saving the files ===
''Start'' the work by saving your livery while it is still empty. That way you will not get carried away, forgetting to save it just to be reminded in the harshest way, maybe having hours of work lost. The file should usually have a size of 1024*1024 pixels, but it does not have to be a square and any rectangle with 2n pixels side, for example 256, 512 and 2048 pixels, will do. Larger image size will result in more detail being shown, but also a slower running FlightGear. In particular, users with lower end computer might experience a delay when loading the model and texture of other multiplayer aircraft coming within a certain distance.

If you are working with raster files, remember to use a two or four times larger size, while working on the livery, in case you later on need a livery in a larger size. When you are done you can save a version in the right size. Save the file in a larger size also when creating a raster image paintkit from scratch.

While working on the livery save the file in different versions while you are adding new features, so you don't end up messing your ''only'' file up by mistake. Copy the file, with the right size, to the aircraft's <tt>Models</tt> directory or <tt>Models/Liveries</tt> directory, depending on how the original author organized the aircraft's folders, and name it default.png.

=== Viewing the livery in 3D ===
While you are working on the livery it is a good idea to load it into a 3D viewer, turning the model around and comparing it to your reference images at regular intervals.

To be able to check the livery on a model there are three ways, you can either
* use '''[[FGRun]]'s''' built in viewer at the aircraft page to look at the model, which is rather slow.
* use '''3DViewer''', a neat, small and fast viewer.
* use the 3D modeller '''[[Blender]]''', which has quite a steep learning curve.

My recommendation is 3DViewer, since it is small and fast.

=== Naming your livery ===
Lastly, when done give the livery a proper name. For hints on airliners etc. have a look at the [http://liveries.flightgear.org/contribute.php livery database's contribute page]. It is usually a good idea to have aircraft model and airline, possibly also years it was used in the file name.

== Editing the livery XML file ==
On aircraft that supports changing the livery shown to other MP pilots there are one XML file for each livery. The livery XML file usually is named as the livery file, except for the file type extension, and in its simplest form it can look something like this:
<syntaxhighlight>
<?xml version="1.0"?>

<propertylist>
<sim>
<model>
<livery>
<name>Full livery name</name> 
<texture>Livery.png</texture> 
</livery>
</model>
</sim>
</propertylist>
</syntaxhighlight>

The livery XML file sets up a few [[Property tree|properties]] used by the aircraft when changing the livery. In the above example the properties will be <tt>sim/model/livery/name=Full livery name</tt> and <tt>sim/model/livery/texture=Livery.png</tt>.

Many aircraft has additional properties that are set up in a similar way. There can for example be separate livery textures for the fuselage, wings and tail. As always it is a good idea to look at the existing XML files of the aircraft you want to make additional liveries for. Also the simplest way to make a new one is to copy and modify an existing file and save it under a new name.

== Sharing your work ==
Please consider sharing your work on the forum, and in the case it is a real livery and doesn't have parts of non-free images, also the livery database under the GPL license.

=== Showing your livery at the FlightGear forum ===
In order to show your liveries at the forum you have to be registered and have uploaded your images of the livery to some external image host like Picasa, Flickr, imageshed or something similar.

On the forum there are sometimes a topic for the development of an aircraft as well as a sparate topic for liveries to the same aircraft. Use the forums search function to find any already existing topics. If you cannot find one, make a new one in the [http://www.flightgear.org/forums/viewforum.php?f=13 liveries development] subforum with the name of the aircraft somewhere in the topic's title.

To add the image to your post use your image host's share function or if you do not find it use <tt>[img]</tt> tags like this <tt>[img]<URL to image>[/img]</tt>.

To share your livery you have to upload it to a file host and link to it with the <tt>[url]</tt> tags like this <tt>[url=<URL to file>]<Description of file>[/url]</tt>.

=== Uploading to the FlightGear Livery Database ===
You can upload your liveries to the official livery database using [http://liveries.flightgear.org/contribute.php a web form]. Please read the rules and tips carefully before sending in your livery.

== A pledge to aircraft developers and livery artists ==
Some one else would likely want to have a try at liveries for the aircraft you are working on. When you are developing an aircraft or are making a new livery for an aircraft without a painkit, please consider making a paintkit for that aircraft. Also consider that the aircraft will more likely get higher quality liveries and more liveries if your paintkit is of high quality.

== Related content ==
* [[Livery over MP]], describes how to equip an aircraft with a livery system.

== External links ==
* [http://liveries.flightgear.org/index.php FlightGear Livery Database]
* [http://www.unitedfreeworld.com/ Unitedfreeworld.com]

=== Web sites for reference images ===
A small selection. Many, many more are available these days.
* [http://www.google.se/imghp Google image search] The obvious
* [http://www.airliners.net/ Airliners.net] Well known
* [http://www.airplane-pictures.net/ Airplane-Pictures.net] Many ways to browse through the images
* [http://www.jetphotos.net/ JetPhotos.Net]
* [http://www.planepictures.net/ PlanePictures]

=== 3D Viewers ===
* [http://karelse.home.xs4all.nl/3DViewer/ 3DViewer] Small, neat and fast.

[[Category:Aircraft enhancement|Edit a livery]]
[[Category:Howto|Edit a livery]]

[[de:Howto: Edit a livery]]

Howto:Edit a livery

2015-08-04T19:20:14Z

F-ojac: Typos

[[File:PC-9M Slovenian Livery.png|150px|thumb|right|Slovenian livery for pjedvaj's second version of the [[Pilatus PC-9M]].]]
[[File:Finished Slovenian PC-9M livery (3DViewer screenshot).png|150px|thumb|right|3DViewer screen shot of a finished livery draped over the model.]]
[[File:Finished Slovenian PC-9M livery (in-game screenshot).png|150px|thumb|right|FlightGear 2.0.0 in-game screen shot with the finished livery.]]

By '''editing a livery''' you can give an aircraft a new paint job, a new ''livery''. In some other flight simulators and games a livery can be called a ''paint (scheme)'' or ''repaint''. A livery consists of one or more textures, wrapped around the 3D model representing the aircraft, together with an XML file needed for FlightGear to know which texture(s) to use.

This [[:Category:howto|howto]] is intended to be a help guiding potential livery artists as well as the more experienced ones needing a refresher.

== Where to find an aircraft livery ==
The installed aircraft can be found in <tt>$FG_ROOT/data/Aircraft</tt>, where <tt>$FG_ROOT</tt> is where FlightGear is installed. Each aircraft has a directory that contains a few text, 3D model and image files organized in several subdirectories. In that structure is one or more liveries and one or more text files, XML files, describing it's use. The liveries can usually be found in the <tt>../Models</tt>, <tt>../Liveries</tt>, <tt>../Models/Liveries</tt> or some other directory, depending on how the aircraft's author organized the files and directories.

== General work flow ==
There are a few ways to make a new livery. First of all have a look at the [[FlightGear livery database]], to make sure you don't duplicate someones else's work. You can also download templates for liveries, called ''paintkits'', there for a few aircraft, but usually paintkits are included with the aircraft.

When creating the livery, the work flow is basically in this order:
# Check the FlightGear Livery Database, to avoid duplicate work,
# Find reference images,
# Get a paintkit, if available,
# Make the livery,
# Share the livery.

== Finding reference images ==
To do a good livery based on a real aircraft you simply have to have reference images to look at while making the livery. You will need images from both sides of the fuselage, images of the top and bottom, and a lot of close in images of details. Make sure you also have images from an angle. Having a three way drawing can be helpful, specially if you want to add rivet lines, or if there was no paintkit available.

Make sure you have a lot of good reference images of the aircraft livery you want to make. A list of websites containing such images can be found at the bottom of this article.

== Editing the texture ==
[[File:Vector vs Raster Graphics.png|150px|thumb|right|One pixel line width square and circle together with a gradient. Left side is a vector image, right side a raster image. Both are exported 20 times larger.]]
[[File:Livery layers in Inkscape (Slovenian PC-9M).png|150px|thumb|right|Inkscape layer dialogue. The four top top layers are the paintkit, while the rest of the layers are the livery.]]

To be on the safe side copy the aircraft folder to some other place and work on the livery in the copied directory.

=== Vector or raster ===
There are in general two ways to edit the livery: Using a raster image editor such as GIMP or Photoshop or using a vector graphics editor such as Inkscape or Illustrator. GIMP and Inkscape are both free and open source software. If you don't have experience with a vector editor there's a bit of a learning curve, but after you have passed it a vector editor can be more rewarding, as you can more easily adjust, scale and rotate elements in the livery such as warning labels, stripes and cabin windows. Vector images also have the great advantage of having the possibility to later make a higher resolution livery in a snap.

=== Using layers ===
When editing the livery, have the template in one or more layer, adding the elements of your livery in other layers. Another good idea if you are using a raster editor is to have individual elements as separate layers to be able to move them around if necessary.

=== Saving the files ===
''Start'' the work by saving your livery while it is still empty. That way you will not get carried away, forgetting to save it just to be reminded in the harshest way, maybe having hours of work lost. The file should usually have a size of 1024*1024 pixels, but it does not have to bee a square and any rectangle with 2n pixels side, for example 256, 512 and 2048 pixels, will do. Larger image size will result in more detail being shown, but also a slower running FlightGear. In particular users with lower end computer might experience a delay when loading the model and texture of other multiplayer aircraft coming within a certain distance.

If you are working with raster files, remember to use a two or four times larger size, while working on the livery, in case you later on need a livery in a larger size. When you are done you can save a version in the right size. Save the file in a larger size also when creating a raster image paintkit from scratch.

While working on the livery save the file in different versions while you are adding new features, so you don't end up messing your ''only'' file up by mistake. Copy the file, with the right size, to the aircraft's <tt>..Models</tt> directory or <tt>..Models/Liveries</tt> directory, depending on how the original author organized the aircraft's folders, and name it default.png.

=== Viewing the livery in 3D ===
While you are working on the livery it is a good idea to load it into a 3D viewer, turning the model around and comparing it to your reference images at regular intervals.

To be able to check the livery on a model there are three ways, you can either
* use '''[[FGRun]]'s''' built in viewer at the aircraft page to look at the model, which is rather slow.
* use '''3DViewer''', a neat, small and fast viewer.
* use the 3D modeller '''[[Blender]]''', which has quite a steep learning curve.

My recommendation is 3DViewer, since it is small and fast.

=== Naming your livery ===
Lastly, when done give the livery a proper name. For hints on airliners etc. have a look at the [http://liveries.flightgear.org/contribute.php livery database's contribute page]. It is usually a good idea to have aircraft model and airline, possibly also years it was used in the file name.

== Editing the livery XML file ==
On aircraft that supports changing the livery shown to other MP pilots there are one XML file for each livery. The livery XML file usually is named as the livery file, except for the file type extension, and in its simplest form it can look something like this:
<syntaxhighlight>
<?xml version="1.0"?>

<propertylist>
<sim>
<model>
<livery>
<name>Full livery name</name> 
<texture>Livery.png</texture> 
</livery>
</model>
</sim>
</propertylist>
</syntaxhighlight>

The livery XML file sets up a few [[Property tree|properties]] used by the aircraft when changing the livery. In the above example the properties will be <tt>sim/model/livery/name=Full livery name</tt> and <tt>sim/model/livery/texture=Livery.png</tt>.

Many aircraft has additional properties that are set up in a similar way. There can for example be separate livery textures for the fuselage, wings and tail. As always it is a good idea to look at the existing XML files of the aircraft you want to make additional liveries for. Also the simplest way to make a new one is to copy and modify an existing file and save it under a new name.

== Sharing your work ==
Please consider sharing your work on the forum, and in the case it is a real livery and doesn't have parts of non-free images, also the livery database under the GPL license.

=== Showing your livery at the FlightGear forum ===
In order to show your liveries at the forum you have to be registered and have uploaded your images of the livery to some external image host like Picasa, Flickr, imageshed or something similar.

On the forum there are sometimes a topic for the development of an aircraft as well as a sparate topic for liveries to the same aircraft. Use the forums search function to find any already existing topics. If you cannot find one, make a new one in the [http://www.flightgear.org/forums/viewforum.php?f=13 liveries development] subforum with the name of the aircraft somewhere in the topic's title.

To add the image to your post use your image host's share function or if you do not find it use <tt>[img]</tt> tags like this <tt>[img]<URL to image>[/img]</tt>.

To share your livery you have to upload it to a file host and link to it with the <tt>[url]</tt> tags like this <tt>[url=<URL to file>]<Description of file>[/url]</tt>.

=== Uploading to the FlightGear Livery Database ===
You can upload your liveries to the official livery database using [http://liveries.flightgear.org/contribute.php a web form]. Please read the rules and tips carefully before sending in your livery.

== A pledge to aircraft developers and livery artists ==
Some one else would likely want to have a try at liveries for the aircraft you are working on. When you are developing an aircraft or are making a new livery for an aircraft without a painkit, please consider making a paintkit for that aircraft. Also consider that the aircraft will more likely get higher quality liveries and more liveries if your paintkit is of high quality.

== Related content ==
* [[Livery over MP]], describes how to equip an aircraft with a livery system.

== External links ==
* [http://liveries.flightgear.org/index.php FlightGear Livery Database]
* [http://www.unitedfreeworld.com/ Unitedfreeworld.com]

=== Web sites for reference images ===
A small selection. Many, many more are available these days.
* [http://www.google.se/imghp Google image search] The obvious
* [http://www.airliners.net/ Airliners.net] Well known
* [http://www.airplane-pictures.net/ Airplane-Pictures.net] Many ways to browse through the images
* [http://www.jetphotos.net/ JetPhotos.Net]
* [http://www.planepictures.net/ PlanePictures]

=== 3D Viewers ===
* [http://karelse.home.xs4all.nl/3DViewer/ 3DViewer] Small, neat and fast.

[[Category:Aircraft enhancement|Edit a livery]]
[[Category:Howto|Edit a livery]]

[[de:Howto: Edit a livery]]

Howto:Edit a livery

2015-08-04T19:19:08Z

F-ojac: Typo

[[File:PC-9M Slovenian Livery.png|150px|thumb|right|Slovenian livery for pjedvaj's second version of the [[Pilatus PC-9M]].]]
[[File:Finished Slovenian PC-9M livery (3DViewer screenshot).png|150px|thumb|right|3DViewer screen shot of a finished livery draped over the model.]]
[[File:Finished Slovenian PC-9M livery (in-game screenshot).png|150px|thumb|right|FlightGear 2.0.0 in-game screen shot with the finished livery.]]

By '''editing a livery''' you can give an aircraft a new paint job, a new ''livery''. In some other flight simulators and games a livery can be called a ''paint (scheme)'' or ''repaint''. A livery consists of one or more textures, wrapped around the 3D model representing the aircraft, together with an XML file needed for FlightGear to know which texture(s) to use.

This [[:Category:howto|howto]] is intended to be a help guiding potential livery artists as well as the more experienced ones needing a refresher.

== Where to find an aircraft livery ==
The installed aircraft can be found in <tt>$FG_ROOT/data/Aircraft</tt>, where <tt>$FG_ROOT</tt> is where FlightGear is installed. Each aircraft has a directory that contains a few text, 3D model and image files organized in several subdirectories. In that structure is one or more liveries and one or more text files, XML files, describing it's use. The liveries can usually be found in the <tt>../Models</tt>, <tt>../Liveries</tt>, <tt>../Models/Liveries</tt> or some other directory, depending on how the aircraft's author organized the files and directories.

== General work flow ==
There are a few ways to make a new livery. First of all have a look at the [[FlightGear livery database]], to make sure you don't duplicate someones else's work. You can also download templates for liveries, called ''paintkits'', there for a few aircraft, but usually paintkits are included with the aircraft.

When creating the livery, the work flow is basically in this order:
# Check the FlightGear Livery Database, to avoid duplicate work
# Find reference images,
# Get a paintkit, if available,
# Make the livery
# Share the livery

== Finding reference images ==
To do a good livery based on a real aircraft you simply have to have reference images to look at while making the livery. You will need images from both sides of the fuselage, images of the top and bottom, and a lot of close in images of details. Make sure you also have images from an angle. Having a three way drawing can be helpful, specially if you want to add rivet lines, or if there was no paintkit available.

Make sure you have a lot of good reference images of the aircraft livery you want to make. A list of websites containing such images can be found at the bottom of this article.

== Editing the texture ==
[[File:Vector vs Raster Graphics.png|150px|thumb|right|One pixel line width square and circle together with a gradient. Left side is a vector image, right side a raster image. Both are exported 20 times larger.]]
[[File:Livery layers in Inkscape (Slovenian PC-9M).png|150px|thumb|right|Inkscape layer dialogue. The four top top layers are the paintkit, while the rest of the layers are the livery.]]

To be on the safe side copy the aircraft folder to some other place and work on the livery in the copied directory.

=== Vector or raster ===
There are in general two ways to edit the livery: Using a raster image editor such as GIMP or Photoshop or using a vector graphics editor such as Inkscape or Illustrator. GIMP and Inkscape are both free and open source software. If you don't have experience with a vector editor there's a bit of a learning curve, but after you have passed it a vector editor can be more rewarding, as you can more easily adjust, scale and rotate elements in the livery such as warning labels, stripes and cabin windows. Vector images also have the great advantage of having the possibility to later make a higher resolution livery in a snap.

=== Using layers ===
When editing the livery, have the template in one or more layer, adding the elements of your livery in other layers. Another good idea if you are using a raster editor is to have individual elements as separate layers to be able to move them around if necessary.

=== Saving the files ===
''Start'' the work by saving your livery while it is still empty. That way you will not get carried away, forgetting to save it just to be reminded in the harshest way, maybe having hours of work lost. The file should usually have a size of 1024*1024 pixels, but it does not have to bee a square and any rectangle with 2n pixels side, for example 256, 512 and 2048 pixels, will do. Larger image size will result in more detail being shown, but also a slower running FlightGear. In particular users with lower end computer might experience a delay when loading the model and texture of other multiplayer aircraft coming within a certain distance.

If you are working with raster files, remember to use a two or four times larger size, while working on the livery, in case you later on need a livery in a larger size. When you are done you can save a version in the right size. Save the file in a larger size also when creating a raster image paintkit from scratch.

While working on the livery save the file in different versions while you are adding new features, so you don't end up messing your ''only'' file up by mistake. Copy the file, with the right size, to the aircraft's <tt>..Models</tt> directory or <tt>..Models/Liveries</tt> directory, depending on how the original author organized the aircraft's folders, and name it default.png.

=== Viewing the livery in 3D ===
While you are working on the livery it is a good idea to load it into a 3D viewer, turning the model around and comparing it to your reference images at regular intervals.

To be able to check the livery on a model there are three ways, you can either
* use '''[[FGRun]]'s''' built in viewer at the aircraft page to look at the model, which is rather slow.
* use '''3DViewer''', a neat, small and fast viewer.
* use the 3D modeller '''[[Blender]]''', which has quite a steep learning curve.

My recommendation is 3DViewer, since it is small and fast.

=== Naming your livery ===
Lastly, when done give the livery a proper name. For hints on airliners etc. have a look at the [http://liveries.flightgear.org/contribute.php livery database's contribute page]. It is usually a good idea to have aircraft model and airline, possibly also years it was used in the file name.

== Editing the livery XML file ==
On aircraft that supports changing the livery shown to other MP pilots there are one XML file for each livery. The livery XML file usually is named as the livery file, except for the file type extension, and in its simplest form it can look something like this:
<syntaxhighlight>
<?xml version="1.0"?>

<propertylist>
<sim>
<model>
<livery>
<name>Full livery name</name> 
<texture>Livery.png</texture> 
</livery>
</model>
</sim>
</propertylist>
</syntaxhighlight>

The livery XML file sets up a few [[Property tree|properties]] used by the aircraft when changing the livery. In the above example the properties will be <tt>sim/model/livery/name=Full livery name</tt> and <tt>sim/model/livery/texture=Livery.png</tt>.

Many aircraft has additional properties that are set up in a similar way. There can for example be separate livery textures for the fuselage, wings and tail. As always it is a good idea to look at the existing XML files of the aircraft you want to make additional liveries for. Also the simplest way to make a new one is to copy and modify an existing file and save it under a new name.

== Sharing your work ==
Please consider sharing your work on the forum, and in the case it is a real livery and doesn't have parts of non-free images, also the livery database under the GPL license.

=== Showing your livery at the FlightGear forum ===
In order to show your liveries at the forum you have to be registered and have uploaded your images of the livery to some external image host like Picasa, Flickr, imageshed or something similar.

On the forum there are sometimes a topic for the development of an aircraft as well as a sparate topic for liveries to the same aircraft. Use the forums search function to find any already existing topics. If you cannot find one, make a new one in the [http://www.flightgear.org/forums/viewforum.php?f=13 liveries development] subforum with the name of the aircraft somewhere in the topic's title.

To add the image to your post use your image host's share function or if you do not find it use <tt>[img]</tt> tags like this <tt>[img]<URL to image>[/img]</tt>.

To share your livery you have to upload it to a file host and link to it with the <tt>[url]</tt> tags like this <tt>[url=<URL to file>]<Description of file>[/url]</tt>.

=== Uploading to the FlightGear Livery Database ===
You can upload your liveries to the official livery database using [http://liveries.flightgear.org/contribute.php a web form]. Please read the rules and tips carefully before sending in your livery.

== A pledge to aircraft developers and livery artists ==
Some one else would likely want to have a try at liveries for the aircraft you are working on. When you are developing an aircraft or are making a new livery for an aircraft without a painkit, please consider making a paintkit for that aircraft. Also consider that the aircraft will more likely get higher quality liveries and more liveries if your paintkit is of high quality.

== Related content ==
* [[Livery over MP]], describes how to equip an aircraft with a livery system.

== External links ==
* [http://liveries.flightgear.org/index.php FlightGear Livery Database]
* [http://www.unitedfreeworld.com/ Unitedfreeworld.com]

=== Web sites for reference images ===
A small selection. Many, many more are available these days.
* [http://www.google.se/imghp Google image search] The obvious
* [http://www.airliners.net/ Airliners.net] Well known
* [http://www.airplane-pictures.net/ Airplane-Pictures.net] Many ways to browse through the images
* [http://www.jetphotos.net/ JetPhotos.Net]
* [http://www.planepictures.net/ PlanePictures]

=== 3D Viewers ===
* [http://karelse.home.xs4all.nl/3DViewer/ 3DViewer] Small, neat and fast.

[[Category:Aircraft enhancement|Edit a livery]]
[[Category:Howto|Edit a livery]]

[[de:Howto: Edit a livery]]

Release plan

2015-08-01T07:42:56Z

F-ojac: /* Detailed time schedule and checklist */

{{GitStatus}}

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. In particular, improvements should be based on [[Release plan/Lessons learned]] from past releases. Please discuss this concept at the mailing-list.

== General release concept ==
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

{{cquote|As a clarification: We do not enter a code freeze but a feature freeze. Code changes are welcome after December 17th as long as it is guaranteed (not just "unlikely") that they do not introduce any side effects and become a release blocker. It is the sole responsibility of the commiter to decide if that is the case or not. Every new feature that didn't make it into the respository by the deadline may probably easily wait for another four weeks to get commited. Remember: most aircraft are not affected by the feature freeze and aircraft developers quickly adopt and use new features as they become available<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html|title=<nowiki>[Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki>|author=Torsten Dreyer|date=16 November 2012}}</ref>|Torsten Dreyer}}

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear, FGRun and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

== Version numbers ==
FlightGear version numbers consist of three digits, seperated by dots:
* '''Major''' (2.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).
* '''Minor''' (2.4.1): has two applications:
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release was 2.8.0, the current development stream is 2.9.0.
* '''Revision''' (2.4.1): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.

When referring to a major release in general, only the first two digits should be used, i.e. 2.6 refers to 2.6.0, 2.6.1 etc.

== Detailed time schedule and checklist ==
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state, add a call for screenshots
##Create a "release preperations" topic at the forum and make it a "Global Announcement", add a call for screenshots
##Ask for translator for a review of the translations of the menu, help and startup entries in case there have been some mods on those files
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next, fgrun/next and fgdata/master to an even number (2.9.0 -> 3.0.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear+fgrun) and master(fgdata)
##Tag (annotated) flightgear, simgear, fgrun and fgdata with <tt>version/3.0.0</tt>
##:<code>git tag -a version/3.0.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.0.0</code>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgrun/fgdata):
##:<code>git pull</code>
##:<code>git branch release/3.0.0</code>
##On the next/master branches, bump up the version-number of simgear, flightgear, fgrun and fgdata to an odd number (3.0.0 -> 3.1.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear, fgrun and fgdata with "version/2.9.0"
##:<code>git tag -a version/2.9.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream
##:for flightgear, simgear, fgrun and fgdata: <code>git push origin release/3.0.0</code>
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.1.0</code>
##Declare dev-streams "open" or "green"
##: Ask a [http://wiki.flightgear.org/index.php?title=Special:ListUsers&group=sysop wiki admin] to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James or Clément for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
##:in fgmeta:
##:<code>git checkout release/3.0.0</code>
##:<code>git submodule foreach git checkout release/3.0.0</code>
##:<code>git submodule foreach git pull -r</code>
##:<code>git add .</code>
##:<code>git commit -m "Bump revision"</code>
##:<code>git push origin release/3.0.0</code>
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/3.0.0 branches of simgear, flightgear, fgrun and fgdata and push the tags.
##:for flighgear, simgear, fgrun and fgdata: <code>git tag version/3.0.0-final</code>
##:for flighgear, simgear, fgrun and fgdata: <code>git push origin version/3.0.0-final</code>
##Merge the branch release/3.0.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear, fgrun and simgear:
##:<code>git checkout -b master origin/master</code> or <code>git checkout master</code> if you already have the local branch
##:<code>git merge version/3.0.0-final</code>
##:<code>git push origin master</code>
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.

== To bump up the version number ==
* [https://gitorious.org/fg/fgdata FGData]
** edit the ''version'' file
* [https://gitorious.org/fg/simgear SimGear]
** edit the ''version'' file
* [https://gitorious.org/fg/flightgear FlightGear]
** edit the ''version'' file
* [https://gitorious.org/fg/fgrun FGRun]
** edit the ''version'' file

== Definition of repository states ==
{| class="wikitable"
!
! State
! Description
|-
! [[File:Traffic light green.png|20px]]
! Open/Green
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five months after the release branches were created.
|-
! [[File:Traffic light yellow.png|20px]]
! Frozen/Yellow
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.
|-
! [[File:Traffic light red.png|20px]]
! Closed/Red
| Nothing shall be pushed to the development streams (simgear, flightgear, fgrun and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.
|}

== Bug fix committing policy ==
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

== Bug tracking ==
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.12.0 the list of fixed bugs].

=== Tasks and owners ===

The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.

{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
! Status for [[Changelog 2.12|2.12]]
|-
! rowspan="7" |
| Announce the state-change of the dev-streams, '''cross-post to JSBSim list''' (see lessons learned!)
| TorstenD
|
|-
| Create/maintain the git branches
| TorstenD
|
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Sync the language files so they can be translated
| ThorstenB, James
|
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|
|-
| MacOS
| Tat/James
|
|-
| Distribute files to download servers
| Curt
|
|-
! rowspan="3" | Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
| Generate aircraft page
| Curt, Gijs
|-
|-
| Tag the [http://wiki.flightgear.org/index.php?title=Talk:Next_newsletter&action=edit&section=45 newsletter template] according to the released version
<nowiki>[[Category:Changes after 2.12]]</nowiki>
| Hooray, Gijs, Stuart (other wiki admins)
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Next Changelog]]
| All developers/contributors
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

== Open items, questions ==
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it."<ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html |title=<nowiki>Re: [Flightgear-devel] Release candidates</nowiki> |author=Torsten Dreyer |date=29 January 2013}}</ref>
* <del>Automate the creation of Windows and Mac installers</del> {{Done}} <ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40650.html</ref> (see [[FlightGear Build Server]])
* Automate the creation of FGDATA distribution
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests <ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40201.html |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
{{Cite web |url=http://sourceforge.net/p/flightgear/mailman/message/31762085/
|title=<nowiki>Release preparations - feature freeze starts today</nowiki> |author=Anders Gidenstam |date=2013-12-17 19:46:48}}
</ref>

== Lessons learned ==
See [[Release plan/Lessons learned]] for a list of things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.

{{Appendix}}

[[Category:Core developer documentation]]
[[Category:FlightGear]]

TerraGear Installation for Windows

2015-07-27T12:14:16Z

F-ojac: Typo - will fix URLs later.

TerraGear build for Windows requires several libraries, some which must be downloaded separately.

=== TerraGear Windows Build===
Download the [http://build.flightgear.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip latest Terragear Windows build archive] from the [[FlightGear Build Server]].

Select a logical location on your system for TerraGear. It can be anywhere but for clarity the instruction below are for C:\Program Files .

Extract the TerraGear Archive to a temporary location on your system. In the examples below, the archive was extracted to C:\Archive

* Move C:\Archive\install\msvc100\TerraGear\ to C:\Program Files
* Move C:\Archive\CGAL\auxiliary\gmp\lib\libgmp-10.dll to C:\Program Files\TerraGear\bin\
* Move C:\Archive\CGAL\auxiliary\gmp\lib\libmpfr-4.dll to C:\Program Files\TerraGear\bin\
* Move C:\Archive\gdal\bin\gdal110dev.dll to C:\Program Files\TerraGear\bin\
* Move C:\Archive\3rdParty\msvcp71.dll to your TerraGear GUI root directory (if you use [[TerraGear_GUI]])
* Move C:\Archive\3rdParty\msvcr71.dll to your TerraGear GUI root directory (if you use [[TerraGear_GUI]])

=== Required Libraries ===
Download the CGAL library from [http://build.flightgear.org:8080/job/CGAL-Win-CMake/ws/install/msvc100/CGAL/bin/CGAL-vc100-mt-4.1.dll the Build Server] and save the dll into C:\Program Files\TerraGear\bin\

[http://download.osgeo.org/proj/proj446_win32_bin.zip Download the Cartographic Projections Library] from http://trac.osgeo.org/proj/
You only need one file, proj.dll, from this archive. Save proj.dll into to C:\Program Files\TerraGear\bin\

=== Results ===
If you chose C:\Program Files for your location when you are done you should have following directory structure.
* C:\Program Files\TerraGear\bin
:* (contains 15 .exe files and 5 .dll files)
* C:\Program Files\TerraGear\share\TerraGear
:* (contains 15 .txt files)

If you use [[TerraGear_GUI|TerraGear GUI]] its "TerraGear root" will be C:\Program Files\TerraGear

[[Category:TerraGear]]

Fr/Utiliser TerraGear

2015-07-27T11:21:46Z

F-ojac: Linking to WED and not Taxidraw

[[File:Terragearprocesschart.png|thumb|Organigramme de TerraGear]]
Le projet logiciel [[TerraGear]] participe au projet [[FlightGear]] en créant les fichiers utilisés par celui-ci pour représenter le relief et la texture de la Terre, ce qui comprend les aéroports, villes, champs, forêts, rivières, routes, etc. Le logiciel TerraGear lit des fichiers de données contenant l'élévation du sol, le positionnement et l'agencement des aéroports, les données géographiques d'occupation du sol, entre autres et produit les fichiers de scènes utilisés par Flightgear pour représenter la surface de la planète.

Par simplicité et commodité, la plupart des utilisateurs de FlightGear téléchargent simplement les fichiers plug-and-play des scènes à partir du serveur de scènes de FlightGear, ou utilisent [[TerraSync]] pour télécharger automatiquement les scènes à la volée. Mais il peut y avoir des cas où vous pourriez vouloir utiliser TerraGear pour générer vos propres fichiers terrain, plutôt que de télécharger les scènes standard de FlightGear.

Par exemple, si vous utilisez [[WED]] pour modifier/améliorer un taxiway/une aire de trafic d'un [[:Category:Airports|aéroport]], vous pourriez avoir envie de visualiser à quoi ressemblerait cet aéroport modifié dans les scènes avant de décider que les résultats vous conviennent. Peut-être que les scènes officielles sont trop détaillées pour votre machine trop lente; dans ce cas, vous pourriez vouloir générer un terrain en utilisant un modèle numérique d'élévation (DEM) de plus faible résolution, afin diminuer le nombre de polygones et ainsi d'améliorer le taux d'images. Ou peut-être disposez-vous d'une machine très rapide, et que vous souhaiteriez construire votre propre terrain avec des données vectorielles haute-résolution (vmap1, Tiger, osm) afin d'obtenir des routes/rivières plus réalistes. Pour toutes ces raisons, apprendre l'utilisation de TerraGear est une bonne idée.

== Obtenir TerraGear ==
Vous pouvez soit compiler TerraGear vous-même, ou bien télécharger un binaire pré-compilé, cette dernière démarche étant plus aisée et donc recommandée pour les débutants.

* '''Option 1 - Télécharger TerraGear pré-compilé (recommandé aux débutants ) sur Windows'''
*# Téléchargez la dernière version de TerraGear sur le [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip| Serveur de compilation de FlightGear].
*# Créez ou choisissez un répertoire pour contenir les outils TerraGear.
*# Dé-zippez le paquetage, et déplacez les fichiers de <tt>archive/install/msvc100/TerraGear/bin</tt> dans un sous-répertoire nommé <tt>Terragear/</tt> dans le répertoire de base.
* '''Option 2 - Compiler TerraGear à partir du code source, comme expliqué dans [[Building TerraGear|cet article]].

''Note :'' Vous pourriez avoir besoin du fichier default_priorities.txt qui peut être obtenu à partir du [https://gitorious.org/fg/terragear-cs/blobs/raw/master/src/BuildTiles/Clipper/default_priorities.txt dépôt Git] ou à partir de l'archive téléchargée à partir du serveur de compilation (dans le sous-répertoire <tt>archive/install/msvc100/TerraGear/share</tt>). Voir [http://forum.flightgear.org/viewtopic.php?f=5&p=77950|ce lien du forum] pour les détails.

=== Interface graphique ===
L'interface graphique appelée [[TerraGear GUI]] est disponible pour ceux voudraient utiliser Terragear sans avoir à connaître/utiliser les options de ligne de commande.

== Utilisation de TerraGear ==
Tout d'abord, choisissez les limites de la zone de scène que vous voulez construire, en termes de latitude et de longitude. Plus la zone à générer sera restreinte, plus la quantité de données et le temps CPU nécessaire seront limités. Par exemple, si vous voulez juste générer une nouvelle disposition d'aéroport à la position 12°3 Ouest et 34°4 Nord, la génération des scènes entre 34°N 12°O et 35°N 13°O sera suffisante.

Notez la boîte de délimitation (longitudes et latitudes minimum et maximum) pour la scène que vous voulez générer. Rappelez-vous que Ouest et Sud sont négatifs - c'est-à-dire que 4° Ouest 10° Sud doit être -4, -10. Essayez de ne pas vous mélanger les pinceaux, sinon la scène ou l'aéroport que vous créez se retrouvera de l'autre côté de la planète !

Vous aurez affaire avec différents types de données utilisant des formats variés. Créez un nouveau répertoire pour votre travail de scène, puis créez à l'intérieur créez les sous-répertoires suivants :

* '''data/''' - pour les données brutes et pré-calculées (par exemple, les fichiers d'élévation)
* '''output/''' - pour les fichiers de scènes que vous créerez
* '''work/''' - pour les données qui ont été calculez (par exemple par shape-decode) et qui sont prêtes à être intégrées dans la scène

=== Obtenir et traiter les données ===
Terragear utilise trois sortes d'informations différentes pour générer une scène :

# L'élévation du terrain (fournie par SRTM)
# L'emplacement et la disposition des aéroports (fournis par apt.dat ou un fichier .dat personnalisé)
# Si une lat/lon donnée correspond à la mer, la terre, une ville, une forêt, un village, une route, un chemin de fer (fourni par VMAP0, [[CORINE]], etc. ou par des fichiers personnalisés de formes)

Cet article décrit comment obtenir et traiter chacun de ces types de données dans l'ordre, et les fournir ensemble, pour que FlightGear les utilise. L'ordre de ces étapes est important. Par exemple, l'étape des données d'un aéroport a besoin des données d'élévation pour déterminer l'élévation des aéroports. Ainsi, vous commencerez par préparer les données d'élévation.

'''Remarque : pour que votre travail puisse être intégré dans les scènes officielles de FlightGear, toutes les données doivent provenir de sources compatibles avec la licence [[GNU GPL]] !'''

==== Données d'élévation ====
Les meilleures données d'élévation actuellement disponibles proviennent du projet Shuttle Radar Topography Mission (SRTM). Il y a deux types de données SRTM :
* Données de haute précision (1-arc seconde), ou SRTM-1, pour les USA
* Données de précision moindre (3-arc second), ou SRTM-3, pour le reste du monde
A partir de maintenant, nous supposerons que vous utilisez les données SRTM-3. Sauf mention contraire, le processus est identique pour SRTM-1.

Vous pouvez télécharger les données appropriées à partir du site http://dds.cr.usgs.gov/srtm/version2_1/. Vous devrez récupérer tous les fichiers .hgt.zip couvrant la région qui vous intéresse. Selon la taille de votre scène, cela peut représenter un grand nombre de fichiers. Téléchargez les vers l'emplacement <tt>data/SRTM-1/</tt>(ou SRTM-3/SRTM-30 en fonction du type de données que vous téléchargez) dans votre répertoire de base. (Genapts recherchera ses données parmi un ensemble de noms de répertoires prédéfinis dans son répertoire de travail. SRTM-30 est l'un d'eux, c'est le moins déroutant dans cette liste. Notez que, à compter du 31 juillet 2010, l'outil genapts prend également en compte l'existence de répertoires SRTM-1/SRTM-3. Si vous utilisez une version plus ancienne, pensez à fournir les répertoires en utilisant --dem-path)

Maintenant que nous avons les données, nous devons les convertir pour qu'elles puissent servir à TerraGear. Tout d'abord, dézippez chacun des fichiers .hgt. Ensuite, ouvrez la ligne de commande (Sous Windows: <tt>Démarrer > Exécuter > cmd.exe</tt>) et placez-vous dans le répertoire de base (<tt>cd .../.../TerraGear</tt>).
* '''NOTE :''' si vous voulez créer un fichier batch, remplacez <tt>%f</tt> avec <tt>%%f</tt>, voir à ce sujet : [http://technet.microsoft.com/en-us/library/bb490909.aspx]
* '''NOTE :''' pour les données SRTM-1, remplacez le <tt>3</tt> par un <tt>1</tt> dans le premier argument fourni à hgtchop

Pour Windows :
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 %f .\work\SRTM-3
ou
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 .\data\SRTM-3\%f .\work\SRTM-3

Pour Linux :
for i in $PWD/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 $i $PWD/work/SRTM-3; done

Maintenant, vous allez obtenir une quantité importante de fichiers .arr.gz dans votre répertoire work/SRTM-3/. Il nous faut les convertir au format .fit.gz. Utilisez à nouveau la ligne de commande avec
* '''NOTE:''' l'espace et le point à la fin sont importants !

Pour Windows :
.\Terragear\terrafit.exe work\SRTM-3

Pour Linux :
./Terragear/terrafit work/SRTM-3

==== Données d'aéroports ====
Maintenant que nous avons les données d'élévation, nous pouvons générer nos aéroports. Tout d'abord, créons un répertoire <tt>data/airports/</tt> et copions-y le fichier apt.dat. Ceci peut être effectué soit directement à partir de votre paquetage de FlightGear (bien que vous devrez le dé-zipper), soit il peut correspondre au fichier que vous auriez modifié avec [[TaxiDraw]].

La commande pour créer les aéroports est "genapts". Lancez-la sans arguments, afin de visualiser les différentes options de ligne de commande.

Si elle est simplement lancée avec un fichier apt.dat spécifié et le répertoire de travail, elle génèrera les agencements d'aéroports pour chaque aéroport contenu dans le fichier, ce qui peut être long.

Si vous créez juste un seul aéroport, et que vous connaissez son identifiant OACI (par exemple [[KSFO]], EGPH, EG32), utilisez cet identifiant comme suit à partir du répertoire racine de vos scènes (c'est à dire à partir du répertoire parent de vos répertoires data, work et output). Si vous utilisez un fichier apt.dat contenant un seul aéroport, vous pouvez omettre le paramètre "--airport".

genapts --input=data/airports/apt.dat --work=./work --airport=<IDENTIFIANT_OACI_AEROPORT>

Si vous générez des scènes plus grandes, alors vous pouvez spécifier les longitudes et latitudes minimum et maximum.

Genapts va créer deux sous-répertoires dans votre répertoire work:
* AirportArea/
* AirportObj/

Ils contiennent les définitions des agencement de l'aéroport, et de certains objets présents (par exemple les manches à air).

==== Données d'utilisation du sol ====
Les dernières données que nous avons besoin de générer sont celles correspondant au type d'utilisation du sol. En général, elles proviennent du lot de données VMAP0 en tant que fichiers de formes en provenance du serveur de carte de la base de données des scènes, mais d'autres sources peuvent aussi être utilisées.

Les données d'utilisation du sol peuvent être séparées en différents types :

* '''Landmass :''' sépare la terre de la mer. Ces données sont utilisées comme masque pour toutes les autres données. Les plus couramment utilisées sont le Landmass VMAP0, mais GSHHS peut également être utilisé.
* '''Land use data :''' définit si une portion de terrain correspond à une forêt, une zone urbaine, du sable, de la lave, des glaciers, etc. Ce sont généralement données VMAP0 définies en tant que polygones.
* '''Line data :''' comprend les lignes de chemins de fer, les rivières, les routes. Typiquement VMAP0, mais aussi OpenStreetMap pour les routes.
* '''Point data :''' est actuellement uniquement utilisé pour définir les villes.

De loin, le moyen le plus facile pour obtenir ces données est de télécharger à partir du magnifique [http://mapserver.flightgear.org MapServer] les fichiers formes pour une zone de scène donnée. Cliquez sur le lien "Download Shapefiles" (ou allez directement à : http://mapserver.flightgear.org/download.psp). Entrez dans la boîte de délimitation de la scène que vous désirez générer, sélectionnez le type de données de fichier-formes que vous voulez, et cliquez sur '''download'''. Pour les scènes de base, prenez tout ce qui est listé sous VMap0 (c'est-à-dire utilisant le préfixe v0_).

Téléchargez chaque fichier-forme dans un répertoire séparé (!) <tt>data/shapefiles/...</tt>. Ainsi, pour v0_landmass, vous obtiendriez <tt>data/shapefiles/v0_landmass/v0_landmass.shp</tt>, etc.

Vous pouvez charger ces fichiers-formes dans un éditeur SIG tel que [[QGIS]] ou GRASS pour les visualiser et les éditer. C'est une bonne idée pour vérifier que vous avez bien les bons fichiers ! Plus tard, vous pourrez expérimenter en remplaçant divers fichiers-formes avec d'autres versions (GSHHS pour la côte, OSM pour les routes, etc.).

L'étape suivante décode les fichiers-formes vers le format TerraGear en utilisant la commande '''ogr-decode''' .

Il y a trois arguments de ligne de commande importants pour ogr-decode :
* le répertoire de destination pour les données décodées,
* la localisation du répertoire de fichiers-formes,
* le type de matériau.

Chaque fichier-forme correspond avec un des types de matériau défini dans les fichiers materials.xml. La correspondance est assez évidente. Par exemple, v0_mixedcroppasturecover correspond à MixedCropPastureCover. Notez que les types de matériau sont sensibles à la casse, donc il est bon de se référer au fichier <tt>[[$FG ROOT]]/materials.xml</tt> pour vérifier. L'exception est v0_landmass, qui DOIT correspondre au type Default.

En complément, il existe de nombreux arguments optionnels pour indiquer la largeur des données linéaires (pour les routes, les rivières, les voies de chemin de fer), quelle largeur utiliser pour les données de type point (pour les villes) et quelle est la plus grande longueur acceptable pour une ligne droite.

Par exemple, pour décoder le fichier-forme v0_landmass, vous entrez la commande suivante :

ogr-decode --max-segment 500 --area-type Default work/Landmass data/shapefiles/v0_landmass

Pour créer des rivières de 10 mètres de large :

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

Pour générer des villes d'environ 1 kilomètre de diagonale :

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Lancez cette commande pour chaque fichier-forme du lot de données.

== Générer les scènes ==
Vous avez maintenant un répertoire de travail, avec des sous-répertoires comme :
{|
|
: AirportArea
: AirportObj
: Bog
: DryCropPastureCover
: EvergreenBroadCover
: GrassCover
: IrrCropPastureCover
: Lake
: Landmass
: Marsh
: MixedCropPastureCover
| valign="top" |
: MixedForestCover
: Railroad
: Road
: Sand
: ScrubCover
: Shared
: SRTM-3
: Stream
: Town
: Urban
|}

Nous pouvons maintenant générer les scènes en utilisant la commande fgfs-construct. Lancez la commande avec <code>--help</code> pour obtenir les informations d'utilisation.

Nous devons définir :
* Les répertoires de travail (--work-dir) et de sortie (--output-dir) .
** '''Notez''', au sujet du répertoire de sortie : il doit pointer vers le répertoire <tt>Terrain/</tt>, sinon, les versions récentes FlightGear seront incapables de charger le terrain.
* Le centre de la scène que nous voulons générer (--lat, --lon).
* Le rayon (--xdist, --ydist) à partir duquel on génère.
* Tous les répertoires de travail à inclure dans la scène.

Par exemple :
{{Pre2|<nowiki>fgfs-construct --work-dir=./work --output-dir=./output/Terrain --lon=55 --lat=60 --xdist=3 --ydist=3 AirportArea SRTM-3 AirportObj Stream Bog IrrCropPastureCover Town Lake Urban Landmass Railroad DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover MixedForestCover</nowiki> }}

Lorsque cette commande se termine, le répertoire de sortie contiendra un sous-répertoire scenery. Pointez vers lui en paramétrant [[$FG_SCENERY]] ou en utilisant l'option de ligne de commande --fg-scenery à fgfs, et testez votre nouvelle scène !

== Un soucis ? ==
Vous trouverez ci-dessous une liste de problèmes courants et leur solutions. Dans le doute, copiez/collez votre erreur dans Google. La plupart des problèmes (en particulier lors de la compilation de TerraGear) ont déjà été évoqués :

* Crash de genapts. Quelquefois, genapts plante avec certains aéroports. Dans ce cas, essayez de le relancer avec l'argument --start-id pour démarrer à l'aéroport sur lequel il a planté, et l'argument --nudge pour essayer de remettre les calculs dans la bonne voie.
* fgfs-construct tué. Le processus fgfs-construct peut se suicider s'il consomme trop de ressources système. L'augmentation des valeurs pour setrlimit dans src/BuildTiles/Main/main.cxx est la meilleure solution.
* Les aéroports apparaissent au fond de trous, ou il y a des espaces entre les aéroports et la scène. Ceci arrive lorsque genapts est incapable de trouver la donnée d'élévation correcte, ou alors la donnée d'élévation a changé entre le lancement de genapts et celui de shape-decode. Essayez de générer un seul aéroport dans votre zone de scène en utilisant genapts, et visualisez la sortie. En particulier, soyez sûr que le répertoire work/SRTM-3 existe.
* Seuls les aéroports apparaissent dans la scène. Il existe trois explications typiques :
** vous n'avez pas téléchargé les fichiers-formes corrects de la zone;
** vous n'avez pas lancé shape-decode sur le fichier-forme v0_landmass comme Default
** vous n'avez pas inclus les répertoires corrects dans fgfs-construct.
* La scène générée contient des données effacées des fichiers-formes. Si vous éditez des fichiers-formes, vous devez effacer le sous-répertoire work approprié avant de lancer shape-decode. Sinon, vos changements s'ajouteront à ceux qui existent déjà.
* La scène entière est plate et au niveau de la mer. C'est généralement dû au fait que vous n'avez pas inclus les données d'élévation dans votre commande fgfs-construct. Assurez-vous qu'il existe un répertoire STRM-3 précisé dans la ligne de commande.
* Tout terrain copie le matériel d'un fichier-forme. Vous avez probablement oublié de mettre chacun des fichiers-formes téléchargés dans un répertoire séparé à l'intérieur du répertoire Data/shapefiles.

{{Terra}}

[[Category:Scenery enhancement]]
[[fr:Utiliser TerraGear]]

Howto:Set up a FGCom server

2015-07-27T11:08:54Z

F-ojac: Formel URL didn't work anymore.

This page is for installing a '''FGCom Server'''. If you want to have voice communications within [[FlightGear]], you are probably wanting to install the [[FGCom|client]].

This document is to assist in setting up hot spares as potential failover for the new server and for replacing that server if/when that becomes necessary. It is not expected that this will be a widely used document, nonetheless, the information contained is no less valuable for that.

== Install Asterisk ==
You need an instance of Asterisk on the server, you can either install Asterisk via a package manager (if you're using CentOS/RHEL) or via the source code if you're on a different distro. For easiness (and because I can) I chose to do it via the package manager.
We used CentOS (this works for RedHat too) and the instructions for installing it on CentOS/RHEL are as follows:

=== CentOS/RHEL ===

==== Setting up the Package Manager ====

In the ''''/etc/yum.repos.d'''' folder create the following files:

centos-asterisk.repo:
[asterisk-tested]
name=CentOS-$releasever - Asterisk - Tested
baseurl=http://packages.asterisk.org/centos/$releasever/tested/$basearch/
enabled=0
gpgcheck=0
#gpgkey=http://packages.asterisk.org/RPM-GPG-KEY-Digium

[asterisk-current]
name=CentOS-$releasever - Asterisk - Current
baseurl=http://packages.asterisk.org/centos/$releasever/current/$basearch/
enabled=1
gpgcheck=0
#gpgkey=http://packages.asterisk.org/RPM-GPG-KEY-Digium

centos-digium.repo:
[digium-tested]
name=CentOS-$releasever - Digium - Tested
baseurl=http://packages.digium.com/centos/$releasever/tested/$basearch/
enabled=0
gpgcheck=0
#gpgkey=http://packages.digium.com/RPM-GPG-KEY-Digium

[digium-current]
name=CentOS-$releasever - Digium - Current
baseurl=http://packages.digium.com/centos/$releasever/current/$basearch/
enabled=1
gpgcheck=0
#gpgkey=http://packages.digium.com/RPM-GPG-KEY-Digium

==== Installing the Packages ====

[root@localhost~]# yum install asterisk16 asterisk16-configs asterisk16-voicemail dahdi-linux dahdi-tools libpri

You will then see something like this:
=========================================================================================
Package Arch Version Size
=========================================================================================
Installing:
asterisk16 i386 1.6.0.15-1_centos5 4.0 k
Installing for dependencies:
asterisk-sounds-core-en-gsm noarch 1.4.15-1_centos5 1.7 M
asterisk16-core i386 1.6.0.15-1_centos5 11 M
asterisk16-dahdi i386 1.6.0.15-1_centos5 837 k
asterisk16-doc i386 1.6.0.15-1_centos5 10 k
asterisk16-voicemail i386 1.6.0.15-1_centos5 264 k
dahdi-firmware noarch 2.0.1-1_centos5 1.9 k
dahdi-firmware-oct6114-064 noarch 1.05.01-1_centos5 165 k
dahdi-firmware-oct6114-128 noarch 1.05.01-1_centos5 166 k
dahdi-firmware-tc400m noarch MR6.12-1_centos5 1.7 M
dahdi-linux i386 2.2.0.2-1_centos5 3.3 k
kernel i686 2.6.18-164.el5 16 M
kmod-dahdi-linux i686 2.2.0.2-1_centos5.2.6.18_164.el5 3.4 M
kmod-dahdi-linux-fwload-vpmadt032 i686 2.2.0.2-1_centos5.2.6.18_164.el5 124 k
libpri i386 1.4.10.1-1_centos5 103 k
libss7 i386 1.0.2-1_centos5 63 k
yum-kmod noarch 1.1.16-13.el5.centos 17 k

Transaction Summary
========================================================================================
Install 17 Package(s)
Update 0 Package(s)
Remove 0 Package(s)

Total download size: 35 M
Is this ok [y/N]:

Press {{Key press|Y}} and then {{Key press|Enter}}

Downloading Packages:
(1/17): dahdi-firmware-2.0.1-1_centos5.noarch.rpm | 1.9 kB 00:00
(2/17): dahdi-linux-2.2.0.2-1_centos5.i386.rpm | 3.3 kB 00:00
(3/17): asterisk16-1.6.0.15-1_centos5.i386.rpm | 4.0 kB 00:00
(4/17): asterisk16-doc-1.6.0.15-1_centos5.i386.rpm | 10 kB 00:00
(5/17): yum-kmod-1.1.16-13.el5.centos.noarch.rpm | 17 kB 00:00
(6/17): libss7-1.0.2-1_centos5.i386.rpm | 63 kB 00:00
(7/17): libpri-1.4.10.1-1_centos5.i386.rpm | 103 kB 00:00
(8/17): kmod-dahdi-linux-fwload-vpmadt032-2.2.0.2-1_centos5.2.6.18_164.el5.i686.rpm | 124 kB 00:00
(9/17): dahdi-firmware-oct6114-064-1.05.01-1_centos5.noarch.rpm | 165 kB 00:00
(10/17): dahdi-firmware-oct6114-128-1.05.01-1_centos5.noarch.rpm | 166 kB 00:00
(11/17): asterisk16-voicemail-1.6.0.15-1_centos5.i386.rpm | 264 kB 00:01
(12/17): asterisk16-dahdi-1.6.0.15-1_centos5.i386.rpm | 837 kB 00:04
(13/17): dahdi-firmware-tc400m-MR6.12-1_centos5.noarch.rpm | 1.7 MB 00:08
(14/17): asterisk-sounds-core-en-gsm-1.4.15-1_centos5.noarch.rpm | 1.7 MB 00:08
(15/17): kmod-dahdi-linux-2.2.0.2-1_centos5.2.6.18_164.el5.i686.rpm | 3.4 MB 00:17
(16/17): asterisk16-core-1.6.0.15-1_centos5.i386.rpm | 11 MB 00:57
(17/17): kernel-2.6.18-164.el5.i686.rpm | 16 MB 00:23
-------------------------------------------------------------------------------------
Total 283 kB/s | 35 MB
02:06
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID e8562897
Importing GPG key 0xE8562897 "CentOS-5 Key (CentOS 5 Official Signing Key) " from
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
Is this ok [y/N]:

Press {{Key press|Y}} and then {{Key press|Enter}} again

Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : kernel [ 1/17]
Installing : asterisk16-core [ 2/17]
Installing : kmod-dahdi-linux [ 3/17]
Installing : asterisk16-doc [ 4/17]
Installing : kmod-dahdi-linux-fwload-vpmadt032 [ 5/17]
Installing : asterisk-sounds-core-en-gsm [ 6/17]
Installing : dahdi-firmware-oct6114-064 [ 7/17]
Installing : yum-kmod [ 8/17]
Installing : dahdi-firmware-tc400m [ 9/17]
Installing : dahdi-firmware-oct6114-128 [10/17]
Installing : asterisk16-voicemail [11/17]
Installing : libss7 [12/17]
Installing : libpri [13/17]
Installing : dahdi-firmware [14/17]
Installing : dahdi-linux [15/17]
Installing : asterisk16-dahdi [16/17]
Installing : asterisk16 [17/17]

Installed: asterisk16.i386 0:1.6.0.15-1_centos5
Dependency Installed: asterisk16-core.i386 0:1.6.0.15-1_centos5 ...
Complete!
[root@localhost yum.repos.d]#

When you are met with the screen above with the words ''''Complete!'''' on it then you are ready to move on to Part 2: Configuration Files

=== Debian/Ubuntu ===
This about covers it:

apt-get install asterisk

=== Install from Source ===
==== Downloading the Source ====
Downloading necessary packages: LIBPRI, DAHDI, AND Asterisk

cd /usr/src
wget http://www.asterisk.org/downloads/asterisk/releases/asterisk-1.6.2-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.11.3.tar.gz
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.3.0.1+2.3.0.tar.gz

==== Installing Libpri ====

tar -xvzf libpri-1.4.11.3.tar.gz
cd libpri-1.4.11.3
make
make install

==== Installing DAHDI ====

cd /usr/src
tar -xvzf dahdi-linux-complete-2.3.0.1+2.3.0.tar.gz
cd dahdi-linux-complete-2.3.0.1+2.3.0
make
make install
make config

==== Installing Asterisk ====

cd /usr/src
tar -xvzf asterisk-1.6.2-current.tar.gz
cd asterisk-1.6.2.11/
make clean
./configure
make
make install
make samples
make config

== Configuration Files ==

Regardless of what OS you are running Asterisk on and regardless of what method of installation you used to install it, there are 2 main configuration files that we need to work with and one file we need to generate and include:

=== extensions.conf ===
If you are using an existing Asterisk server then add the following lines to the [default] context:
#include "fgcom.inc"
include => fgcom
Or if you are using a new Asterisk install remove everything from ''''extensions.conf'''' and put in:
[general]
static=yes
writeprotect=yes
;
[default]
#include "fgcom.inc"
include => fgcom

=== iax.conf ===
[general]
bandwidth=low
disallow=lpc10
jitterbuffer=yes
forcejitterbuffer=no
tos=lowdelay
autokill=30000
codecpriority=host
disallow=all
allow=gsm
allow=ilbc
allow=g726
language=en
maxauthreq=30
context=fgcom
minregexpire=30
maxregexpire=10800
maxexpirey=10800
defaultexpirey=10800
;
[guest]
type=user
username=guest
secret=guest
context=fgcom
qualify=yes
callerid=Guest IAX User
host=dynamic
requirecalltoken=no
;

=== fgcom.inc ===
This is a special file generated using a script. It should be placed in the Asterisk config directory (/etc/asterisk/ normally).

You need the gen_phonebook.pl script (https://sourceforge.net/p/flightgear/fgcom/ci/master/tree/server/gen_phonebook.pl?format=raw) and nav.dat.gz and apt.dat.gz from the git repository.

Put them all in the same folder and run the script.

[[Category:Multiplayer]]
[[Category:FGCom]]

Howto:Set up a FGCom server

2015-07-27T10:40:31Z

F-ojac: Fixing typo

This page is for installing a '''FGCom Server'''. If you want to have voice communications within [[FlightGear]], you are probably wanting to install the [[FGCom|client]].

This document is to assist in setting up hot spares as potential failover for the new server and for replacing that server if/when that becomes necessary. It is not expected that this will be a widely used document, nonetheless, the information contained is no less valuable for that.

== Install Asterisk ==
You need an instance of Asterisk on the server, you can either install Asterisk via a package manager (if you're using CentOS/RHEL) or via the source code if you're on a different distro. For easiness (and because I can) I chose to do it via the package manager.
We used CentOS (this works for RedHat too) and the instructions for installing it on CentOS/RHEL are as follows:

=== CentOS/RHEL ===

==== Setting up the Package Manager ====

In the ''''/etc/yum.repos.d'''' folder create the following files:

centos-asterisk.repo:
[asterisk-tested]
name=CentOS-$releasever - Asterisk - Tested
baseurl=http://packages.asterisk.org/centos/$releasever/tested/$basearch/
enabled=0
gpgcheck=0
#gpgkey=http://packages.asterisk.org/RPM-GPG-KEY-Digium

[asterisk-current]
name=CentOS-$releasever - Asterisk - Current
baseurl=http://packages.asterisk.org/centos/$releasever/current/$basearch/
enabled=1
gpgcheck=0
#gpgkey=http://packages.asterisk.org/RPM-GPG-KEY-Digium

centos-digium.repo:
[digium-tested]
name=CentOS-$releasever - Digium - Tested
baseurl=http://packages.digium.com/centos/$releasever/tested/$basearch/
enabled=0
gpgcheck=0
#gpgkey=http://packages.digium.com/RPM-GPG-KEY-Digium

[digium-current]
name=CentOS-$releasever - Digium - Current
baseurl=http://packages.digium.com/centos/$releasever/current/$basearch/
enabled=1
gpgcheck=0
#gpgkey=http://packages.digium.com/RPM-GPG-KEY-Digium

==== Installing the Packages ====

[root@localhost~]# yum install asterisk16 asterisk16-configs asterisk16-voicemail dahdi-linux dahdi-tools libpri

You will then see something like this:
=========================================================================================
Package Arch Version Size
=========================================================================================
Installing:
asterisk16 i386 1.6.0.15-1_centos5 4.0 k
Installing for dependencies:
asterisk-sounds-core-en-gsm noarch 1.4.15-1_centos5 1.7 M
asterisk16-core i386 1.6.0.15-1_centos5 11 M
asterisk16-dahdi i386 1.6.0.15-1_centos5 837 k
asterisk16-doc i386 1.6.0.15-1_centos5 10 k
asterisk16-voicemail i386 1.6.0.15-1_centos5 264 k
dahdi-firmware noarch 2.0.1-1_centos5 1.9 k
dahdi-firmware-oct6114-064 noarch 1.05.01-1_centos5 165 k
dahdi-firmware-oct6114-128 noarch 1.05.01-1_centos5 166 k
dahdi-firmware-tc400m noarch MR6.12-1_centos5 1.7 M
dahdi-linux i386 2.2.0.2-1_centos5 3.3 k
kernel i686 2.6.18-164.el5 16 M
kmod-dahdi-linux i686 2.2.0.2-1_centos5.2.6.18_164.el5 3.4 M
kmod-dahdi-linux-fwload-vpmadt032 i686 2.2.0.2-1_centos5.2.6.18_164.el5 124 k
libpri i386 1.4.10.1-1_centos5 103 k
libss7 i386 1.0.2-1_centos5 63 k
yum-kmod noarch 1.1.16-13.el5.centos 17 k

Transaction Summary
========================================================================================
Install 17 Package(s)
Update 0 Package(s)
Remove 0 Package(s)

Total download size: 35 M
Is this ok [y/N]:

Press {{Key press|Y}} and then {{Key press|Enter}}

Downloading Packages:
(1/17): dahdi-firmware-2.0.1-1_centos5.noarch.rpm | 1.9 kB 00:00
(2/17): dahdi-linux-2.2.0.2-1_centos5.i386.rpm | 3.3 kB 00:00
(3/17): asterisk16-1.6.0.15-1_centos5.i386.rpm | 4.0 kB 00:00
(4/17): asterisk16-doc-1.6.0.15-1_centos5.i386.rpm | 10 kB 00:00
(5/17): yum-kmod-1.1.16-13.el5.centos.noarch.rpm | 17 kB 00:00
(6/17): libss7-1.0.2-1_centos5.i386.rpm | 63 kB 00:00
(7/17): libpri-1.4.10.1-1_centos5.i386.rpm | 103 kB 00:00
(8/17): kmod-dahdi-linux-fwload-vpmadt032-2.2.0.2-1_centos5.2.6.18_164.el5.i686.rpm | 124 kB 00:00
(9/17): dahdi-firmware-oct6114-064-1.05.01-1_centos5.noarch.rpm | 165 kB 00:00
(10/17): dahdi-firmware-oct6114-128-1.05.01-1_centos5.noarch.rpm | 166 kB 00:00
(11/17): asterisk16-voicemail-1.6.0.15-1_centos5.i386.rpm | 264 kB 00:01
(12/17): asterisk16-dahdi-1.6.0.15-1_centos5.i386.rpm | 837 kB 00:04
(13/17): dahdi-firmware-tc400m-MR6.12-1_centos5.noarch.rpm | 1.7 MB 00:08
(14/17): asterisk-sounds-core-en-gsm-1.4.15-1_centos5.noarch.rpm | 1.7 MB 00:08
(15/17): kmod-dahdi-linux-2.2.0.2-1_centos5.2.6.18_164.el5.i686.rpm | 3.4 MB 00:17
(16/17): asterisk16-core-1.6.0.15-1_centos5.i386.rpm | 11 MB 00:57
(17/17): kernel-2.6.18-164.el5.i686.rpm | 16 MB 00:23
-------------------------------------------------------------------------------------
Total 283 kB/s | 35 MB
02:06
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID e8562897
Importing GPG key 0xE8562897 "CentOS-5 Key (CentOS 5 Official Signing Key) " from
/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
Is this ok [y/N]:

Press {{Key press|Y}} and then {{Key press|Enter}} again

Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : kernel [ 1/17]
Installing : asterisk16-core [ 2/17]
Installing : kmod-dahdi-linux [ 3/17]
Installing : asterisk16-doc [ 4/17]
Installing : kmod-dahdi-linux-fwload-vpmadt032 [ 5/17]
Installing : asterisk-sounds-core-en-gsm [ 6/17]
Installing : dahdi-firmware-oct6114-064 [ 7/17]
Installing : yum-kmod [ 8/17]
Installing : dahdi-firmware-tc400m [ 9/17]
Installing : dahdi-firmware-oct6114-128 [10/17]
Installing : asterisk16-voicemail [11/17]
Installing : libss7 [12/17]
Installing : libpri [13/17]
Installing : dahdi-firmware [14/17]
Installing : dahdi-linux [15/17]
Installing : asterisk16-dahdi [16/17]
Installing : asterisk16 [17/17]

Installed: asterisk16.i386 0:1.6.0.15-1_centos5
Dependency Installed: asterisk16-core.i386 0:1.6.0.15-1_centos5 ...
Complete!
[root@localhost yum.repos.d]#

When you are met with the screen above with the words ''''Complete!'''' on it then you are ready to move on to Part 2: Configuration Files

=== Debian/Ubuntu ===
This about covers it:

apt-get install asterisk

=== Install from Source ===
==== Downloading the Source ====
Downloading necessary packages: LIBPRI, DAHDI, AND Asterisk

cd /usr/src
wget http://www.asterisk.org/downloads/asterisk/releases/asterisk-1.6.2-current.tar.gz
wget http://downloads.asterisk.org/pub/telephony/libpri/releases/libpri-1.4.11.3.tar.gz
wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.3.0.1+2.3.0.tar.gz

==== Installing Libpri ====

tar -xvzf libpri-1.4.11.3.tar.gz
cd libpri-1.4.11.3
make
make install

==== Installing DAHDI ====

cd /usr/src
tar -xvzf dahdi-linux-complete-2.3.0.1+2.3.0.tar.gz
cd dahdi-linux-complete-2.3.0.1+2.3.0
make
make install
make config

==== Installing Asterisk ====

cd /usr/src
tar -xvzf asterisk-1.6.2-current.tar.gz
cd asterisk-1.6.2.11/
make clean
./configure
make
make install
make samples
make config

== Configuration Files ==

Regardless of what OS you are running Asterisk on and regardless of what method of installation you used to install it, there are 2 main configuration files that we need to work with and one file we need to generate and include:

=== extensions.conf ===
If you are using an existing Asterisk server then add the following lines to the [default] context:
#include "fgcom.inc"
include => fgcom
Or if you are using a new Asterisk install remove everything from ''''extensions.conf'''' and put in:
[general]
static=yes
writeprotect=yes
;
[default]
#include "fgcom.inc"
include => fgcom

=== iax.conf ===
[general]
bandwidth=low
disallow=lpc10
jitterbuffer=yes
forcejitterbuffer=no
tos=lowdelay
autokill=30000
codecpriority=host
disallow=all
allow=gsm
allow=ilbc
allow=g726
language=en
maxauthreq=30
context=fgcom
minregexpire=30
maxregexpire=10800
maxexpirey=10800
defaultexpirey=10800
;
[guest]
type=user
username=guest
secret=guest
context=fgcom
qualify=yes
callerid=Guest IAX User
host=dynamic
requirecalltoken=no
;

=== fgcom.inc ===
This is a special file generated using a script. It should be placed in the Asterisk config directory (/etc/asterisk/ normally).

You need the gen_phonebook.pl script (http://dl.dropbox.com/u/21858433/gen_phonebook.pl) and nav.dat.gz and apt.dat.gz from the git repository.

Put them all in the same folder and run the script.

[[Category:Multiplayer]]
[[Category:FGCom]]

Fr/TerraGear

2015-07-27T08:37:33Z

F-ojac: /* Obtenir TerraGear */

<div style="padding-left:20px;">''Ne pas confondre avec [[Fr/TerraSync|TerraSync]], outil de téléchargement de scènes à la volée.''</div>

[[File:TerraGear The Hague wireframe.png|thumb|270px|Une vue en fil de fer d'une scène détaillée avec données [[CORINE]] et [[OSM]] (OpenStreetMap), générée par TerraGear.]]
'''TerraGear''' est un ensemble d'outils open source et de librairies de rendu qui peut transformer les données SIG disponibles publiquement en représentations 3D (c'est à dire des modèles 3D ou des cartes 3D) de la Terre leur utilisation dans des projets de rendu en temps réel. TerraGear peut importer des données 3D comme les grilles de terrain DEM, des ensembles de données 2D polygonales comme les contours des côtes, les délimitations des villes, le contour des lacs, et les ensembles de données raster 2D comme les plans d'occupation des sols NAOO 1 km. Il comprend également les outils pour générer des [[Airport|aéroports]] réalistes, des pistes et des éclairages selon les données FAA disponibles.
TerraGear est l'outil de base principal pour générer les [[Fr/Scenery|scènes]] du projet [[Fr/FlightGear|FlightGear]].

== Introduction ==
Pour de nombreuses raisons, vous pourriez vouloir construire vous-même le terrain, plutôt que de le télécharger à partir des scènes disponibles sur FlightGear. Par exemple, si vous utilisez [[WED]] pour créer ou modifier l'agencement d'un aéroport, vous pourriez vouloir visualiser comment l'aéroport une fois modifié se présente dans les scènes, avant de décider si vous êtes content du résultat. Et normalement, pour visualiser et utiliser l'aéroport dans les scènes, il faut soumettre les modifications à XPlane et attendre la prochaine mise à jour de la zone concernée via [[TerraSync]] ou dans les [http://www.flightgear.org/Downloads/scenery.html données officielles de scènes de FlightGear]. Si vous parvenez à construire le terrain vous-même, vous pouvez commencer à l'utiliser immédiatement.

Peut-être que les scènes officielles sont trop détaillées pour votre machine un peu ancienne, et que vous voudriez construire un terrain avec un DEM (modèle numérique de terrain) de plus faible résolution, afin de diminuer le nombre de polygones et ainsi augmenter votre taux de rafraichissement d'image. Soit vous avez une machine ultra-rapide, et vous voulez construire votre propre terrain avec des données vectorielles de plus haute résolution (vmap1, Tiger) pour obtenir de meilleures routes/rivières. Pour toutes ces raisons, utiliser TerraGear est une bonne idée.

== Obtenir TerraGear ==
=== Avec le script download_and_compile.sh ===
Téléchargez le script download_and_compile.sh si vous ne l'avez pas déjà. Copiez-le dans un répertoire particulier, il n'est pas nécessaire d'être root pour l'exécuter.
<syntaxhighlight lang="bash">
wget http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
chmod 755 download_and_compile.sh
./download_and compile.sh SIMGEAR TERRAGEAR
</syntaxhighlight>
Cela compilera SIMGEAR (pre-requis) et TERRAGEAR, ainsi que leurs dépendances respectives si nécessaire et vous aurez terminé la partie compilation.

=== Versions pré-compilées ===
* [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip dernières versions pour Windows], construites par le [[FlightGear Build Server]].
* [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32 Binaires Windows] (anciens)

=== Sources ===
Les sources sont maintenues dans un dépôt [[Fr/FlightGear_et_Git|git]] de Sourceforge.
git clone git://git.code.sf.net/p/flightgear/terragear flightgear-terragear

== Compilation ==
=== Dépendances ===
* TerraGear
** [[SimGear]] - '''Pas''' simgear-cs! (paquetage simgear-dev)
*** SimGear peut être compilé sans support OSG, éliminant ainsi de nombreuses dépendances. Utilisez l'option "-DSIMGEAR_HEADLESS=YES" pour une construction minimale.
** libnewmat - au moins version newmat11 (qui est en version beta actuellement). Voir [http://mapserver.flightgear.org/git/?p=terragear-cs;a=blob;f=README.newmat;h=95570b6b279d3d00bd7664cd4f00d6c4802aed1b;hb=HEAD README.newmat] pour plus d'informations sur comment l'obtenir/l'installer
** [http://pocoproject.org/ POCO] - Pour support multiprocesseurs
** [http://www.cgal.org/ CGAL] - Pour les calculs géométrique de haute précision
** [http://www.gdal.org/ libgdal]
** libexpat

=== Construction ===
cmake . [options]
make install
Options pour <tt>cmake</tt>:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Plate-formes spécifiques ===
* Debian : [[Building FlightGear - Debian#TerraGear]]
* Gentoo : <tt>emerge -av terragear</tt> Voir [[Building Flightgear - Gentoo]].
* Ubuntu : [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== Interface graphique ==
L'interface graphique [[TerraGear GUI]] est disponible pour ceux qui ne savent pas utiliser ou n'utilisent pas les options en lignes de commande.

== Contenu connexe ==
* [[Fr/Utiliser_TerraGear|Utiliser TerraGear]]
* [[Fr/TerraGear_CORINE|TerraGear CORINE]]
* [[TerraGear Documentation]]

{{Terra}}
{{Building}}

[[Category:Scenery enhancement]]
[[en:TerraGear]]
[[es:TerraGear]]

Fr/Accueil

2015-07-27T08:34:55Z

F-ojac: Slight update.

{{Main page/Header
|title=Bienvenue sur le [[FlightGear wiki|wiki FlightGear]]
|subtitle=''Fly free!''
|rightbox={{Main page/Languages}}
|introduction=
[[Help:Your first article|Participez]] en créant, en améliorant ou en complétant des articles.

|rightcolumn1= [[File:Portal user.png|40px]] </div>
[[Fr/Portal:Utilisateur|Utilisation]] 
[[Fr/Nouveau sur flightgear|Nouveau sur flightgear]] 
[[Fr/Glossaire|Le Glossaire de FlightGear]] 
[[Fr/Foire aux questions|Foire aux questions]] · [[Fr/Howto: Débarrassez-vous des erreurs les plus fréquentes|Messages d'erreur communs]] · [[Troubleshooting problems|Dépannage]] 
[[Fr/Avions|Les avions]] · [[Fr/Helicoptere|Les hélicoptères]] · [[Fr/Vehicules|Les véhicules]] 
[[Fr/Installer une scène|Installer une scène]] · [[Fr/Howto Installer un avion|Installer un avion]] 
[[Fr/Piloter l'hélicoptère|Piloter l'hélicoptère]]
|rightcolumn2= [[File:Portal developer.png|40px]] </div>
[[Fr/Portal:Développeur|Développement]] 

[[Portal:Developer/Aircraft|Aéronefs]] · [[Portal:Developer/Scenery|Scènes]] 
[[Fr/Placer des objets 3D avec UFO|Placer des objets]] · [[Fr/Howto: Utiliser QGIS et images satellites|Améliorer les terrains]] 
[[How the FlightGear project works|Comment le projet FlightGear fonctionne]]
|rightcolumn3= [[File:Portal wiki.png|40px]] </div>
 [[Fr/Portal:Wiki|Wiki]] 

[[FlightGear Wiki|À propos du wiki]] · [[Fr/Aide:Contenu|Aide]] 
[[Help:Your first article|Votre premier article]] · [[Fr/Help:Traduire|Traduire]] 
[[Special:Categories|Catégories]]


|sections=
{{Main page/Leftbox|title=About FlightGear
|logo=FlightGear logo.png
|contents= '''[[Fr/FlightGear|FlightGear]] Flight Simulator''' est un logiciel libre de simulation de vol sophistiqué et fonctionnel, créé et maintenu entièrement par des volontaires. Le code source complet est accessible par [[Fr/FlightGear et Git | Git]], sous une licence libre [[GNU General Public License]].

Le projet [[Fr/FlightGear|FlightGear]] propose un environnement de développement de simulateur de vol sophistiqué, pour une utilisation académique ou à des fins de recherche; il permet le développement d'autres idées intéressantes en simulation de vol, tout en restant aussi accessible à l'utilisateur lambda. Toute personne intéressée peut [[Fr/Volontaires|contribuer]] à l'ajout de fonctionnalités ou à l'amélioration de FlightGear (avions, scènes). De plus, il existe de nombreux [[FlightGear related projects|projets connexes]] ([http://www.flightgear.org/links.html liens]).

FlightGear est doté d'une documentation illustrée, parmi laquelle "Le Manuel", disponible aux formats [http://mapserver.flightgear.org/getstart-fr.pdf PDF] et [http://www.flightgear.org/Docs/getstart/getstart.html HTML]. Ce Wiki a été lancé en 2006 et couvre actuellement une bonne partie des sujets liés à FlightGear. La fonctionnalité multi-langues est plus récente (été 2009) et, pour le moment, seulement une petite partie est effectivement traduite.

=== Je suis à la recherche de ... ===
* [[:Fr:Portal:Utilisateur|Aide pour l'utilisation de FlightGear]]
* [[Portal:Developer|Comment contribuer à quelque chose pour FlightGear]]

}}
{{Main page/Leftbox|title=Nouvelles
|logo=Nuvola apps knewsticker.png
|contents={{News}} }}
{{Main page/Leftbox|title=Le saviez-vous...
|logo=Nuvola apps ktip.png
|contents={{Did you know}} }}

}}

{{Main page/Rightcolumn
|title= [[:Category:Picture of the week|Image de la semaine]]
|contents= <center style="padding-top:.9em;">{{POTW/{{CURRENTYEAR}}-{{CURRENTWEEK}}}}</center>
|padding-right=23px
}}

{{Main page/Rightcolumn end
|title= [[FlightGear and Git|Development repository status]]
|contents= <center style="padding-top:.9em;">{{GitStatus}}</center>
|padding-right=23px
}}

TerraGear

2015-07-27T08:31:18Z

F-ojac: Adding a download_and_compile easy way.

{{Hatnote|Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.}}

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[WED]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Using the download_and_compile.sh script ===
Get the script download_and_compile.sh if you don't already have it. Copy it intp a specific directory, no need to be root.
<syntaxhighlight lang="bash">
wget http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
chmod 755 download_and_compile.sh
./download_and compile.sh SIMGEAR TERRAGEAR
</syntaxhighlight>
This will build SIMGEAR (pre-requisite) and TERRAGEAR properly, installing dependencies if necessary and you will be done for the TG compilation part of the process.

=== Pre-compiled builds ===
* [http://build.flightgear.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[Git]] repository at SourceForge and a mirror at mapserver.
<syntaxhighlight lang="bash">
git clone http://mapserver.flightgear.org/git/terragear
</syntaxhighlight>

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
* Debian: [[Building FlightGear - Debian#TerraGear]]
* Gentoo: <tt>emerge -av terragear</tt> See [[Building Flightgear - Gentoo]].
* Ubuntu: [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear]]

[[es:TerraGear]]
[[fr:TerraGear]]

Scripted Compilation on Linux Debian/Ubuntu

2015-07-27T08:25:30Z

F-ojac: Removing ref to gitorious.

The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

Please also see [[Superbuild]].

=== Update Available ===

[[user:F-JJTH|F-JJTH]] has published version 2.33 of the script.

download the newest script with this command:

wget -O download_and_compile.sh http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw

=== Cut to the Chase: for the impatient ===

cd <your working directory for building flightgear>
wget -O download_and_compile.sh http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
chmod +x download_and_compile.sh
mkdir -p stable
mkdir -p next
cd stable
../download_and_compile.sh -s
cd ../next
../download_and_compile.sh -p n

=== Conversion of directory structure from earlier versions of download_and_compile.sh ===

Earlier versions of the script used a different directory structure. If you used the earlier version, the new script includes a section that will convert the earlier structure to the current set of directories.

=== Disk Space Requirements ===
As of Version 3.4.0 in June 2015, this script require 2-3 gb of disk space, note that this includes downloaded source trees, build files, and fgdata.

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGo!]]
* [[FGX]]
* [[Terragear]]
* [[TerraGear_GUI]]
* [[OpenRadar]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

Note that openRTI is just another optional dependency for HLA support: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For the time being, you should be just fine building without HLA support. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it's probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.

you can pass the '''-i''' option to compile OpenRTI, as well as SimGear and FlightGear re-configured with -D ENABLE_RTI=ON option (experimental)

<syntaxhighlight lang="bash">./download_and_compile.sh -i</syntaxhighlight>

==== When building Next you may see build errors ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not. Building the stable version should always work unless there is a problem with the script 

== Download ==
You can download the script here:
* http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
*The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script from the master branch. You can replace master with next to get a later version of the script if one is available:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).
After building stable or the latest, if you need to build a different version, try the instructions for [[Avoiding Multiple Downloads of fgdata]].
=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
./download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any options,
the latest development version is built.

'''Warning''': The development version of Flightgear changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
./download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
When using brisa's script, the two FG dependencies/libs are usually not installed system-wide, but in a custom location (that makes it possible, to easily use different OSG/SG/FG versions on a single system, i.e. for testing purposes - but also to have separate build trees (optimized/debug) ) - which is why you either need to set LD_LIBRARY_PATH or simply use Brisa's script to run everything (something like run_fgfs.sh, which automatically sets up all environment variables according to your build settings).

To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

fgrun will save its settings in ~/.fltk/flightgear.org/fgrun.prefs you may want to save copies of the preferences customized for stable and next.

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
./download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the [[TerraSync]] program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

=== OpenRTI undefined reference errors ===
Sometimes due to the way d&c build cleans up projects, linking errors might occur, this is the case with this error "libRTI-NG.so: undefined reference to xxx", sadly at this point either you need to patch the d&c script to clean OpenRTI with rm -f CMakeCache.txt && rm -rf CMakeFiles/, or just start from a clean environment, assuming you are in the parent project directory, you will need to issue this command to clean everything(except FGDATA):
<pre>
rm -rf build/* install/simgear/ install/openrti/ install/flightgear/share/ install/flightgear/bin/
</pre>

see this thread for more details(http://forum.flightgear.org/viewtopic.php?f=45&t=26244)

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
./download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* TERRAGEAR (to compile and install only terragear!)
* TERRAGEARGUI (to compile and install only terrageargui!)
* OPENRADAR (to compile and install only OpenRadar!)
* FGO (to compile and install only Fgo!)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
./download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
./download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together. 
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of distro packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
./download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

== Optimus technology ==
If your computer has a GPU with optimus technology, you need a dedicated script in order to make FG running with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FG installation directory (where you executed ./download_and_compile.sh) :
<pre>
sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
</pre>
Now you can run FG with ./run_fgfs_optirun.sh

the same is applied with the FGRUN launcher :
<pre>
sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh
</pre>

== Remove warning message for DDS files ==
You can remove the warning message displayed when DDS files are parsed by SimGear by adding the following line just after '''cd "simgear"''' line :
<pre>
sed -i s/SG_ALERT,\ \"Image/SG_WARN,\ \"Image/g simgear/scene/model/ModelRegistry.cxx
</pre>

[[Category:Building from source]]

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]
[[fr:Script de compilation sous Linux Debian/Ubuntu]]

Scripted Compilation on Linux Debian/Ubuntu

2015-07-27T08:24:24Z

F-ojac: Removing bracket

The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

Please also see [[Superbuild]].

=== Update Available ===

[[user:F-JJTH|F-JJTH]] has published version 2.33 of the script.

download the newest script with this command:

wget -O download_and_compile.sh http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw

=== Cut to the Chase: for the impatient ===

cd <your working directory for building flightgear>
wget -O download_and_compile.sh http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
chmod +x download_and_compile.sh
mkdir -p stable
mkdir -p next
cd stable
../download_and_compile.sh -s
cd ../next
../download_and_compile.sh -p n

=== Conversion of directory structure from earlier versions of download_and_compile.sh ===

Earlier versions of the script used a different directory structure. If you used the earlier version, the new script includes a section that will convert the earlier structure to the current set of directories.

=== Disk Space Requirements ===
As of Version 3.4.0 in June 2015, this script require 2-3 gb of disk space, note that this includes downloaded source trees, build files, and fgdata.

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGo!]]
* [[FGX]]
* [[Terragear]]
* [[TerraGear_GUI]]
* [[OpenRadar]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

Note that openRTI is just another optional dependency for HLA support: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For the time being, you should be just fine building without HLA support. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it's probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.

you can pass the '''-i''' option to compile OpenRTI, as well as SimGear and FlightGear re-configured with -D ENABLE_RTI=ON option (experimental)

<syntaxhighlight lang="bash">./download_and_compile.sh -i</syntaxhighlight>

==== When building Next you may see build errors ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not. Building the stable version should always work unless there is a problem with the script 

== Download ==
You can download the script here:
* http://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh?format=raw
*The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script from the master branch. You can replace master with next to get a later version of the script if one is available:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://www.gitorious.org/fg/fgmeta/raw/download_and_compile.sh
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).
After building stable or the latest, if you need to build a different version, try the instructions for [[Avoiding Multiple Downloads of fgdata]].
=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
./download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any options,
the latest development version is built.

'''Warning''': The development version of Flightgear changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
./download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
When using brisa's script, the two FG dependencies/libs are usually not installed system-wide, but in a custom location (that makes it possible, to easily use different OSG/SG/FG versions on a single system, i.e. for testing purposes - but also to have separate build trees (optimized/debug) ) - which is why you either need to set LD_LIBRARY_PATH or simply use Brisa's script to run everything (something like run_fgfs.sh, which automatically sets up all environment variables according to your build settings).

To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

fgrun will save its settings in ~/.fltk/flightgear.org/fgrun.prefs you may want to save copies of the preferences customized for stable and next.

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
./download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the [[TerraSync]] program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

=== OpenRTI undefined reference errors ===
Sometimes due to the way d&c build cleans up projects, linking errors might occur, this is the case with this error "libRTI-NG.so: undefined reference to xxx", sadly at this point either you need to patch the d&c script to clean OpenRTI with rm -f CMakeCache.txt && rm -rf CMakeFiles/, or just start from a clean environment, assuming you are in the parent project directory, you will need to issue this command to clean everything(except FGDATA):
<pre>
rm -rf build/* install/simgear/ install/openrti/ install/flightgear/share/ install/flightgear/bin/
</pre>

see this thread for more details(http://forum.flightgear.org/viewtopic.php?f=45&t=26244)

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
./download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* TERRAGEAR (to compile and install only terragear!)
* TERRAGEARGUI (to compile and install only terrageargui!)
* OPENRADAR (to compile and install only OpenRadar!)
* FGO (to compile and install only Fgo!)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
./download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
./download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together. 
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of distro packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
./download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

== Optimus technology ==
If your computer has a GPU with optimus technology, you need a dedicated script in order to make FG running with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FG installation directory (where you executed ./download_and_compile.sh) :
<pre>
sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
</pre>
Now you can run FG with ./run_fgfs_optirun.sh

the same is applied with the FGRUN launcher :
<pre>
sed 's|\./fgrun|optirun ./fgrun|' run_fgrun.sh > run_fgrun_optirun.sh && chmod +x run_fgrun_optirun.sh
</pre>

== Remove warning message for DDS files ==
You can remove the warning message displayed when DDS files are parsed by SimGear by adding the following line just after '''cd "simgear"''' line :
<pre>
sed -i s/SG_ALERT,\ \"Image/SG_WARN,\ \"Image/g simgear/scene/model/ModelRegistry.cxx
</pre>

[[Category:Building from source]]

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]
[[fr:Script de compilation sous Linux Debian/Ubuntu]]

TerraGear

2015-07-24T16:30:11Z

F-ojac: Removing link to Taxidraw.

{{Hatnote|Not to be confused with [[TerraSync]], a tool to download scenery on-the-fly.}}

[[File:TerraGear The Hague wireframe.png|thumb|270px|A wireframe view of detailed [[CORINE]] and [[OSM]] scenery, generated by TerraGear.]]
'''TerraGear''' is a collection of open-source tools and rendering libraries which can transform publically available GIS data in 3D representations (i.e. 3D models or 3D maps) of the earth for use in real time rendering projects. TerraGear can import 3D data sets such as DEM terrain grids, 2D polygon data sets such as coastlines, city outlines, lake outlines, and 2D raster data sets such as the 1 km NAOO land use/land cover data. It also has tools for generating realistic [[airport]]s, runways, and lighting based on available FAA data.

TerraGear is the primary tool used to generate the [[scenery]] for the [[FlightGear]] project.

== Introduction ==
For a variety of reasons you might want to build terrain yourself, rather than downloading it from the available scenery on FlightGear. For instance, if you use [[WED]] to create or modify an airport layout, you might wish to see how that modified airport would look in the Scenery before deciding you're happy with the results. And normally, to see and use the airport in the scenery, it's necessary to submit the modifications to the FlighGear scenery staff and then wait untill the next update of the scenery of that area is available via [[TerraSync]] or in the [http://www.flightgear.org/download/scenery/ official FlightGear Scenery] build. If you can build terrain yourself, you can start using it right away.

Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher resolution vector data (vmap1, Tiger) to get better roads/rivers. For all these reasons learning how to use TerraGear is a good idea.

== Getting TerraGear ==
=== Pre-compiled builds ===
* [http://build.flightgear.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip Latest Windows build], built by the [[FlightGear Build Server]].

:*[[TerraGear_Installation_for_Windows|Detailed Windows Installation Instructions]]

=== Source ===
The source is hold in a [[Git]] repository at SourceForge and a mirror at mapserver.
<syntaxhighlight lang="bash">
git clone http://mapserver.flightgear.org/git/terragear
</syntaxhighlight>

== Compilation ==
=== Dependencies ===
* TerraGear
** [[SimGear]] - '''Not''' simgear-cs! (simgear-dev package)
*** SimGear can be compiled without OSG support thus eliminating many deps, like OSG. Use "-DSIMGEAR_HEADLESS=YES" for a minimal build.
** [http://www.cgal.org/ CGAL] - For high accuracy geometric calculations
** [http://www.gdal.org/ libgdal]

=== Building ===
cmake . [options]
make install
<tt>cmake</tt> options:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Platform specific ===
* Debian: [[Building FlightGear - Debian#TerraGear]]
* Gentoo: <tt>emerge -av terragear</tt> See [[Building Flightgear - Gentoo]].
* Ubuntu: [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== GUI Tool ==
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]
* [[TerraGear Documentation]]
* [http://api-docs.freeflightsim.org/terragear/ TerraGear API docs]

{{Terra}}
{{Building}}

[[Category:TerraGear]]

[[es:TerraGear]]
[[fr:TerraGear]]

Fr/TerraGear

2015-07-24T16:28:46Z

F-ojac: Removing link to Taxidraw.

<div style="padding-left:20px;">''Ne pas confondre avec [[Fr/TerraSync|TerraSync]], outil de téléchargement de scènes à la volée.''</div>

[[File:TerraGear The Hague wireframe.png|thumb|270px|Une vue en fil de fer d'une scène détaillée avec données [[CORINE]] et [[OSM]] (OpenStreetMap), générée par TerraGear.]]
'''TerraGear''' est un ensemble d'outils open source et de librairies de rendu qui peut transformer les données SIG disponibles publiquement en représentations 3D (c'est à dire des modèles 3D ou des cartes 3D) de la Terre leur utilisation dans des projets de rendu en temps réel. TerraGear peut importer des données 3D comme les grilles de terrain DEM, des ensembles de données 2D polygonales comme les contours des côtes, les délimitations des villes, le contour des lacs, et les ensembles de données raster 2D comme les plans d'occupation des sols NAOO 1 km. Il comprend également les outils pour générer des [[Airport|aéroports]] réalistes, des pistes et des éclairages selon les données FAA disponibles.
TerraGear est l'outil de base principal pour générer les [[Fr/Scenery|scènes]] du projet [[Fr/FlightGear|FlightGear]].

== Introduction ==
Pour de nombreuses raisons, vous pourriez vouloir construire vous-même le terrain, plutôt que de le télécharger à partir des scènes disponibles sur FlightGear. Par exemple, si vous utilisez [[WED]] pour créer ou modifier l'agencement d'un aéroport, vous pourriez vouloir visualiser comment l'aéroport une fois modifié se présente dans les scènes, avant de décider si vous êtes content du résultat. Et normalement, pour visualiser et utiliser l'aéroport dans les scènes, il faut soumettre les modifications à XPlane et attendre la prochaine mise à jour de la zone concernée via [[TerraSync]] ou dans les [http://www.flightgear.org/Downloads/scenery.html données officielles de scènes de FlightGear]. Si vous parvenez à construire le terrain vous-même, vous pouvez commencer à l'utiliser immédiatement.

Peut-être que les scènes officielles sont trop détaillées pour votre machine un peu ancienne, et que vous voudriez construire un terrain avec un DEM (modèle numérique de terrain) de plus faible résolution, afin de diminuer le nombre de polygones et ainsi augmenter votre taux de rafraichissement d'image. Soit vous avez une machine ultra-rapide, et vous voulez construire votre propre terrain avec des données vectorielles de plus haute résolution (vmap1, Tiger) pour obtenir de meilleures routes/rivières. Pour toutes ces raisons, utiliser TerraGear est une bonne idée.

== Obtenir TerraGear ==
=== Versions pré-compilées ===
* [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip dernières versions pour Windows], construites par le [[FlightGear Build Server]].
* [ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32 Binaires Windows] (anciens)

=== Sources ===
Les sources sont maintenues dans un dépôt [[Fr/FlightGear_et_Git|git]] de Sourceforge.
git clone git://git.code.sf.net/p/flightgear/terragear flightgear-terragear

== Compilation ==
=== Dépendances ===
* TerraGear
** [[SimGear]] - '''Pas''' simgear-cs! (paquetage simgear-dev)
*** SimGear peut être compilé sans support OSG, éliminant ainsi de nombreuses dépendances. Utilisez l'option "-DSIMGEAR_HEADLESS=YES" pour une construction minimale.
** libnewmat - au moins version newmat11 (qui est en version beta actuellement). Voir [http://mapserver.flightgear.org/git/?p=terragear-cs;a=blob;f=README.newmat;h=95570b6b279d3d00bd7664cd4f00d6c4802aed1b;hb=HEAD README.newmat] pour plus d'informations sur comment l'obtenir/l'installer
** [http://pocoproject.org/ POCO] - Pour support multiprocesseurs
** [http://www.cgal.org/ CGAL] - Pour les calculs géométrique de haute précision
** [http://www.gdal.org/ libgdal]
** libexpat

=== Construction ===
cmake . [options]
make install
Options pour <tt>cmake</tt>:
-DCMAKE_PREFIX_PATH="/path/to/lib/install/prefix"

=== Plate-formes spécifiques ===
* Debian : [[Building FlightGear - Debian#TerraGear]]
* Gentoo : <tt>emerge -av terragear</tt> Voir [[Building Flightgear - Gentoo]].
* Ubuntu : [[Building terragear in Ubuntu 910 (32- or 64-bit)]]

== Interface graphique ==
L'interface graphique [[TerraGear GUI]] est disponible pour ceux qui ne savent pas utiliser ou n'utilisent pas les options en lignes de commande.

== Contenu connexe ==
* [[Fr/Utiliser_TerraGear|Utiliser TerraGear]]
* [[Fr/TerraGear_CORINE|TerraGear CORINE]]
* [[TerraGear Documentation]]

{{Terra}}
{{Building}}

[[Category:Scenery enhancement]]
[[en:TerraGear]]
[[es:TerraGear]]

Howto:Test your airport layout: quick and easy

2015-07-05T15:15:32Z

F-ojac: Link to tgweb

Thanks to LucMTL in [http://www.flightgear.org/forums/viewtopic.php?f=5&t=3230&st=0&sk=t&sd=a&start=60#p29683 this post] we can now test our new airport layout easily!

== Required software ==
* [[WED]] to draw/change the airport layout (runways, taxiways, tarmac).
* [[TerraGear]] to generate the FlightGear scenery.

== Relative simply method ==
=== File creation ===

Let's suppose your airport in project has the ICAO code: ''ABCD''.

# Create a folder anywhere named with any name, and copy the genapts executable into it, from the TerraGear suite.
# In WED, open your project and do the command: '''Export Airport'''. Save the export ''ABCD.dat'' file into your folder.
# Open a command line window and go to your folder in it.
# Do the command exactly as here, including the dot at the end (but put the real ICAO code of your airport of course, instead of "''ABCD''" at the input parameter): 
genapts --input=ABCD.dat --work=.
: That command will make a series of data lines pass through the screen. Your new airport has just been generated. We must now manage to put the current scenery out of our way, and place the new airport temporarily at the right place, so we can take a look at it.

=== Putting aside the current scenery ===

# Go to <tt>[[$FG_ROOT]]/Scenery/Terrain</tt>, and go through to your exact scenery sub-folder where the airport is normally stored.
# In this folder, there is already the official "ABCD.btg.gz" file existing. Rename it by adding the word BACKUP at the end of its name. That will put it aside for the moment.
# Also in that same folder, locate your exact bucket file corresponding to the place where your airport is supposed to be. For example, the bucket file for the CSK3 airport is <tt>1745385.btg.gz</tt>. Rename it by adding the word BACKUP at the end of its name. That will completely deactivate for the moment all the surrounding scenery around your airport (Important ! Otherwise, parts of your new airport layout are likely to be hidden by the old scenery).
# Finally, always in the scenery folder, locate the small text file with the same numbered name as the bucket file, but with the .stg extention. For example, for the CSK3 airport, the file is <tt>1745385.stg</tt>. Rename it also by adding the word BACKUP at the end of its name. That will put aside the current scenery instructions given to FlightGear for the local area you're working on.

=== Putting the new airport in place ===

# There should be two new subfolders in your working folder: <tt>AirportArea</tt> and <tt>AirportObj</tt>.
# In <tt>AirportObj</tt>, go through the subfolders and locate your new airport file: <tt>ABCD.btg.gz</tt>. Copy it from your working folder to the corresponding scenery folder.
# Still in <tt>AirportObj</tt>, locate also the new scenery instructions text file. It is named with the bucket number plus the .ind extension (ex. <tt>1745385.ind</tt>). Rename it to the .stg extension (ex. <tt>1745385.stg</tt>), and copy it to the scenery folder.
# Edit your .stg file: Add a first line like this:
OBJECT_BASE your_stg_number.btg
example:
OBJECT_BASE 1745385.btg
OBJECT ABCD.btg
Now start FlightGear with the [[UFO]] and go to your airport. At the beginning you will see nothing but a void. Go up, take some altitude : you can see your airport right there, you were just UNDER it at the start. It floats alone in the middle of the air, but it's all there, you can see what it looks like.

=== Restoring ===

When you're done working on the airport layout and you're satisfied :

# Go to the scenery folder and delete both the new ABCD.btg.gz and the new "bucket-number".stg file.
# Locate the three files that were renamed "BACKUP" at the end, and rename them back to their previous names.

== Quicker but dirty way ==

This way is quicker because you don't need to modify your current scenery (nor make backup copies or restore it afterward). The only drawback (the ''dirty'' part, so to speak) is that the '''only''' thing that you will see is the new airport.

* Run the genapts command as described above in the first paragraph.
* Go into the directory of the generated airport object. eg:
cd AirportObj/w060s40/w059s38/
:(Your path should be consistent with the coordinates of your airport)
* Rename the .ind file with a .stg extension. eg:
mv 1984723.ind 1984723.stg
* Get back to the AirportObj directory:
cd ../../
* Start FlightGear with the current directory as the scenery path and loacted on your new airport (change ABCD with the icao code of your airport):
fgfs --fg-scenery=. --aircraft=ufo --airport=ABCD

== Use fgviewer ==
You can also use [[FGViewer]] to look at your airport.

== Terragear web interface ==
Even quicker use the Terragear web interface at http://scenery.flightgear.org/tgweb/ . Just submit the apt.dat, it will generate the airport .btg.gz (not the surrounding tiles) for you.

And that's it!

[[Category:Howto|Airport layout test]]
[[Category:Scenery enhancement|Airport layout test]]

FlightGear World Scenery 2.0

2015-06-29T18:53:40Z

F-ojac: Fixing numbering

The '''FlightGear World Scenery 2.0''' was released during [[FSweekend]] November 2013. This new scenery reflects a major improvement over the existing default world scenery and has taken over five years to complete. A [http://mapserver.flightgear.org/map/?lon=14.56652&lat=-25.18458&zoom=1&layers=B00000000000FTFFTFFTFFFFFFFF much higher level of detail] and internal consistency characterizes this new release, in addition to the fact that it will serve as a stepping-stone for further incremental refinements.

{{caution|The new scenery is currently quite heavy and FlightGear ''will'' run slower. It ''may'' even crash FlightGear if run on systems with less than 4Gb RAM or if used with the 32 bit version of FlightGear.}}

== Source data ==
This FlightGear World Scenery was compiled from:
* ViewFinderPanoramas elevation model by Jonathan de Ferranti (using terrafit.py -x 20000 -e 10),
* VMap0 Ed.5 Worldwide Land Cover
* CORINE Land Cover 2006v16 for Europe (Source : European Union, SOeS, CORINE Land Cover, 2006 - [http://www.ifen.fr/index.php?id=88]). See [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail|here] for the correspondance between CORINE and FG textures
* Several custom land cover enhancements (to be listed here...)
* The latest airports (2013.10), maintained by Robin Peel of X-Plane
* Road, rail and rivers courses line data by OpenStreetMap [http://www.openstreetmap.org]

== Distribution ==
World Scenery 2.0 is available through the usual channels:
* [[TerraSync]]
* [http://terasaur.org/item/downloads/flightgear-v2-12/6697 Torrent]
* FlightGear main website
* [[TerraSync by hand using svn]]
* [[TerraMaster]]

== Notes ==
* All object elevation were recomputed. Thus, if some objects were defined with a bad elevation or bad offset, they may have taken a bit of elevation. Use [http://scenemodels.flightgear.org our webforms], if necessary, to fix this.
* The new scenery is currently quite heavy and hardly runs and can lead to FG crashes if run on systems with less than 4Gb RAM and if you're not using FG 64 bits. This is being worked on, however keeping a high quality scenery with a lower count of triangles is not easy. The addition of OSM roads added a lot of new triangles, hence the fps reduction.

== Known bugs and limitations ==
# Clipping of OSM roads on water showing height glitches (due to bad coast/river lines definitions and bad clipping): clip roads against landmass or add landmass where required? Should roads over bridges get removed, even in places where a 3D bridge model is missing?
# (fixed_alfa) Some z-fighting (clipper is generating the correct number of contours, but the airport hole is wound as a boundary, not a hole) and/or triangles on airports (LFRH, EDWJ (partially submerged)...);
# (fixed_alfa) Some troubles on very dense cities (such as Paris) leading to grey-white triangles on cities - see also yellow lines @LFPG;
# (unfixed_alfa) Some line issues on small airfield with LTA specific runways (LFNH, LFLI...) - the small centerlines on the runways are "floating" over the runway (20 cm to 1m), leading to some gear destructions ;-) (they didn't use lines, but surfaces that are defined as transparent and borders defined as the line type. This way you limit the number of "line features"). Probably "hot" = false would solve it. See [http://uppix.net/y1H1NB.png 1] [http://uppix.net/sMdg17.png 2] [http://uppix.net/kAXrdF.png 3] [http://uppix.net/vYuReF.png 4] [http://uppix.net/DQ4NHr.png 5]. Thanks Clément for noticing;
# Airport being located over two different tiles sometimes renders bad, leading to z-fighting (LEJR, UKKE...);
# (unfixed_alfa) On sharp cliffs, water sometimes climbs over the cliffs (see e000n40/e000n49/2958056 and [http://img809.imageshack.us/img809/2082/9n96.jpg this picture] for instance). Thanks clm76 for reporting. On the same matter, clipping between river and terrain is somewhat strange, making the river "climb" over the terrain, noticeably under bridges - probably due to the presence of the roads. See [http://img809.imageshack.us/img809/2082/9n96.jpg this example];
# Terrain and ocean z-fighting such as [http://mapserver.flightgear.org/map/?lon=12.73312&lat=55.60834&zoom=15 east of EKCH]. See tile 3155042 and EDWJ;
# The Moss Landing airport (on the coast a little bit south of KSFO) is partly submerged into the water and the airport's north end is elevated above the terrain around it. There is an area on the coast just to the north of the Moss Landing airport that is above sea level if you are up above 1000ft but is covered in water is you are on the deck. When flying over this you can see trees sticking up out of the water so the code that is placing random trees thinks this is above sea level. The old scenery didn't have either of these problems. Also if you fly over this at just the right altitude you can see this area switching back and forth between being water and land (thanks hvengel);
# On many airports where the taxiway signs are now taken from the apt.dat and put in the Terrain folder, the old signs still remain in the Object folder. See EDDF, ELLX;
# (unfixed_alfa) On ELLX there are some problems with "holes" in the pavement that flicker between grass and tarmac. I saw this (if I remember correctly) with an older development version of terragear, but this was fixed some time ago.
# (fixed_alfa) On EHAM some vertice seems to be inverted [http://uppix.net/AVUaZt.jpg see this picture]
# (fixed_alfa) At LFLI the taxiway is not correctly drawn
# The taxiway signs are not rendered correctly with transition shader set to its maximum in ALS. Quoting ThorstenB, "It occurs because you're using the terrain shader effect on something that isn't part of the terrain but in reality an artificial object placed onto the terrain. The terrain shader effect concludes correctly that a natural vertical surface cannot be anything but rock, so it replaces the default texture with the default steep gradient texture - which is rock. In my view, the proper solution would be to *not* render signs as part of the terrain but to let a different effect handle them (model-default.eff should do the trick for instance, but one could also run a lower quality terrain shader). If that is not acceptable a workaround is to declare the gradient texture for the signs as void.png as described in http://wiki.flightgear.org/Procedural_Texturing#The_gradient_texture which continues to use the terrain-specific effect but instructs the shader not to use a separate texture for steep gradients."
# sometimes some strange water width transitions, like [http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/TG%20bugs/fgfs2013-11-0822-18-06-03_zpsf3527850.jpg for the Rhein] - reported by ot-666
# (fixed_alfa) In a few airports (LEVT, LEGE are two examples), taxiways are defined in using a stack of layers: the bottom layer for the asphalt surface and the upper layer (defined as transparent) is only used to define the lines. Current tools do not support stacks of layers and the upper layer is "transparent" all the way down to the ground. See [http://i.imgur.com/AkOd5Zo.png 1] and [http://forum.flightgear.org/viewtopic.php?f=5&t=21294&p=201132#p201126 2] This is easily fixable in the data by changing transparent layers to asphalt, but it involves a manual intervention in each airport and sending the data back to Robin. And actually, there is not anything wrong with the original data. Other airports such as LFLR do take advantage of transparent taxiways.
:: I am working on a true priority stack for genapt ( while bringing the design to match tg-construct ). Transparent pavement should work just like X-Plane, but the orthographic images are not.--[[User:Psadro gm|Psadro gm]] ([[User talk:Psadro gm|talk]]) 18:50, 1 March 2014 (UTC)

== Fixed bugs ==
* Near EHAM there is a pylon under terrain [http://uppix.net/7rFkTR.jpg see this picture]
* Glacier landcover is missing, leading to some holes in high moutains, as seen in Switzerland (SW [http://mapserver.flightgear.org/map/?lon=8.12304&lat=46.07741&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF LSMM]), Austria ([http://mapserver.flightgear.org/map/?lon=11.3527&lat=47.25782&zoom=10&layers=B00000000000FTFFTFFTFFFFFFFF south of LOWI]) and Northern Norway (i.e. [http://mapserver.flightgear.org/map/?lon=14.210&lat=65.974&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF near ENMS]);
* Triangle winding appears inconsistent - especially when a vertex is shared by 4+ edges. Issue can be visualized here: [https://dl.dropboxusercontent.com/u/29968727/fgfs-screen-116.png messed up binormals and tangents] This may be the root cause of the urban shader issue - reported by i4dnf. Issue understood - Winding is not the issue, duplicate nodes per triangle (zero area triangles) are possible when converting the CGAL exact triangle back to nodes using double floats.

== Features enhancement ==
# Enhance landcover data for the rest of the world (OSM? vectorize US-American NLCD2006?) and add more custom scenery and fixes;
# Complete CORINE coverage, fix overlaps in CLC2000 and merge with CLC2006;
# Use latest ViewFinderPanoramas DEM's;
# Find a new svn hosting solution;
# Compute the next terrain with textures-lines option (requires pavement atlas - single texture for all road / rail / streams ) to keep framerate under control;
# Add some more OSM data (secondary...);
# Descent airports priority below roads, so roads and railroads can be shown over airports; have a proper solution for roads running over terrain classified as airfield, maybe extract administrative boundaries from apt.dat;
# Retry multi-thread;
# Enhance the "random" tree and builds placement to take OSM into account;
# .SPT file support - push Mathias' LOD ideas forward;
# Landclass border blurring - Several ideas on this - It would be really nice to be able to do it;
# OSM motorway_link (and the other _link) roads should probably have their own width. Perhaps grouped into a separate shapefile, or handled in ogr-decode - single lane is most likely;
# OSM line data simplification / preprocessing. - We've done some experimenting, and the results are promising. This should reduce the number of triangles generated. It could create longer continuous roads, which allows better control of the generated texture coordinates - so we could, theoretically, populate the roads with traffic in the future.

== Related content ==
* [[World Scenery 3.0 roadmap]]

== External link ==
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21226& FlightGear World Scenery 2.0 released] – Announcement on the official forum
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21294 FG Worldwide scenery 2.0 - Return of experience] – Forum topic dedicated to comparisons and finding anomalies

[[Category:Scenery]]

FlightGear World Scenery 2.0

2015-06-29T17:33:39Z

F-ojac: /* Known bugs and limitations */ Bug review for alfa

The '''FlightGear World Scenery 2.0''' was released during [[FSweekend]] November 2013. This new scenery reflects a major improvement over the existing default world scenery and has taken over five years to complete. A [http://mapserver.flightgear.org/map/?lon=14.56652&lat=-25.18458&zoom=1&layers=B00000000000FTFFTFFTFFFFFFFF much higher level of detail] and internal consistency characterizes this new release, in addition to the fact that it will serve as a stepping-stone for further incremental refinements.

{{caution|The new scenery is currently quite heavy and FlightGear ''will'' run slower. It ''may'' even crash FlightGear if run on systems with less than 4Gb RAM or if used with the 32 bit version of FlightGear.}}

== Source data ==
This FlightGear World Scenery was compiled from:
* ViewFinderPanoramas elevation model by Jonathan de Ferranti (using terrafit.py -x 20000 -e 10),
* VMap0 Ed.5 Worldwide Land Cover
* CORINE Land Cover 2006v16 for Europe (Source : European Union, SOeS, CORINE Land Cover, 2006 - [http://www.ifen.fr/index.php?id=88]). See [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail|here] for the correspondance between CORINE and FG textures
* Several custom land cover enhancements (to be listed here...)
* The latest airports (2013.10), maintained by Robin Peel of X-Plane
* Road, rail and rivers courses line data by OpenStreetMap [http://www.openstreetmap.org]

== Distribution ==
World Scenery 2.0 is available through the usual channels:
* [[TerraSync]]
* [http://terasaur.org/item/downloads/flightgear-v2-12/6697 Torrent]
* FlightGear main website
* [[TerraSync by hand using svn]]
* [[TerraMaster]]

== Notes ==
* All object elevation were recomputed. Thus, if some objects were defined with a bad elevation or bad offset, they may have taken a bit of elevation. Use [http://scenemodels.flightgear.org our webforms], if necessary, to fix this.
* The new scenery is currently quite heavy and hardly runs and can lead to FG crashes if run on systems with less than 4Gb RAM and if you're not using FG 64 bits. This is being worked on, however keeping a high quality scenery with a lower count of triangles is not easy. The addition of OSM roads added a lot of new triangles, hence the fps reduction.

== Known bugs and limitations ==
# Clipping of OSM roads on water showing height glitches (due to bad coast/river lines definitions and bad clipping): clip roads against landmass or add landmass where required? Should roads over bridges get removed, even in places where a 3D bridge model is missing?
# (fixed_alfa) Some z-fighting (clipper is generating the correct number of contours, but the airport hole is wound as a boundary, not a hole) and/or triangles on airports (LFRH, EDWJ (partially submerged)...);
# (fixed_alfa) Some troubles on very dense cities (such as Paris) leading to grey-white triangles on cities - see also yellow lines @LFPG;
# (unfixed_alfa) Some line issues on small airfield with LTA specific runways (LFNH, LFLI...) - the small centerlines on the runways are "floating" over the runway (20 cm to 1m), leading to some gear destructions ;-) (they didn't use lines, but surfaces that are defined as transparent and borders defined as the line type. This way you limit the number of "line features"). Probably "hot" = false would solve it. See [http://uppix.net/y1H1NB.png 1] [http://uppix.net/sMdg17.png 2] [http://uppix.net/kAXrdF.png 3] [http://uppix.net/vYuReF.png 4] [http://uppix.net/DQ4NHr.png 5]. Thanks Clément for noticing;
# Airport being located over two different tiles sometimes renders bad, leading to z-fighting (LEJR, UKKE...);
# (unfixed_alfa) On sharp cliffs, water sometimes climbs over the cliffs (see e000n40/e000n49/2958056 and [http://img809.imageshack.us/img809/2082/9n96.jpg this picture] for instance). Thanks clm76 for reporting. On the same matter, clipping between river and terrain is somewhat strange, making the river "climb" over the terrain, noticeably under bridges - probably due to the presence of the roads. See [http://img809.imageshack.us/img809/2082/9n96.jpg this example];
# Terrain and ocean z-fighting such as [http://mapserver.flightgear.org/map/?lon=12.73312&lat=55.60834&zoom=15 east of EKCH]. See tile 3155042 and EDWJ;
# The Moss Landing airport (on the coast a little bit south of KSFO) is partly submerged into the water and the airport's north end is elevated above the terrain around it. There is an area on the coast just to the north of the Moss Landing airport that is above sea level if you are up above 1000ft but is covered in water is you are on the deck. When flying over this you can see trees sticking up out of the water so the code that is placing random trees thinks this is above sea level. The old scenery didn't have either of these problems. Also if you fly over this at just the right altitude you can see this area switching back and forth between being water and land (thanks hvengel);
# On many airports where the taxiway signs are now taken from the apt.dat and put in the Terrain folder, the old signs still remain in the Object folder. See EDDF, ELLX;
# (unfixed_alfa) On ELLX there are some problems with "holes" in the pavement that flicker between grass and tarmac. I saw this (if I remember correctly) with an older development version of terragear, but this was fixed some time ago.
# (fixed_alfa) On EHAM some vertice seems to be inverted [http://uppix.net/AVUaZt.jpg see this picture]
# (fixed_alfa) At LFLI the taxiway is not correctly drawn
# The taxiway signs are not rendered correctly with transition shader set to its maximum in ALS. Quoting ThorstenB, "It occurs because you're using the terrain shader effect on something that isn't part of the terrain but in reality an artificial object placed onto the terrain. The terrain shader effect concludes correctly that a natural vertical surface cannot be anything but rock, so it replaces the default texture with the default steep gradient texture - which is rock. In my view, the proper solution would be to *not* render signs as part of the terrain but to let a different effect handle them (model-default.eff should do the trick for instance, but one could also run a lower quality terrain shader). If that is not acceptable a workaround is to declare the gradient texture for the signs as void.png as described in http://wiki.flightgear.org/Procedural_Texturing#The_gradient_texture which continues to use the terrain-specific effect but instructs the shader not to use a separate texture for steep gradients."
# sometimes some strange water width transitions, like [http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/TG%20bugs/fgfs2013-11-0822-18-06-03_zpsf3527850.jpg for the Rhein] - reported by ot-666
# (fixed_alfa) In a few airports (LEVT, LEGE are two examples), taxiways are defined in using a stack of layers: the bottom layer for the asphalt surface and the upper layer (defined as transparent) is only used to define the lines. Current tools do not support stacks of layers and the upper layer is "transparent" all the way down to the ground. See [http://i.imgur.com/AkOd5Zo.png 1] and [http://forum.flightgear.org/viewtopic.php?f=5&t=21294&p=201132#p201126 2] This is easily fixable in the data by changing transparent layers to asphalt, but it involves a manual intervention in each airport and sending the data back to Robin. And actually, there is not anything wrong with the original data. Other airports such as LFLR do take advantage of transparent taxiways.
:: I am working on a true priority stack for genapt ( while bringing the design to match tg-construct ). Transparent pavement should work just like X-Plane, but the orthographic images are not.--[[User:Psadro gm|Psadro gm]] ([[User talk:Psadro gm|talk]]) 18:50, 1 March 2014 (UTC)

== Fixed bugs ==
* Near EHAM there is a pylon under terrain [http://uppix.net/7rFkTR.jpg see this picture]
* Glacier landcover is missing, leading to some holes in high moutains, as seen in Switzerland (SW [http://mapserver.flightgear.org/map/?lon=8.12304&lat=46.07741&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF LSMM]), Austria ([http://mapserver.flightgear.org/map/?lon=11.3527&lat=47.25782&zoom=10&layers=B00000000000FTFFTFFTFFFFFFFF south of LOWI]) and Northern Norway (i.e. [http://mapserver.flightgear.org/map/?lon=14.210&lat=65.974&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF near ENMS]);
* Triangle winding appears inconsistent - especially when a vertex is shared by 4+ edges. Issue can be visualized here: [https://dl.dropboxusercontent.com/u/29968727/fgfs-screen-116.png messed up binormals and tangents] This may be the root cause of the urban shader issue - reported by i4dnf. Issue understood - Winding is not the issue, duplicate nodes per triangle (zero area triangles) are possible when converting the CGAL exact triangle back to nodes using double floats.

== Features enhancement ==
# Enhance landcover data for the rest of the world (OSM? vectorize US-American NLCD2006?) and add more custom scenery and fixes;
# Complete CORINE coverage, fix overlaps in CLC2000 and merge with CLC2006;
# Use latest ViewFinderPanoramas DEM's;
# Find a new svn hosting solution;
# Compute the next terrain with textures-lines option;
:: (requires pavement atlas - single texture for all road / rail / streams ) to keep framerate under control
# Add some more OSM data (secondary...);
# Descent airports priority below roads, so roads and railroads can be shown over airports; have a proper solution for roads running over terrain classified as airfield, maybe extract administrative boundaries from apt.dat;
# Retry multi-thread;
# Enhance the "random" tree and builds placement to take OSM into account;
# .SPT file support - push Mathias' LOD ideas forward;
# Landclass border blurring - Several ideas on this - It would be really nice to be able to do it;
# OSM motorway_link (and the other _link) roads should probably have their own width. Perhaps grouped into a separate shapefile, or handled in ogr-decode - single lane is most likely;
# OSM line data simplification / preprocessing. - We've done some experimenting, and the results are promising. This should reduce the number of triangles generated. It could create longer continuous roads, which allows better control of the generated texture coordinates - so we could, theoretically, populate the roads with traffic in the future.

== Related content ==
* [[World Scenery 3.0 roadmap]]

== External link ==
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21226& FlightGear World Scenery 2.0 released] – Announcement on the official forum
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21294 FG Worldwide scenery 2.0 - Return of experience] – Forum topic dedicated to comparisons and finding anomalies

[[Category:Scenery]]

Professional and educational FlightGear users

2015-02-15T19:52:44Z

F-ojac: /* Europe */

[[FlightGear]] is used by dozens of organisations, companies and universities all over the world.

== Companies ==
* '''Aeronautical Development Agency''', Bangalore India. FlightGear is used as as the image generator for a flight simulation facility for piloted evaluation of ski-jump launch and arrested recovery of a fighter aircraft from an aircraft carrier.
* '''Veridian Engineering Division''', Buffalo, NY. FlightGear is used for the scenery and out-the-window view for the Genesis 3000 flight simulator.
* '''MathWorks''' provides the [http://www.mathworks.com/access/helpdesk/help/toolbox/aeroblks/ Aerospace Blockset] libraries for interfacing FlightGear to their Simulink software.
* '''NASA/Ames Human Centered System Lab''' - 737NG full scale cockpit simulator developed by [http://www.lfstech.com LFS Technologies]. FlightGear provides visuals for four large screen wrap around displays, improved turbo-fan math models, detailed fuel system models, and extendable network interface to cockpit displays and electronics. <ref>[http://human-factors.arc.nasa.gov/ihi/hcsl/publications.html Human Centered System Labs], NASA</ref>
* FlightGear was used by '''Pragolet s.r.o.''' in a motion platform based flight simulator of light and ultra-light sports aircraft. <ref>{{cite web |url=http://www.pragolet.cz/clanky/flight_simulator_of_light_and_ultralight_aircraft.html |title=Simulator of a Light and Ultra-Light Sport Aircraft |last=Thöndel |first=Evžen |date=29 January 2009 |publisher=Pragolet }}</ref>
* '''ATC Flight Simulator Company''' builds FAA approved flight simulators, that use FlightGear for the visuals.<ref>{{cite web |url=http://www.atcflightsim.com/ |title=ATC Flight Simulator }}</ref>
* '''ActiveFly''' has a worldwide unique paragliding simulator. FlightGear is used to provide the visuals. "In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated"<ref>[http://www.activefly.com ActiveFly.com]</ref>
** [http://www.youtube.com/watch?v=YFcHebPaiEs Video] (YouTube)
* FlightGear was used to give a 3D visualiziation of a simulation by '''Robert Heffley Engineering'''. The simulation was used to examine the use of a Task-Pilot-Vehicle (TPV) model as a tool for flight simulator math model development.<ref>{{cite web |url=http://pdf.aiaa.org/getfile.cfm?urlX=6%3A7I%276D%26X%5BRW%2CS%20CIP4S%5EQ%3AO%224ZT%27%5FP%20%20%0A&urla=%26%2AR%28%27%230%2AC%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urld=%28%2A%22P%26%22%406CTA%20%20%0A&urle=%28%2A%22H%23%230%22DU1X%20%0A |title=Use of a Task-Pilot-Vehicle (TPV) Model as a Tool for Flight Simulator Math Model Development |date=2-5 August 2010 |author=Heffley R.K. |publisher=American Institute of Aeronautics and Astronautics |acessdate=16 August 2012 }}</ref>
* Dutch roadable autogyro manufacturer '''PAL-V Europe NV''' uses FlightGear to provide the visuals and terrain data for their simulator. The simulator is currently used to prepare the test pilot and evaluate design options, but may be used to train customers in the future.<ref>{{cite web |url=http://pal-v.com/licenses/the-pal-v-simulator/ |title=The PAL-V simulator}}</ref>
* The '''Max Planck Institute for Biological Cybernetics''' of Germany uses FlightGear in several simulation environments:
** HeliLab<ref>{{cite web |url=http://www.cyberneum.de/de/forschungseinrichtungen/helilab.html |title=HeliLab (Tiled Display)}}</ref>
** MPI CyberMotion Simulator <ref>{{cite web |url=http://www.cyberneum.de/de/labore-forschung/cmslab.html |title=Der MPI-CyberMotion-Simulator}}</ref>
* The West Virginia based '''Institute for Scientific Research''' used FlightGear to perform simulated flight testing of the avionics and control system of a small autonomous UAV.<ref>{{cite web |url=ftp://ftp.uni-duisburg.de/pub/FlightGear/Docs/AIAA-2005-7083.pdf |title=Simulated Flight Testing of an Autonomous Unmanned Aerial Vehicle Using FlightGear |date=September 2005 |author=Eric F. Sorton, Sonny Hammaker }}</ref>

=== ARINC ===
Todd Moyer of Aeronautical Radio, Incorporated (ARINC) used FlightGear as part of an effort to test and evaluate Flight Management Computer avionics and the corresponding ground systems. Certain capabilities of the Flight Management Computer are only available when airborne, which is determined by the FMC according to data it receives from GPS and INS sensors.

They wrote additional software that translates the NMEA output of FlightGear (including latitude, longitude, and altitude) into the ARINC 429 data words used by GPS and INS sensors. These data words are fed to the Flight Management Computer. the position information from FlightGear is realistic enough to convince the FMC that it is actually airborne, and allows ARINC to test entire `flights' with the avionics.

=== RWTH Aachen research simulator ===
The '''Institute of Aerospace Engineering''' at the RWTH Aachen is using FlightGear to drive the cockpit and the visuals of a general aviation simulator for training and research purpose. Micro Air Vehicles are being implemented by MATLAB/Simulink flight dynamics models; all I/O-related tasks, be they required by FDM, controls or instruments, are connected over network, using FlightGear native interfaces. <ref>http://www.dynamik.rwth-aachen.de/English/Simulators</ref>

=== Endless Runway Project ===
The '''Endless Runway Project''' is a consortium of aerospace instutes from France, Germany, the Netherlands, Poland and Spain. "The fundamental principle of The Endless Runway is that the aircraft take-off and land on a large circular structure. This will allow for the unique characteristic that the runway can be used in any wind direction, thus making the runway independent of the direction of the wind and therefore also the airport capacity independent of the wind direction."<ref>{{Cite web |url=http://endlessrunway-project.eu/downloads/d3.2-aircraft-aspects.pdf |title=Aircraft aspects of the Endless Runway |date=30 September 2013 |accessdate=16 January 2014}}</ref>

FlightGear and JSBSim were extensively used to simulate the landing and take-off performance of large aircraft on a circular runway. By using FlightGear, the consortium was able to select the radius, width and curvature of the runway.

More information and documents can be found at [http://endlessrunway-project.eu endlessrunway-project.eu]

== Universities ==
=== Africa ===
* The '''Minia University''' in Egypt developed a virtual lab with MATLAB and FlightGear. "It can be used easily by students to study and visualize classical control principles using FlightGear and MATLAB GUI with an attractive case study of a flight control system."<ref>{{cite web |url=http://www.researchgate.net/publication/236174210_automatic_control_education_using_flight_gear_and_matlab_based_virtual_lab/file/3deec5245860723ce4.pdf |title=Automatic control education using FlightGear and MATLAB based virtual lab |date=May 2012 }}</ref>

=== Asia ===
* The Department of Aircraft and Aeroengine from the Chinese '''Air Force Engineering University''' conducted a study on a new airworthiness compliance verification method based on pilot-aircraft-environment complex system simulation.<ref>{{Cite web |url=http://ac.els-cdn.com/S1000936111604342/1-s2.0-S1000936111604342-main.pdf?_tid=d3518780-834d-11e2-ba1b-00000aab0f26&acdnat=1362238285_cf85b59c1b58215e2a1559b6f42867aa |title=Airworthiness Compliance Verification Method Based on Simulation of Complex System |date=12 January 2012 |author=XU Haojun, LIU Dongliang, XUE Yuan, ZHOU Li, MIN Guilong |publisher=Chinese Journal of Aeronautics}}</ref>
* The Malaysian '''Universiti Teknologi Malaysia''' uses FlightGear for several projects.<ref>http://www.youtube.com/user/isfarazi</ref>
* The '''Nanjing University of Aeronautics and Astronautics''' in China made a 3D surface movement simulation system for [http://en.wikipedia.org/wiki/Advanced_Surface_Movement_Guidance_and_Control_System A-SMGCS] with FlightGear. The system displays ADS-B data in FlightGear through the multiplayer system and accurately predicts the aircraft's and/or vehicle's attitude (this is absent in ADS-B).<ref>{{cite web |url=http://pub.chinasciencejournal.com/article/getArticle.action?articleId=31183 |title=3D simulation of A-SMGCS surface movement based on FlightGear |date=16 May 2012 }}</ref>
* FlightGear was interfaced to MATLAB by the '''Indian Institute of Technology''' to develop a Vision-in-the-Loop Simulation facility for UAV landings.<ref>{{Cite web |url=http://www.ifac-papersonline.net/Detailed/64832.html |title=Vision Based Alignment to Runway During Approach for Landing of Fixed Wing UAVs |author=Marianandam, Peter Arun; Ghose, Debasish |date=2014}}</ref>
* The Chinese '''Shenyang Institute of Automation'''established a simulation system based on FlightGear and Matlab to validate a path planning method based on linear programming. The simulation results demonstrate the effectiveness and efficiency of this approach and the real flight test is under development.<ref>{{Cite web |url=http://ojs.unsysdigital.com/index.php/just/article/view/2 |title=LP Based Path Planning for Autonomous Landing of An Unmanned Helicopter on A Moving Platform |author=Chong Wu, Juntong Qi, Dalei Song, Jianda Han |date=24 May 2013 |publisher=Journal of Unmanned System Technology}}</ref>

=== Europe ===
* The '''University of Naples''', Italy used FlightGear in a six degrees of freedom (6dof) motion simulator, serving as a research and training tool.<ref>{{cite web |url=http://wpage.unina.it/agodemar/DSV-DQV/AIAA_MST_2007_DeMarco_Coiro_Nicolosi_paper.pdf |title=A 6DOF Flight Simulation Environment for General Aviation Aircraft with Control Loading Reproduction |last=Coiro |first=Domenico P. |coauthors=De Marco, Agostino; Nicolosi, Fabrizio |date=2007 }}</ref>
* The Intelligent Robotics Group at the '''University of Wales''', Aberystwyth, UK is using FlightGear as part of their aerobot research<ref>[http://users.aber.ac.uk/dpb/aerobots.html Aerobot Research], Dave Barne</ref> to design aerial vehicles that can operate in the atmosphere of other planets.
* '''Delft University of Technology''', the Netherlands
** FlightGear was used for the ICE project. The goal was to design, test, and evaluate computational techniques that can be used in the development of intelligent situation-aware crew assistance systems. Using methods from artificial intelligence, ICE focused primarily on the data fusion, data processing and reasoning part of these systems. <ref>{{cite web |url=http://www.kbs.twi.tudelft.nl/Research/Projects/ICE/index.html |title=The Intelligent Cockpit Environment (ICE) Project |last=Ehlert |first=Patrick |date=18 January 2005 |publisher=TU Delft }}</ref><ref>{{cite web |url=http://mmi.tudelft.nl/pub/patrick/Ehlert.P.A.M-GAMEON2002.pdf |title=Recognising situations in a flight simulator environment |date=November 2002 |author=Ehlert P.A.M., Mouthaan Q.M., Rothkrantz L.J.M. |accessdate=18 April 2012 |publisher=SCS Publishing House }}</ref><ref>{{cite web |url=http://www.kbs.twi.tudelft.nl/People/Students/D.Dragos/back/ice/index.htm |title=The ICE Project |author=Datcu Dragos |date=January 2003 |accessdate=8 May 2012 }}</ref>
** FlightGear is often used to provide the visuals on [http://www.lr.tudelft.nl/en/cooperation/facilities/simona/the-simona-research-simulator/ SIMONA], a 6-DOF research flight simulator.
* The German based '''Hamburg University of Applied Sciences''' used JSBSim and FlightGear to evaluate the handling qualities of a box wing aircraft.<ref>{{cite web |url=http://www.fzt.haw-hamburg.de/pers/Scholz/Airport2030/Airport2030_PUB_DLRK_12-09-10_Caja.pdf |title=Box Wing Flight Dynamics in the Stage of Conceptual Aircraft Design |author=Caja R., Scholz D. |date=23 November 2012}}</ref>
* For studentproject Daedalus, the Technical University of München uses FlightGear to optimize the flight characteristics of a zeppelin as well to simulate its performance. Another goal is to simulate prerecorded flights from a real model for further analysis. <ref>{{cite web |url=http://www.daedalus.ei.tum.de/index.php/de/mach-mit-mm |title=Mach mit ! - daedalus}}</ref>
* The '''Czech Technical University in Prague''' is working on a full motion simulator to do research on situation awareness. They're using FlightGear for the visuals. A video of the simulator can be seen [http://www.youtube.com/watch?v=d8SQa9_el8k&feature=autoshare at YouTube]. More info at http://measure.feld.cvut.cz/en/cast
* '''French Aerospace Lab (ONERA)''' and '''University of Toulouse''', France (2004). A thesis student Frédéric Dehais has used FlightGear and developed a cognitive counter-measures experimental environment (p.119 and following) to show the pilot/ATC scheme could be formalized and enhanced to avoid cognitive perturbation. Use of Atlas and Onera Messenger. Over 22 real-life pilots have been testing this environment.<ref>{{fr}} {{cite web |url=http://oatao.univ-toulouse.fr/2137/1/Dehais_2137.pdf |title=Modélisation des conflits dans l’activité de pilotage |first=Frédéric |last=Dehais |publisher=University of Toulouse |date=21 June 2004}}</ref>
* '''Pázmány Péter Catholic University''' and the '''Hungarian Academy of Sciences''' developed a collision avoidance system for UAVs using visual detection. The system was simulated with FlightGear serving the visuals.<ref>{{cite web |url=http://www.analogic.sztaki.hu/publications/UAV_Collision_avoidance.pdf |title=Collision avoidance for UAV using visual detection }}</ref>
* The '''University of Sheffield''', England, modeled and simulated a small UAV in FlightGear and JSBSim. The report describes the whole process of creating an UAV for use in FlightGear.<ref>{{Cite web |url=http://www.dcs.shef.ac.uk/intranet/teaching/public/projects/archive/msc2006/pdf/acq05taa.pdf |title=Modelling and Autonomous Flight Simulation of a Small Unmanned Aerial Vehicle |date=August 2006}}</ref>
* A MOOC on aerodynamics made by the French School '''Supaéro''' uses FlightGear.<ref>{{Cite web | url=https://www.france-universite-numerique-mooc.fr/courses/isaesupaero/25001/Trimestre_4_2014/about | title=Aerodynamics MOOC using FlightGear|date=February 2015}}</ref>

=== North-America ===
* '''University of Illinois''' at Urbana Champaign. FlightGear is providing a platform for icing research for the Smart Icing Systems Project. <ref>http://www.aae.uiuc.edu/sis/mainpapers.html</ref>
* '''Simon Fraser University''', British Columbia Canada. Portions of FlightGear were used in simulation to develop the needed control algorithms for an autonomous aerial vehicle.
* '''Iowa State University'''. A senior project intended to retrofit some older sim hardware with FlightGear based software.
* '''University of Minnesota''' - Human Factors Research Lab. FlightGear brings new life to an old Agwagon single seat, single engine simulator.
* FlightGear is being used as the basic framework to provide the UTC Challenger Center (and hopefully other centers in the future) a low cost virtual reality computer simulation in the '''University of Tennessee''' at Chattanooga. Our simulation is using flightgear and JSBSim, specifically the shuttle module, to develop a shuttle landing simulator. Currently, we are trying to get to the point of at least contributing instructions on how to interface our virtual reality hardware with Flightgear back to the OS community.<ref>{{cite web |url=http://www.flightgear.org/Projects/utc.html |title=University of Tennessee at Chattanooga |publisher=FlightGear |first=Dawn |last=Ellis |accessdate=18 April 2012}}</ref>
* '''Department of Aerospace Engineering at The Pennsylvania State University''' used FlightGear primarly for its graphics engine, in advanced research programs in the areas of flight control design, advanced rotorcraft flight dynamics modeling, and near real-time acoustics simulation.<ref>{{cite web |url=http://www.fkm.utm.my/ftp/pub/OSS/Win32/FlightGear/paper_PSU_2004AHS.pdf |title=A Multi-Disciplinary Rotorcraft Simulation Facility Composed of Commodity Components and Open Source Software |publisher=Department of Aerospace Engineering, The Pennsylvania State University }}</ref>
* A team of '''Northeastern University''' (Boston, USA) engineering students has developed a system that allows a pilot to fly a simulated airplane in FlightGear, using nothing more than his or her brainwaves.<ref>{{cite web |url=http://www.northeastern.edu/news/stories/2011/05/braincontrol.html |title=A brainy innovation takes flight |publisher=Northeastern University |date=31 May 2011 }}</ref>
* '''Arizona State University''' (USA) used a combination of engineering programmas (among which FlightGear) in its aerospace engineering program. The faculty shifted how they were teaching to put less focus on theory and more emphasis on simulation and visualization through the immediate use of engineering software. Students used those programms within [[MATLAB]].<ref>[http://campustechnology.com/Articles/2011/08/23/Arizona-State-Tries-Practice-over-Theory-in-Engineering-Education.aspx Arizona State Tries Practice over Theory in Engineering Education], Campus Technology</ref>
* A project by the '''University of Montreal''' and the '''University of Toulouse''' used FlightGear to visualize the effect of an active freedback system for pilot guidance assistance.<ref>{{cite web |url=http://pdf.aiaa.org/getfile.cfm?urlX=6%3A7I%276D%26X%5BRO%23S%20%27MP4S%5EQ%3AG%224%2A%28%21%5F%40%20%20%0A&urla=%26%2AR%28%27%230%2AC%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urld=%28%2A%22P%26%22%406BUQ8%20%0A&urle=%28%2A%22H%23%230%22DU1X%20%0A |title=Preliminary Study of an Active Feedback System for Aircraft Guidance |date=13-16 August 2012 |author=Latorre-Costa P., Defay F., Saussi�é D. |publisher=American Institute of Aeronautics and Astronautics |accessdate=16 August 2012 }}</ref>
* The Center for Coastal & Ocean Mapping/Joint Hydrographic Center at the '''University of New Hampshire''' set up a ship simulator using FlightGear for the visuals.<ref>{{cite web |url=http://ccom.unh.edu/vislab/projects/simulator.html |title=Spatially Aware Hand-held Devices and the Boat Simulator |accessdate=20 October 2012 }}</ref>
* The '''University of Michigan''' used FlightGear to validate PID autopilot for unmanned aerial vehicles.<ref>{{Cite web |url=http://www-personal.umich.edu/~duncanlm/Miller_Duncan_AIAA_RegionIII_2011_Autolab.pdf | title=Autonomous Vehicle Laboratory for Sense and Avoid Research and Hardware-in-the-Loop Simulations |publisher=American Institute of Aeronautics and Astronautics |author=Duncan Miller |date=2011 |format=pdf}}</ref>
* FlightGear was used by the '''University of Toronto Institute for Aerospace Studies''' to simulate [[UTIAS Ornithopter No.1|their first ornithopter]] (engine powered).<ref>{{Cite web |url=http://www.ornithopter.net/MediaGallery/flightgear_e.html |title=Flying the Ornithopter in FlightGear Flight Simulator |author=Project Ornithopter |date=2006 |format=html }}</ref> In 2010 the team made aviation history when their second ornithopter became the first human-powered ornithopter to make a sustained flight.<ref>{{Cite web |url=http://media.utoronto.ca/media-releases/new-media-technology/human-powered-ornithopter-becomes-first-ever-to-achieve-sustained-flight/ |title=Human-powered ornithopter becomes first ever to achieve sustained flight |publisher=University of Toronto |date=22 September 2010 }}</ref>
* '''Purdue University''', Indiana visualized scenarios involving cyber attacks in FlightGear to demonstrate the vulnerabilities of current UAV autopilot systems.<ref>{{cite web |url=http://www.syprisresearch.com/Images/secure-control-systems/AIAA-Infotech_Threats-and-Vulnerabilities-Analysis.pdf |title=Cyber Attack Vulnerabilities Analysis for Unmanned Aerial Vehicles}}</ref>
* A thesis at the '''University of Arizona''' involved using FlightGear to enhance the ArduPilot autopilot of an UAV to detect and capitalize upon rising air.<ref>{{Cite web |url=http://arizona.openrepository.com/arizona/handle/10150/297776 |title=Thermal Energy Extraction Methods for UAV Gliders |author=Umashankar, Rohit |date=30 April 2013 }}</ref>

=== South-America ===
* The '''Aeronautical Engineering University''' of Argentina uses FlightGear to display the outside view of their simulator. Pictures can be seen at http://gsdv.com.ar/fotos/20110528/index.html.
* Brazilian '''Universidade Federal de Minas Gerais''' compared Microsoft Flight Simulator X to FlightGear for use in an UAV simulation. The authors concluded that, although the two sims were considerably close to each other, FlightGear is the better option for research, due to its flexible and open character and the higher frequency at which the simulation could run (independent of the visual frame rate).<ref>{{cite web |url=http://homepages.dcc.ufmg.br/~chaimo/public/SBAI09-cantoni.pdf |title=Analise Comparativa Entre Microsoft Flight Simulator E Flightgear Flight Simulator Em Testes Hardware-In-The-Loop }}</ref>

== Home built applications ==
* '''Team Viper''' built a 360 degrees roll and pitch simulator, that runs on FlightGear.<ref>{{cite web |url=http://www.the-viper.org/ |title=TheViper }}</ref>
* '''John Wojnaroski''''s 747 cockpit is a long time project.<ref>http://www.flightgear.org/Projects/747-JW/</ref>

{{Appendix|all|
* {{cite web |url=http://www.usenix.org/events/usenix04/tech/sigs/full_papers/perry/perry_html/Applications_Simulator.html |title=Applications for the Simulator |last=Perry |first=Alex }}
----
{{References||2}}
}}

[[Category:FlightGear]]

Professional and educational FlightGear users

2015-02-15T19:52:10Z

F-ojac: /* Europe */

[[FlightGear]] is used by dozens of organisations, companies and universities all over the world.

== Companies ==
* '''Aeronautical Development Agency''', Bangalore India. FlightGear is used as as the image generator for a flight simulation facility for piloted evaluation of ski-jump launch and arrested recovery of a fighter aircraft from an aircraft carrier.
* '''Veridian Engineering Division''', Buffalo, NY. FlightGear is used for the scenery and out-the-window view for the Genesis 3000 flight simulator.
* '''MathWorks''' provides the [http://www.mathworks.com/access/helpdesk/help/toolbox/aeroblks/ Aerospace Blockset] libraries for interfacing FlightGear to their Simulink software.
* '''NASA/Ames Human Centered System Lab''' - 737NG full scale cockpit simulator developed by [http://www.lfstech.com LFS Technologies]. FlightGear provides visuals for four large screen wrap around displays, improved turbo-fan math models, detailed fuel system models, and extendable network interface to cockpit displays and electronics. <ref>[http://human-factors.arc.nasa.gov/ihi/hcsl/publications.html Human Centered System Labs], NASA</ref>
* FlightGear was used by '''Pragolet s.r.o.''' in a motion platform based flight simulator of light and ultra-light sports aircraft. <ref>{{cite web |url=http://www.pragolet.cz/clanky/flight_simulator_of_light_and_ultralight_aircraft.html |title=Simulator of a Light and Ultra-Light Sport Aircraft |last=Thöndel |first=Evžen |date=29 January 2009 |publisher=Pragolet }}</ref>
* '''ATC Flight Simulator Company''' builds FAA approved flight simulators, that use FlightGear for the visuals.<ref>{{cite web |url=http://www.atcflightsim.com/ |title=ATC Flight Simulator }}</ref>
* '''ActiveFly''' has a worldwide unique paragliding simulator. FlightGear is used to provide the visuals. "In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated"<ref>[http://www.activefly.com ActiveFly.com]</ref>
** [http://www.youtube.com/watch?v=YFcHebPaiEs Video] (YouTube)
* FlightGear was used to give a 3D visualiziation of a simulation by '''Robert Heffley Engineering'''. The simulation was used to examine the use of a Task-Pilot-Vehicle (TPV) model as a tool for flight simulator math model development.<ref>{{cite web |url=http://pdf.aiaa.org/getfile.cfm?urlX=6%3A7I%276D%26X%5BRW%2CS%20CIP4S%5EQ%3AO%224ZT%27%5FP%20%20%0A&urla=%26%2AR%28%27%230%2AC%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urld=%28%2A%22P%26%22%406CTA%20%20%0A&urle=%28%2A%22H%23%230%22DU1X%20%0A |title=Use of a Task-Pilot-Vehicle (TPV) Model as a Tool for Flight Simulator Math Model Development |date=2-5 August 2010 |author=Heffley R.K. |publisher=American Institute of Aeronautics and Astronautics |acessdate=16 August 2012 }}</ref>
* Dutch roadable autogyro manufacturer '''PAL-V Europe NV''' uses FlightGear to provide the visuals and terrain data for their simulator. The simulator is currently used to prepare the test pilot and evaluate design options, but may be used to train customers in the future.<ref>{{cite web |url=http://pal-v.com/licenses/the-pal-v-simulator/ |title=The PAL-V simulator}}</ref>
* The '''Max Planck Institute for Biological Cybernetics''' of Germany uses FlightGear in several simulation environments:
** HeliLab<ref>{{cite web |url=http://www.cyberneum.de/de/forschungseinrichtungen/helilab.html |title=HeliLab (Tiled Display)}}</ref>
** MPI CyberMotion Simulator <ref>{{cite web |url=http://www.cyberneum.de/de/labore-forschung/cmslab.html |title=Der MPI-CyberMotion-Simulator}}</ref>
* The West Virginia based '''Institute for Scientific Research''' used FlightGear to perform simulated flight testing of the avionics and control system of a small autonomous UAV.<ref>{{cite web |url=ftp://ftp.uni-duisburg.de/pub/FlightGear/Docs/AIAA-2005-7083.pdf |title=Simulated Flight Testing of an Autonomous Unmanned Aerial Vehicle Using FlightGear |date=September 2005 |author=Eric F. Sorton, Sonny Hammaker }}</ref>

=== ARINC ===
Todd Moyer of Aeronautical Radio, Incorporated (ARINC) used FlightGear as part of an effort to test and evaluate Flight Management Computer avionics and the corresponding ground systems. Certain capabilities of the Flight Management Computer are only available when airborne, which is determined by the FMC according to data it receives from GPS and INS sensors.

They wrote additional software that translates the NMEA output of FlightGear (including latitude, longitude, and altitude) into the ARINC 429 data words used by GPS and INS sensors. These data words are fed to the Flight Management Computer. the position information from FlightGear is realistic enough to convince the FMC that it is actually airborne, and allows ARINC to test entire `flights' with the avionics.

=== RWTH Aachen research simulator ===
The '''Institute of Aerospace Engineering''' at the RWTH Aachen is using FlightGear to drive the cockpit and the visuals of a general aviation simulator for training and research purpose. Micro Air Vehicles are being implemented by MATLAB/Simulink flight dynamics models; all I/O-related tasks, be they required by FDM, controls or instruments, are connected over network, using FlightGear native interfaces. <ref>http://www.dynamik.rwth-aachen.de/English/Simulators</ref>

=== Endless Runway Project ===
The '''Endless Runway Project''' is a consortium of aerospace instutes from France, Germany, the Netherlands, Poland and Spain. "The fundamental principle of The Endless Runway is that the aircraft take-off and land on a large circular structure. This will allow for the unique characteristic that the runway can be used in any wind direction, thus making the runway independent of the direction of the wind and therefore also the airport capacity independent of the wind direction."<ref>{{Cite web |url=http://endlessrunway-project.eu/downloads/d3.2-aircraft-aspects.pdf |title=Aircraft aspects of the Endless Runway |date=30 September 2013 |accessdate=16 January 2014}}</ref>

FlightGear and JSBSim were extensively used to simulate the landing and take-off performance of large aircraft on a circular runway. By using FlightGear, the consortium was able to select the radius, width and curvature of the runway.

More information and documents can be found at [http://endlessrunway-project.eu endlessrunway-project.eu]

== Universities ==
=== Africa ===
* The '''Minia University''' in Egypt developed a virtual lab with MATLAB and FlightGear. "It can be used easily by students to study and visualize classical control principles using FlightGear and MATLAB GUI with an attractive case study of a flight control system."<ref>{{cite web |url=http://www.researchgate.net/publication/236174210_automatic_control_education_using_flight_gear_and_matlab_based_virtual_lab/file/3deec5245860723ce4.pdf |title=Automatic control education using FlightGear and MATLAB based virtual lab |date=May 2012 }}</ref>

=== Asia ===
* The Department of Aircraft and Aeroengine from the Chinese '''Air Force Engineering University''' conducted a study on a new airworthiness compliance verification method based on pilot-aircraft-environment complex system simulation.<ref>{{Cite web |url=http://ac.els-cdn.com/S1000936111604342/1-s2.0-S1000936111604342-main.pdf?_tid=d3518780-834d-11e2-ba1b-00000aab0f26&acdnat=1362238285_cf85b59c1b58215e2a1559b6f42867aa |title=Airworthiness Compliance Verification Method Based on Simulation of Complex System |date=12 January 2012 |author=XU Haojun, LIU Dongliang, XUE Yuan, ZHOU Li, MIN Guilong |publisher=Chinese Journal of Aeronautics}}</ref>
* The Malaysian '''Universiti Teknologi Malaysia''' uses FlightGear for several projects.<ref>http://www.youtube.com/user/isfarazi</ref>
* The '''Nanjing University of Aeronautics and Astronautics''' in China made a 3D surface movement simulation system for [http://en.wikipedia.org/wiki/Advanced_Surface_Movement_Guidance_and_Control_System A-SMGCS] with FlightGear. The system displays ADS-B data in FlightGear through the multiplayer system and accurately predicts the aircraft's and/or vehicle's attitude (this is absent in ADS-B).<ref>{{cite web |url=http://pub.chinasciencejournal.com/article/getArticle.action?articleId=31183 |title=3D simulation of A-SMGCS surface movement based on FlightGear |date=16 May 2012 }}</ref>
* FlightGear was interfaced to MATLAB by the '''Indian Institute of Technology''' to develop a Vision-in-the-Loop Simulation facility for UAV landings.<ref>{{Cite web |url=http://www.ifac-papersonline.net/Detailed/64832.html |title=Vision Based Alignment to Runway During Approach for Landing of Fixed Wing UAVs |author=Marianandam, Peter Arun; Ghose, Debasish |date=2014}}</ref>
* The Chinese '''Shenyang Institute of Automation'''established a simulation system based on FlightGear and Matlab to validate a path planning method based on linear programming. The simulation results demonstrate the effectiveness and efficiency of this approach and the real flight test is under development.<ref>{{Cite web |url=http://ojs.unsysdigital.com/index.php/just/article/view/2 |title=LP Based Path Planning for Autonomous Landing of An Unmanned Helicopter on A Moving Platform |author=Chong Wu, Juntong Qi, Dalei Song, Jianda Han |date=24 May 2013 |publisher=Journal of Unmanned System Technology}}</ref>

=== Europe ===
* The '''University of Naples''', Italy used FlightGear in a six degrees of freedom (6dof) motion simulator, serving as a research and training tool.<ref>{{cite web |url=http://wpage.unina.it/agodemar/DSV-DQV/AIAA_MST_2007_DeMarco_Coiro_Nicolosi_paper.pdf |title=A 6DOF Flight Simulation Environment for General Aviation Aircraft with Control Loading Reproduction |last=Coiro |first=Domenico P. |coauthors=De Marco, Agostino; Nicolosi, Fabrizio |date=2007 }}</ref>
* The Intelligent Robotics Group at the '''University of Wales''', Aberystwyth, UK is using FlightGear as part of their aerobot research<ref>[http://users.aber.ac.uk/dpb/aerobots.html Aerobot Research], Dave Barne</ref> to design aerial vehicles that can operate in the atmosphere of other planets.
* '''Delft University of Technology''', the Netherlands
** FlightGear was used for the ICE project. The goal was to design, test, and evaluate computational techniques that can be used in the development of intelligent situation-aware crew assistance systems. Using methods from artificial intelligence, ICE focused primarily on the data fusion, data processing and reasoning part of these systems. <ref>{{cite web |url=http://www.kbs.twi.tudelft.nl/Research/Projects/ICE/index.html |title=The Intelligent Cockpit Environment (ICE) Project |last=Ehlert |first=Patrick |date=18 January 2005 |publisher=TU Delft }}</ref><ref>{{cite web |url=http://mmi.tudelft.nl/pub/patrick/Ehlert.P.A.M-GAMEON2002.pdf |title=Recognising situations in a flight simulator environment |date=November 2002 |author=Ehlert P.A.M., Mouthaan Q.M., Rothkrantz L.J.M. |accessdate=18 April 2012 |publisher=SCS Publishing House }}</ref><ref>{{cite web |url=http://www.kbs.twi.tudelft.nl/People/Students/D.Dragos/back/ice/index.htm |title=The ICE Project |author=Datcu Dragos |date=January 2003 |accessdate=8 May 2012 }}</ref>
** FlightGear is often used to provide the visuals on [http://www.lr.tudelft.nl/en/cooperation/facilities/simona/the-simona-research-simulator/ SIMONA], a 6-DOF research flight simulator.
* The German based '''Hamburg University of Applied Sciences''' used JSBSim and FlightGear to evaluate the handling qualities of a box wing aircraft.<ref>{{cite web |url=http://www.fzt.haw-hamburg.de/pers/Scholz/Airport2030/Airport2030_PUB_DLRK_12-09-10_Caja.pdf |title=Box Wing Flight Dynamics in the Stage of Conceptual Aircraft Design |author=Caja R., Scholz D. |date=23 November 2012}}</ref>
* For studentproject Daedalus, the Technical University of München uses FlightGear to optimize the flight characteristics of a zeppelin as well to simulate its performance. Another goal is to simulate prerecorded flights from a real model for further analysis. <ref>{{cite web |url=http://www.daedalus.ei.tum.de/index.php/de/mach-mit-mm |title=Mach mit ! - daedalus}}</ref>
* The '''Czech Technical University in Prague''' is working on a full motion simulator to do research on situation awareness. They're using FlightGear for the visuals. A video of the simulator can be seen [http://www.youtube.com/watch?v=d8SQa9_el8k&feature=autoshare at YouTube]. More info at http://measure.feld.cvut.cz/en/cast
* '''French Aerospace Lab (ONERA)''' and '''University of Toulouse''', France (2004). A thesis student Frédéric Dehais has used FlightGear and developed a cognitive counter-measures experimental environment (p.119 and following) to show the pilot/ATC scheme could be formalized and enhanced to avoid cognitive perturbation. Use of Atlas and Onera Messenger. Over 22 real-life pilots have been testing this environment.<ref>{{fr}} {{cite web |url=http://oatao.univ-toulouse.fr/2137/1/Dehais_2137.pdf |title=Modélisation des conflits dans l’activité de pilotage |first=Frédéric |last=Dehais |publisher=University of Toulouse |date=21 June 2004}}</ref>
* '''Pázmány Péter Catholic University''' and the '''Hungarian Academy of Sciences''' developed a collision avoidance system for UAVs using visual detection. The system was simulated with FlightGear serving the visuals.<ref>{{cite web |url=http://www.analogic.sztaki.hu/publications/UAV_Collision_avoidance.pdf |title=Collision avoidance for UAV using visual detection }}</ref>
* The '''University of Sheffield''', England, modeled and simulated a small UAV in FlightGear and JSBSim. The report describes the whole process of creating an UAV for use in FlightGear.<ref>{{Cite web |url=http://www.dcs.shef.ac.uk/intranet/teaching/public/projects/archive/msc2006/pdf/acq05taa.pdf |title=Modelling and Autonomous Flight Simulation of a Small Unmanned Aerial Vehicle |date=August 2006}}</ref>
* A MOOC on aerodynamics made by the French School '''Supaéro''' uses FlightGear.<ref{{Cite web | url=https://www.france-universite-numerique-mooc.fr/courses/isaesupaero/25001/Trimestre_4_2014/about | title=Aerodynamics MOOC using FlightGear|date=February 2015}}</ref>

=== North-America ===
* '''University of Illinois''' at Urbana Champaign. FlightGear is providing a platform for icing research for the Smart Icing Systems Project. <ref>http://www.aae.uiuc.edu/sis/mainpapers.html</ref>
* '''Simon Fraser University''', British Columbia Canada. Portions of FlightGear were used in simulation to develop the needed control algorithms for an autonomous aerial vehicle.
* '''Iowa State University'''. A senior project intended to retrofit some older sim hardware with FlightGear based software.
* '''University of Minnesota''' - Human Factors Research Lab. FlightGear brings new life to an old Agwagon single seat, single engine simulator.
* FlightGear is being used as the basic framework to provide the UTC Challenger Center (and hopefully other centers in the future) a low cost virtual reality computer simulation in the '''University of Tennessee''' at Chattanooga. Our simulation is using flightgear and JSBSim, specifically the shuttle module, to develop a shuttle landing simulator. Currently, we are trying to get to the point of at least contributing instructions on how to interface our virtual reality hardware with Flightgear back to the OS community.<ref>{{cite web |url=http://www.flightgear.org/Projects/utc.html |title=University of Tennessee at Chattanooga |publisher=FlightGear |first=Dawn |last=Ellis |accessdate=18 April 2012}}</ref>
* '''Department of Aerospace Engineering at The Pennsylvania State University''' used FlightGear primarly for its graphics engine, in advanced research programs in the areas of flight control design, advanced rotorcraft flight dynamics modeling, and near real-time acoustics simulation.<ref>{{cite web |url=http://www.fkm.utm.my/ftp/pub/OSS/Win32/FlightGear/paper_PSU_2004AHS.pdf |title=A Multi-Disciplinary Rotorcraft Simulation Facility Composed of Commodity Components and Open Source Software |publisher=Department of Aerospace Engineering, The Pennsylvania State University }}</ref>
* A team of '''Northeastern University''' (Boston, USA) engineering students has developed a system that allows a pilot to fly a simulated airplane in FlightGear, using nothing more than his or her brainwaves.<ref>{{cite web |url=http://www.northeastern.edu/news/stories/2011/05/braincontrol.html |title=A brainy innovation takes flight |publisher=Northeastern University |date=31 May 2011 }}</ref>
* '''Arizona State University''' (USA) used a combination of engineering programmas (among which FlightGear) in its aerospace engineering program. The faculty shifted how they were teaching to put less focus on theory and more emphasis on simulation and visualization through the immediate use of engineering software. Students used those programms within [[MATLAB]].<ref>[http://campustechnology.com/Articles/2011/08/23/Arizona-State-Tries-Practice-over-Theory-in-Engineering-Education.aspx Arizona State Tries Practice over Theory in Engineering Education], Campus Technology</ref>
* A project by the '''University of Montreal''' and the '''University of Toulouse''' used FlightGear to visualize the effect of an active freedback system for pilot guidance assistance.<ref>{{cite web |url=http://pdf.aiaa.org/getfile.cfm?urlX=6%3A7I%276D%26X%5BRO%23S%20%27MP4S%5EQ%3AG%224%2A%28%21%5F%40%20%20%0A&urla=%26%2AR%28%27%230%2AC%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urld=%28%2A%22P%26%22%406BUQ8%20%0A&urle=%28%2A%22H%23%230%22DU1X%20%0A |title=Preliminary Study of an Active Feedback System for Aircraft Guidance |date=13-16 August 2012 |author=Latorre-Costa P., Defay F., Saussi�é D. |publisher=American Institute of Aeronautics and Astronautics |accessdate=16 August 2012 }}</ref>
* The Center for Coastal & Ocean Mapping/Joint Hydrographic Center at the '''University of New Hampshire''' set up a ship simulator using FlightGear for the visuals.<ref>{{cite web |url=http://ccom.unh.edu/vislab/projects/simulator.html |title=Spatially Aware Hand-held Devices and the Boat Simulator |accessdate=20 October 2012 }}</ref>
* The '''University of Michigan''' used FlightGear to validate PID autopilot for unmanned aerial vehicles.<ref>{{Cite web |url=http://www-personal.umich.edu/~duncanlm/Miller_Duncan_AIAA_RegionIII_2011_Autolab.pdf | title=Autonomous Vehicle Laboratory for Sense and Avoid Research and Hardware-in-the-Loop Simulations |publisher=American Institute of Aeronautics and Astronautics |author=Duncan Miller |date=2011 |format=pdf}}</ref>
* FlightGear was used by the '''University of Toronto Institute for Aerospace Studies''' to simulate [[UTIAS Ornithopter No.1|their first ornithopter]] (engine powered).<ref>{{Cite web |url=http://www.ornithopter.net/MediaGallery/flightgear_e.html |title=Flying the Ornithopter in FlightGear Flight Simulator |author=Project Ornithopter |date=2006 |format=html }}</ref> In 2010 the team made aviation history when their second ornithopter became the first human-powered ornithopter to make a sustained flight.<ref>{{Cite web |url=http://media.utoronto.ca/media-releases/new-media-technology/human-powered-ornithopter-becomes-first-ever-to-achieve-sustained-flight/ |title=Human-powered ornithopter becomes first ever to achieve sustained flight |publisher=University of Toronto |date=22 September 2010 }}</ref>
* '''Purdue University''', Indiana visualized scenarios involving cyber attacks in FlightGear to demonstrate the vulnerabilities of current UAV autopilot systems.<ref>{{cite web |url=http://www.syprisresearch.com/Images/secure-control-systems/AIAA-Infotech_Threats-and-Vulnerabilities-Analysis.pdf |title=Cyber Attack Vulnerabilities Analysis for Unmanned Aerial Vehicles}}</ref>
* A thesis at the '''University of Arizona''' involved using FlightGear to enhance the ArduPilot autopilot of an UAV to detect and capitalize upon rising air.<ref>{{Cite web |url=http://arizona.openrepository.com/arizona/handle/10150/297776 |title=Thermal Energy Extraction Methods for UAV Gliders |author=Umashankar, Rohit |date=30 April 2013 }}</ref>

=== South-America ===
* The '''Aeronautical Engineering University''' of Argentina uses FlightGear to display the outside view of their simulator. Pictures can be seen at http://gsdv.com.ar/fotos/20110528/index.html.
* Brazilian '''Universidade Federal de Minas Gerais''' compared Microsoft Flight Simulator X to FlightGear for use in an UAV simulation. The authors concluded that, although the two sims were considerably close to each other, FlightGear is the better option for research, due to its flexible and open character and the higher frequency at which the simulation could run (independent of the visual frame rate).<ref>{{cite web |url=http://homepages.dcc.ufmg.br/~chaimo/public/SBAI09-cantoni.pdf |title=Analise Comparativa Entre Microsoft Flight Simulator E Flightgear Flight Simulator Em Testes Hardware-In-The-Loop }}</ref>

== Home built applications ==
* '''Team Viper''' built a 360 degrees roll and pitch simulator, that runs on FlightGear.<ref>{{cite web |url=http://www.the-viper.org/ |title=TheViper }}</ref>
* '''John Wojnaroski''''s 747 cockpit is a long time project.<ref>http://www.flightgear.org/Projects/747-JW/</ref>

{{Appendix|all|
* {{cite web |url=http://www.usenix.org/events/usenix04/tech/sigs/full_papers/perry/perry_html/Applications_Simulator.html |title=Applications for the Simulator |last=Perry |first=Alex }}
----
{{References||2}}
}}

[[Category:FlightGear]]

Howto:Add details to your airport

2014-10-22T06:51:53Z

F-ojac: /* Placing your first model */ Mmmh seems the wiki doesn't show the = key properly with the key press tag.

[[FlightGear]] has thousands of accurately positioned [[:Category:Airports|airports]], but most of them simply consist of runways and taxiways. Although a number of major international and national airports have been modelled, you may prefer to just fly from your local small airfield or nearby municipal airport. Here's how to add detail to your home base.

Let's assume you have some idea of the layout of your chosen airfield, the buildings and facilities. Use your existing resources, Google Earth to obtain several plan views and Google Image Search for as many other details as you can find. Flickr and similar websites are also useful sources of images.

Print this guide and your images and load FlightGear with the [[UFO]] situated on your airfield.

== Placing your first model ==
{{main article|Howto: Place 3D objects with the UFO}}
Stay in cockpit view. Increase the UFO altitude for a better view: {{key press|Home}} = up, {{key press|End}} = down.

Move towards the location of the first major building, terminal or hanger: {{key press|Page Up}} = speed up, {{key press|Page down}} = slow down. Use the arrow navigation keys to steer; you may prefer to use your joystick. Zoom in for a more accurate view: {{key press|X}} = zoom in, {{key press|Shift|X}} = zoom out.

Now open the list of the models you want to add to your scene: hit the {{key press|Space}} keybar. Select your first model to add: scroll down and up to view all the models. Generic buildings (and objects) are obtainable from the <tt>[[$FG ROOT]]/Models/</tt> directory.

Choose your model: leftclick on the list – or if you're unsure – click on any model for now.

Now place your model: position the mouse cursor on your chosen spot in the view and left click. The chosen model will now be visible on the ground at your airport.

You may now view other choices of model: {{key press|Ctrl|Page up}} = cycle down model List, {{key press|Ctrl|Page down}} = cycle up model List. You are able to cycle through all the model choices if you wish.

When you have decided on this first model to add to your airport you may adjust its position more exactly: hit the = key (post 3.0) or the {{key press|Tab}} (pre-3.0).
* Adjust the '''position''' of your model: click on the left/right arrow keys and/or move the sliders. The model will be moved relative to your UFO position.
* Adjustment of model '''orientation''' is usually needed: use the heading controls.
* Adjustment of model '''altitude''' above sea level may be required: best to use the altitude slider at first. Use the {{key press|Shift}} key to get a more accurate placement.

If you get it wrong hit Backspace to delete the model.

=== Placing more models ===
Move to the location of the second model to be added. Repeat selection and positioning of your next model.

=== Be Creative ===
It is possible to adapt the models to suit your own requirements. For example, sink a three storey building into the ground to make a single storey airport terminal; combine or overlap buildings to make more complex shapes; sit small buildings on larger ones for more interesting architecture.

== Saving to FlightGear ==
Save your work at regular intervals: hit {{key press|D}} and note the location now listed in your terminal/command console, for example

#w010n50/w003n51/2909017.stg

Then edit/copy (don't use {{key press|Ctrl|C}}) the objects listing also listed in your terminal/command console, an example

OBJECT_SHARED Models/Airport/hangar.ac -2.70395512 51.38404119 183.5494 0.0

Modify the .stg file: start your text editor (Gedit, NotePad etc.) and open the relevant .stg file in the appropriate <tt>[[$FG SCENERY]]/Objects</tt> folder.

2909017.stg located in the <tt>[[$FG_SCENERY]]/Objects/w010n50/w003n51</tt> folder, as shown above.

It is wise first make a back-up of the original .stg file first. Rename it to <tt>2909017.old</tt> for example.

Edit/paste the object listing from your terminal/command console to the .stg file

OBJECT_SHARED Models/Airport/hangar.ac -2.70395512 51.38404119 183.5494 0.0

If you're lucky, all subsequent changes should be made to just this .stg file. Otherwise make notes of all the .stg files to be changed.

== Placing signs ==
{{main article|Signs}}
Runway and taxiway signs are first obtained from the Models List as the <tt>[[$FG ROOT]]/Aircraft/ufo/Models/sign.ac</tt>.

Make a note of the order in which you place them.

Add the sign models to the .stg file as before (d, copy, .stg, paste) and then you need to modify the entries using Gedit or NotePad. For example, change the relevant entry in the .stg file to create a yellow sign for taxiway “A”:

OBJECT_SIGN {@Y}A -2.70283307 51.38317242 184.0008 96.0

Or change another entry to produce a yellow sign for taxiway “B”:

OBJECT_SIGN {@Y}B -2.70283307 51.38317242 184.0008 96.0

To create a red sign for runway “27-09”:

OBJECT_SIGN {@R}27-09 -2.70283307 51.38317242 184.0008 96.0

and so on.

You might also consider [[Howto:Modeling Ground Signs with Blender|adding ground signs]], if the current apt.dat format doesn't support them yet (v850 doesn't).

== Adding more detail ==
Now you know how to do it you can float around the airport in the UFO and place models wherever you wish.

Regularly hit the d-key and copy and paste the new object listings to the relevant .stg file.

Separate each type of object listings in the .stg file with comment lines to keep track of your work, eg:
## buses, trucks, vehicles and miscellaneous static objects.

== Workflow ==
You may find that it is best to build your airport in the following sequence:

# Major buildings can be found in
#* <tt>[[$FG ROOT]]/Models/Airport/</tt>
#* <tt>[[$FG ROOT]]/Models/Buildings</tt>
# Hangers listed in <tt>[[$FG ROOT]]/Models/Airport</tt>.
# Service buildings and miscellaneous buildings to be found in:
#* <tt>[[$FG ROOT]]/Models/Airport</tt>
#* <tt>[[$FG ROOT]]/Models/Commercial</tt>
#* <tt>[[$FG ROOT]]/Models/Industrial</tt>
# Fences in the Models/Boundaries list.
# Great static aircraft and services are located in
#* <tt>[[$FG ROOT]]/Models/Aircraft</tt>
#* <tt>[[$FG ROOT]]/Models/Airport</tt>
# Vehicles are in the <tt>[[$FG ROOT]]/Models/Transport</tt> list.
# Signs, as described [[#Placing signs|earlier]].
Add other details such as ISO containers at rear of buildings, buses, tankers, light aircraft.
# Red hazard lights may be added to tall structures, find them in <tt>[[$FG ROOT]]/Models/Effects/</tt>
# Radio masts, monopoles and other towers they may be lowered in height by adjusting the Altitude slider if necessary. Airports are usually flat, low scenes so any verticals help to add interest to your views.
#* <tt>[[$FG ROOT]]/Models/Communications</tt>
#* <tt>[[$FG ROOT]]/Models/Military</tt>
# Immediately outside the airport there are usually large spaces for car parking. Currently there are no 3D models of these so you will have to devise a suitable texture map for them.
# In the areas surrounding the airport you could add residential and commercial properties bearing in mind the distance and visibility of these objects.
# Usually there are some prominent tall objects within a few miles of your airport so it will be worth the effort to add replica versions of these to your scenery.
# Add trees from <tt>[[$FG ROOT]]/Models/Trees</tt>. In many parts of the world the coniferous/deciduous mix varies so you could rename the appropriate file(s) in <tt>[[$FG ROOT]]/Models/Trees</tt> and <tt>[[$FG ROOT]]/Textures/Trees</tt> to give the proportions you wish, e.g.
#* If you wish to reduce the number of coniferous trees around your airport, you have to edit the <tt>[[$FG ROOT]]/materials.xml</tt> file. Do note that this file is distributed with FlightGear and therefore changes will be lost in a next release, unless commited to [[CVS]]. It is better (but harder) to [[Howto: Create custom scenery|edit the terrain]] instead, to reflect the real area.

== Your updated airport ==
As you settle into your new home you will probably wish to adjust, delete or modify the models which, unfortunately, has to be carried out the long way by first deleting them from the .stg file and re-installing using the UFO method.

Keep an eye on frame rates and stop or back-track when you think you've reached your optimum eye-candy/framerate limit. Remember – have fun.

[[Category:Scenery enhancement|Add details to your airport]]

Osm2city.py

2014-09-30T18:27:06Z

F-ojac: /* Install */

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/Linux. It should also run on Mac OSX. Windows users, see [[Osm2city.py#Install_on_Windows|below.]]

It's at a rather early stage of development. There's no GUI, everything is controlled by an input file. But it produces realistic city layouts (after all, it uses realistic data). The whole process -- from scratch to flying in FG -- for a city the size of LOWI takes perhaps 30 min, including maybe a total of 15 min manual work.

It has been tested with Dresden, Germany (EDDC) and Innsbruck, Austria (LOWI). Both areas are now populated with about 50,000 buildings. Rendering this in FG is quite demanding. The FG process eats ~2.8GB RAM when flying in those areas, the download is ~50 MB each.

== Status 06/2014 ==
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

== Status 04/2014 ==
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]]
Following Mathias' suggestion at FS Weekend 2013, I've now changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10). That indeed gives a nice speed-up. In fact, I'm overwhelmed by what's possible now -- here's a scene looking down at LOWI from FL300 showing 60k buildings. Plain Scenery 2.0 gives 19 fps on i7 Intel HD 5000 2560x1440. With buildings framerate goes down to 14.

[[File:LOWI with OSM buidings one object per tile.jpg|thumb|Approaching LOWI, with 60k OSM buildings]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

== Status 10/2013 ==
Currently data is processed offline beforehand. Basically, it parses the OSM
xml, generates a list of building outlines, discards some based on their area,
simplifies the outlines, clusters them into ~500x500m blocks and different LODs,
then writes .ac, .xml, and .stgs. <del>OSM parsing is by far the most expensive,
easily taking 10 minutes for 50k buildings. Once that's done, the remaining parts take maybe 1 minute in total.
</del> (Some optimization gave a huge speedup).

At the moment, the code knows only the floor plans. <del>No streets</del>, no runways, no
land-use. But it'll certainly process such data in the future, and then could
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* reads buildings from OSM. Honors height and level tags, reads relations ('buildings with holes')
* reads existing .stg, won't place OSM building if there's a static model nearby
* reads pre-calculated terrain elevation: places buildings at correct elevation
* simplify/automate elevation probing by using fgelev
* LOD animation based on building height and area (see below)
* cluster a number of buildings into a single .ac files. Clusters overlap to alleviate sharp LOD borders
* complex sloped roof generation (using Olivier Teboul's implementation of the straight skeleton algorithm)
* texture manager: DB of facade/roof textures
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support (currently broken)
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* writes .ac, .xml, .stg

== Planned Features ==
(in random order)
* more complex facade generation. Currently, all sides get same texture {{not done}}
* Rembrandt lighting {{not done}}
* put a piece of matching ground texture around buildings ('garden') {{progressbar|10}}
* put shared models if/where OSM indicates so: gas stations... {{not done}}
* geometry cleanup, simplify too complex buildings {{done}}
* use residential/industrial/commercial tags/areas. ATM, all is residential. {{not done}}
* geometry cleanup, simplify too complex buildings {{done}}
* Batch processing of greater areas including downloads {{done}}
* use more LOD levels, write them to different .ac so users can easily reduce building density, therefore improve performance {{progressbar|50}}
:* put large buildings into one ac, sort/rate buildings by stand-out-ness {{done}}
:* then ship light/med/full .stg {{not done}}
* mid-term: develop this into a city-engine that procedurally generates a city based on OSM roads. {{not done}}
:* read, drape, texture roads and railways {{progressbar|70}}
:* texture road intersections {{not done}}
:* illuminate roads {{not done}}
:* procedural bridges {{progressbar|50}}
:* place shared models along roads if no OSM data available {{not done}}
* long-term: integrate into FG to do all this on the fly. {{not done}}

== LOD Scheme ==
FlightGear knows three standard LOD: bare, rough and detail. 'Bare' sets the drawing distance of the terrain, which may easily be 50 km or more. Drawing buildings 50 km out makes little sense (unless they are ''really'' tall), so we shouldn't use this level here. Of the remaining two standard levels, 'rough' is used for large and/or tall buildings, and 'detail' for smaller ones.

Osm2city can generate complex roof shapes. This increases the poly count further, and I believe it's a good idea to use another LOD 'roof' for complex roofs. Fortunately, we can change every aspect of FlightGear, and adding another LOD is easy. Use the FG command line
--prop:double:/sim/rendering/static-lod/roof=2000
to set the distance for 'roof' to 2 km. If you want to adjust it via FG's GUI, copy static-lod.xml (from osm2city's git repo) to $FGDATA/gui/dialogs.

== Ideas ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* bump map/reflection effects?
* a mode that generally uses shared models? If we find a shared models of matching floorplan, use this instead of creating a new, individual building? Will break clusters.
* a terrasync-like thing? Users get OSM buildings
(where available) on-the-fly? Might be quite costly in terms of runtime performance and bandwidth. The OSM download (buildings only!) is
~40MB for the 25x25km LOWI area.

== Install ==
* dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil

* get [https://gitorious.org/fg-radi/osm2city osm2city] from gitorious
* add the directory with osm2city modules to your [http://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH PYTHONPATH] (unless your PYTHONPATH already contains . (the dot))

* get the textures as described in the first post of the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 devel thread]. Put the folders into your osm2city folder.

* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* create elevation grid, run FG to probe elevation data
* run osm2city
* install the generated scenery

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. Copy the template params.ini to LOWI/. Edit this file, adjusting (at least) the following (check comments in params.ini):
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
=== Probe elevation ===
* probe elevation for the region in params.ini:
* Set the ELEV_MODE in params.ini
* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder
* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory
* ELEV_MODE = Fgelev
:* Set FG_ELEV to your fgelev executable
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* Run tools.py this will generate the elev.out using fgelev This can take considerable time.

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-09-28T17:25:46Z

F-ojac: Small fix

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetPap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/Linux. It should also run on Mac OSX. Windows users, see [[Osm2city.py#Install_on_Windows|below.]]

It's at a rather early stage of development. There's no GUI, everything is controlled by an input file. But it produces realistic city layouts (after all, it uses realistic data). The whole process -- from scratch to flying in FG -- for a city the size of LOWI takes perhaps 30 min, including maybe a total of 15 min manual work.

It has been tested with Dresden, Germany (EDDC) and Innsbruck, Austria (LOWI). Both areas are now populated with about 50,000 buildings. Rendering this in FG is quite demanding. The FG process eats ~2.8GB RAM when flying in those areas, the download is ~50 MB each.

== Status 06/2014 ==
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

== Status 04/2014 ==
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]]
Following Mathias' suggestion at FS Weekend 2013, I've now changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10). That indeed gives a nice speed-up. In fact, I'm overwhelmed by what's possible now -- here's a scene looking down at LOWI from FL300 showing 60k buildings. Plain Scenery 2.0 gives 19 fps on i7 Intel HD 5000 2560x1440. With buildings framerate goes down to 14.

[[File:LOWI with OSM buidings one object per tile.jpg|thumb|Approaching LOWI, with 60k OSM buildings]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

== Status 10/2013 ==
Currently data is processed offline beforehand. Basically, it parses the OSM
xml, generates a list of building outlines, discards some based on their area,
simplifies the outlines, clusters them into ~500x500m blocks and different LODs,
then writes .ac, .xml, and .stgs. <del>OSM parsing is by far the most expensive,
easily taking 10 minutes for 50k buildings. Once that's done, the remaining parts take maybe 1 minute in total.
</del> (Some optimization gave a huge speedup).

At the moment, the code knows only the floor plans. <del>No streets</del>, no runways, no
land-use. But it'll certainly process such data in the future, and then could
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* reads buildings from OSM. Honors height and level tags, reads relations ('buildings with holes')
* reads existing .stg, won't place OSM building if there's a static model nearby
* reads pre-calculated terrain elevation: places buildings at correct elevation
* simplify/automate elevation probing by using fgelev
* LOD animation based on building height and area (see below)
* cluster a number of buildings into a single .ac files. Clusters overlap to alleviate sharp LOD borders
* complex sloped roof generation (using Olivier Teboul's implementation of the straight skeleton algorithm)
* texture manager: DB of facade/roof textures
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support (currently broken)
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* writes .ac, .xml, .stg

== Planned Features ==
(in random order)
* more complex facade generation. Currently, all sides get same texture {{not done}}
* Rembrandt lighting {{not done}}
* put a piece of matching ground texture around buildings ('garden') {{progressbar|10}}
* put shared models if/where OSM indicates so: gas stations... {{not done}}
* geometry cleanup, simplify too complex buildings {{done}}
* use residential/industrial/commercial tags/areas. ATM, all is residential. {{not done}}
* geometry cleanup, simplify too complex buildings {{done}}
* Batch processing of greater areas including downloads {{done}}
* use more LOD levels, write them to different .ac so users can easily reduce building density, therefore improve performance {{progressbar|50}}
:* put large buildings into one ac, sort/rate buildings by stand-out-ness {{done}}
:* then ship light/med/full .stg {{not done}}
* mid-term: develop this into a city-engine that procedurally generates a city based on OSM roads. {{not done}}
:* read, drape, texture roads and railways {{progressbar|70}}
:* texture road intersections {{not done}}
:* illuminate roads {{not done}}
:* procedural bridges {{progressbar|30}}
:* place shared models along roads if no OSM data available {{not done}}
* long-term: integrate into FG to do all this on the fly. {{not done}}

== LOD Scheme ==
FlightGear knows three standard LOD: bare, rough and detail. 'Bare' sets the drawing distance of the terrain, which may easily be 50 km or more. Drawing buildings 50 km out makes little sense (unless they are ''really'' tall), so we shouldn't use this level here. Of the remaining two standard levels, 'rough' is used for large and/or tall buildings, and 'detail' for smaller ones.

Osm2city can generate complex roof shapes. This increases the poly count further, and I believe it's a good idea to use another LOD 'roof' for complex roofs. Fortunately, we can change every aspect of FlightGear, and adding another LOD is easy. Use the FG command line
--prop:double:/sim/rendering/static-lod/roof=2000
to set the distance for 'roof' to 2 km. If you want to adjust it via FG's GUI, copy static-lod.xml (from osm2city's git repo) to $FGDATA/gui/dialogs.

== Ideas ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* bump map/reflection effects?
* a mode that generally uses shared models? If we find a shared models of matching floorplan, use this instead of creating a new, individual building? Will break clusters.
* a terrasync-like thing? Users get OSM buildings
(where available) on-the-fly? Might be quite costly in terms of runtime performance and bandwidth. The OSM download (buildings only!) is
~40MB for the 25x25km LOWI area.

== Install ==
* dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil

* get [https://gitorious.org/fg-radi/osm2city osm2city] from gitorious
* add the directory with osm2city modules to your [http://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH PYTHONPATH] (unless your PYTHONPATH already contains . (the dot))

* get the textures as described in the first post of the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 devel thread]. Put the folders into your osm2city folder.

* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/evel.in
* Change the out variable of elev.nas to the export directory with a filename
with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* create elevation grid, run FG to probe elevation data
* run osm2city
* install the generated scenery

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. Copy the template params.ini to LOWI/. Edit this file, adjusting (at least) the following (check comments in params.ini):
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
=== Probe elevation ===
* probe elevation for the region in params.ini:
* Set the ELEV_MODE in params.ini
* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder
* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory
* ELEV_MODE = Fgelev
:* Set FG_ELEV to your fgelev executable
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* Run tools.py this will generate the elev.out using fgelev This can take considerable time.

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Switching default texture format to DDS

2014-09-13T07:30:30Z

F-ojac: /* NVIDIA proprietary driver */

The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==
However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

=== What we need you to do? ===
FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

# Open the dialog under View -> Rendering
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
# Press 'Okay' - FG will reload the terrain
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
# Change back to the texture scheme you like best
# Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphics drivers ==
=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT 640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|-
|GeForce GT 620 OEM
|331.38
|{{yes}}
|C-GGKV
|-
|GeForce GTX 650
|331.20
|{{yes}}
|dany93
|-
|GeForce 210
|304.117
|{{yes}}
|Jean-Philippe
|-
|GeForce GT 520
|332.21
|{{yes}}
|cossack90
|-
|GeForce GTX 260
|304.117
|{{yes}}
|Lann
|-
|GeForce GTS 250
|331.38
|{{yes}}
|Madbyte
|-
|GeForce GTS 450
|340.32
|{{yes}}
|chris_blues
|-
|GeForce 8600 GT
|340.32
|{{yes}}
|szpajder
|-
|GeForce GTX 460 SE
|331.38
|{{yes}}
|f-jjth
|-
|GeForce GTX 560 Ti
|319.32
|{{yes}}
|PATTEN
|-
|GeForce 8600 GT
|304.117
|{{yes}}
|attila
|-
|GeForce GTX 750 ti
|340.32
|{{yes}}
|f-toro
|-
|GeForce GT 650M
|Apple OS 10.9.4
|{{No}}
|dersh
|-
|GeForce 9800GTX
|304.117
|{{yes}}
|ctec356
|-
|GeForce GT 220
|331.38
|{{yes}}
|D-ABEK
|-
|GeForce GTX 760M
|331.38
|{{yes}}
|f-ojac
|}

=== NVIDIA open source driver (Nouveau)===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GT 630
|
|{{no}}
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]
|-
|GeForce GT 220
|
|{{no}}
|D-ABEK
|-
|}

=== Intel proprietary driver ===

=== Intel open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{n/a}}
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|{{n/a}}
|{{yes}}
|Flyhigh/saiarcot895
|-
|HD Graphics Sandy Bridge (Pentium B980)
|10.1.0
|{{no}}
|{{yes}}
|f-jjth
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|-
|AMD Radeon R9 200 Series
|14.4
|{{yes}}
|Richi
|-
|Radeon HD 4850/4870
|legacy 8.97.100.7-4
|{{yes}}
|Jano
|}

=== ATI/AMD open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|AMD Radeon HD 6770
|10.2.5
|{{no}}
|{{no}}
|Mongrol
|-
|AMD Radeon HD 7950
|10.2.1
|{{yes}}
|{{yes}}
|Saga
|-
|AMD Radeon R9 270X
|10.3~git20140805
|{{no}}
|{{no}}
|nine
|-
|AMD Radeon R9 270X
|10.3~git20140805
|{{yes}}
|{{yes}}
|nine
|}

== Sample test ==
=== DDS Test at the airport of Orio (Bergamo - Italy) ===
[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this. These are the parameters used by the startup script "run_fgrun.sh":
{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}
<code>
--airport=LIME
--aircraft=757-200-PW2040
--disable-random-objects
--enable-horizon-effect
--enable-enhanced-lighting
--enable-distance-attenuation
--enable-ai-models
--disable-ai-traffic
--disable-real-weather-fetch
--enable-clouds3d
--bpp=32
--texture-filtering=16
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4
--timeofday=noon
--enable-terrasync
--httpd=5500
--props=5501
--jpg-httpd=5502
--multiplay=out,10,,0
--multiplay=in,10,,0
--disable-fgcom
</code>

== Excerpts from the ongoing discussion ==
{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 ==
=== Legalities ===
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|t is technically incorrect to provide these s3 patent 
precompressed textures to a driver that does not announce the apropriate 
extension and since we are not allowed to code something that deompresses 
this, I think we should avoid using this compression for all the provided 
models/textures. 
 
I think of a warning that is issued from the image loader in flightgear that 
detects when these precompressed textures are seen. So even people using 
drivers that just offer this extension have a chance to see that the provided 
textures will not work for others.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

=== Portability Concerns ===
{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|And this is what I try to do now: 
Object against using these patented compression algorithms. 
I do not care for the on disk format of any image file we have. But the problem 
is that some kind of precompression that can be stored in these dds files 
cannot be used with other drivers than the closed ati and nvidia ones. 
As long as these patented compression techiques are not used, every OpenGL 
driver can use this and displays this fine. 
 
Think: Intel has the hugest marketshare in graphics today. If I remember 
right, they sell more than ati and nvidia together (*). This kind of change in 
effect rules out the majority of users as intel cannot work with these files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably 
have the same effect. So I think simply ommitting DDS is ok? 
 
Also, much more important, the comment is not about 'your video driver'. It is 
in your (Vivian) case even wrong. Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I would like to have a flightgear that is by default just running on every 
average system. Having this run faster on a special configured system with some 
better configuration options and hand tuned hardware and drivers is very fine. 
But without tuning it must at least work in an acceptable way. 
 
I have checked in a change to flightgear to make the use of the compressed 
internal formats a starttime configuration option. 
I am still interrested if we have that hangs also with texture compression 
disabled and without providing precompressed dds textures?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|this is the reason for the message. If your machine would refuse to display this you, 
developing that, would probably just say 'nice try, but it does not work' 
before you check in something. In the case it displays fine, you probably say 
'it works here, so I assume it works also for others, lets do'. 
And the message tells you, 'despite of just seeing this working on this 
current machine, it does not work for others'.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff. 
 
I am not going to discuss the patent stuff. Please search the mesa-dev archives 
for the discussion and see there why they think that the nvidia tools and 
other stuff out there cannot be used. Really - it is not that the code for that 
is too dificult or unavailable. I am not a lawyer and I cannot change this 
world - even if I would like to in this regard. 
 
I agree that techically for drivers/gpus supporting these compression formats 
it would be best to use these precompressed files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

=== Approaches ===
{{FGCquote
|Well, the default f16 does not work anymore for example. 
I have also never tried the new textures, but I assume that these also contain 
precompressed data? Also you claimed that the old texture files start to bitrot 
comared to the new ones which makes me think that the new standard should be 
the dds files. This together makes me think that the dds files should replace 
the traditional image files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|Hmm, regarding dds. 
I have to say, that not all OpenGL drivers support texture compression, and 
the models with dds files, are those that I cannot display, because of that. 
And in fact this will not happen to the open source drivers before something 
about 2020 because of patent issues. 
 
Sorry to step in this so late - probably way too late - but is there a reason 
that the on disk format must be compressed? 
The previous strategy to have on disk an format that everybody can read and to 
make the driver compress them as needed/possible is better I think? 
 
So, for me the f16 lost its livery lately - where I can live with this for the 
f16, I hope that this does not happen to flightgear as a whole ...
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-27</nowiki>
}}
}}

{{FGCquote
|Well, I hope that we can get rid of the compression. 
Can somebody with the apropriate tools convert the compressed textures to non 
compressed ones? That could still be dds, but dds without these compressions 
that produce the warning. So no problem with cubemaps in dds as long as the 
compression is not there. 
Then *everybody* is again able to use this stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I can see several approaches: 
 
* Just do not use the patented compression stuff. The precomputed mipmaps could 
probably do the job of avoiding the hangs (hopefully? to be checked?). May be 
we could lower disk space usage by providing a dds.gz or similar wrapper? 
 
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu 
in the database loader thread. This would help all textures not only the ones 
that could be converted. May be this is the most generic solution. 
 
* Implement some kind of image lookup order that knows if the compressed files 
could be handled or not. On loading an image in case of available compression 
first try to find a dds file with the same name of the original one. That 
involves some 'magic' which often leads to problems but that could at least 
work.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

{{FGCquote
|Next step is to make sure that compression is not required to avoid the hangs. 
My favorite bet would be that then the new configure option regarding texture 
compression needs to be set to none.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

=== Precomputed mipmaps ===
{{FGCquote
|Could we do dds files without compression but with precomputed mipmaps? 
 
So at next, can you try out which combination of compression/provided 
mipmaps/forced simgear compression still work fine?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|The 4. Method that I can imagine is to precompute the mipmaps in the loader. 
IIRC tests with some of the guys suffering from this problem, providing 
premipmapped but uncompressed dds files had helped to get a fluent viewer. 
The argument against providing these dds files in general was that these files 
are really huge because of not including any compression and having all the 
mipmaps. 
But that means we could at the point where the warning happens compute the 
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be 
used to do this I think (or something similar not requireing a context). This 
one is an imported version of the original glu function that is included in 
osg for running on an EGL stack which no longer provides GLU. 
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and 
scale this to the 2. mipmap and so forth. 
 
This would have the advantage that the png's do not deviate from the dds files 
over time.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I think then, computing mipmaps for any texture file on the CPU in the loader 
thread should globally improove the situation. 
Also avoiding the compression already in the files should help every use case. 
Except that the on disk memory consumption is higher. 
Well and except that the database loader has more work to do on the CPU.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

{{FGCquote
|Doing that differently will provide some overhead that could be kept at a 
minimum I think: 
For the disk usage, I think gzip compressing these will work sufficiently fine. 
Ram usage of the images should not hurt too much. Sure the images are bigger 
in memory. But fgfs is not just about images - far from that. 
On the GPU, you can still use compression for the textures as the internal 
format. This is what flightgear tries to do if the extension is supported 
(checked by osg). 
 
The major point is that there are several ways that use slightly more 
resources to get around this problem. 
But once the patented compression is on disk, there is *no* way back for 
people not having this feature. 
 
If you have better ideas that do not rule out intel and the oss drivers, you 
are welcome!
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this 
also the case for the default win32 case? Is there a osgdb_gz.dll or something 
along the lines in the directory containing the plugins? 
 
If yes, we can already tackle the size problem of the uncompressed dds files on 
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and 
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. 
And I assume that this works fine for all unix like operating systems including 
mac?! 
James?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|What about solution 6 with (uncompressed premipmapped dds).gz? 
On linux this should work as long as you have zlib installed which could be 
regarded as a system library there. 
Can we rely on zlib being compield into our osg distributions on win32? We do 
need zlib in any case, it's mostly about teaching osg that it finds our zlib on 
configure and build the gz plugin.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I implemented a mipmap control and generation tool in effects when I last updated 
the urban shader. For the moment, it relies on hardware when the average operator 
is used for all texture channels but it could easily be modified to compute 
all mipmap on the CPU. look the <mipmap-control> effect option and 
mipmap.[ch]xx in SG material lib
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees
& buildings)</nowiki>
|author=<nowiki>Frederic Bouvier</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

== Implementation ==
{{FGCquote
|As has been previously pointed out, the current DDS texture set is not 
simply the global png texture set converted. 
 
For our own sanity and those of the users, we need to ensure that there's 
an apples-to-apples comparison being made when we change the default. I 
therefore think we need to create a DDS version of the current default 
texture set.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|2) If we go down this path, we probably want to separate the underlying 
texture format from the materials.xml definition entirely. For example, we 
could simply remove the extention from the materials definition, and have 
the C++ code append the appropriate extension based on a separate property. 
This has a couple of advantages: 
a) Makes testing easier and materials definitions less error-prone. 
Assuming we have some batch job in place to generate dds textures, those 
working on materials definitions could continue to work with png textures, 
and only convert to dds as a final step (or indeed as part of the "make 
release" jobs). 
a) Avoids duplication of materials definitions. Having just spent quite a 
bit of time making the materials definitions more efficient, I'd like to 
avoid making it worse again! 
 
I'm quite happy to do the C++ coding required for this in the materials 
loader - it's probably pretty straightforward.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|That does leave the issue of what happens to the existing dds texture 
definitions where there are special mipmap layers. I'd suggest that we 
have some Clever Script (tm) that is able to work out whether the DDS or 
PNG version of a texture is the master, and then generate the other version 
from it. I admit that the PNG conversion of the DDS will lose some 
information in this process, but it would allow those without DDS support 
to at least use the textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|3) We need a sensible process for dealing with aircraft, which has been 
identified as a significant issue. Again, I think more aircraft developers 
find .png easier to deal with, and there are a lot of aircraft out there 
that would need conversion. It feels like we need some build scripts to 
"compile" aircraft to use DDS textures. 
 
A more far-fetched idea might be to have a cache of dds textures that are 
generated on-the-fly, or when aircraft are loaded by the aircraft center. 
Clearly that impacts initial load time the first time a new aircraft is 
loaded, and would increase the size of .fgfs/ directories massively, but it 
would remove the need for any work by aircraft/scenery developers and could 
be made optional. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

== Challenges ==
{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==
Also see [[DDS texture conversion]].

{{FGCquote
|the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names) 
 
notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like: 
 
1 
 
 
just be sure to include this in the normal map effects with png and it will be easier: 
 
0 
 
 
about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here: 
 
http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799214/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean pellotier</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

{{FGCquote
|I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799324/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>TDO Brandano</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''

{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==
{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

[[Category:Core development projects]]

FlightGear World Scenery 2.0

2014-08-12T09:15:35Z

F-ojac: /* Side note */

:''Follow the dedicated forum thread: [http://forum.flightgear.org/viewtopic.php?f=5&t=21294 FG Worldwide scenery 2.0 - Return of experience]''

The '''FlightGear World Scenery 2.0''' was released during [[FSweekend]] November 2013. This new scenery reflects a major improvement over the existing default world scenery and has taken over five years to complete. A [http://mapserver.flightgear.org/map/?lon=14.56652&lat=-25.18458&zoom=1&layers=B00000000000FTFFTFFTFFFFFFFF much higher level of detail] and internal consistency characterizes this new release, in addition to the fact that it will serve as a stepping-stone for further incremental refinements.

{{Note|Also see [[World Scenery 3.0 roadmap]] }}

== Source data ==
This FlightGear World Scenery was compiled from:
* ViewFinderPanoramas elevation model by Jonathan de Ferranti (using terrafit.py -x 20000 -e 10),
* VMap0 Ed.5 Worldwide Land Cover
* CORINE Land Cover 2006v16 for Europe (Source : European Union, SOeS, CORINE Land Cover, 2006 - [http://www.ifen.fr/index.php?id=88]). See [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail|here] for the correspondance between CORINE and FG textures
* Several custom land cover enhancements (to be listed here...)
* The latest airports (2013.10), maintained by Robin Peel of X-Plane
* Road, rail and rivers courses line data by OpenStreetMap [http://www.openstreetmap.org]

== Distribution ==
World Scenery 2.0 is available through the usual channels:
* [[TerraSync]]
* [http://terasaur.org/item/downloads/flightgear-v2-12/6697 Torrent]
* FlightGear main website
* [[TerraSync by hand using svn]]

== Side note ==
Note that all objects elevation were recomputed. Thus, if some objects were defined with a bad elevation or bad offset, they may have taken a bit of elevation. Use [http://scenemodels.flightgear.org our webforms], if necessary, to fix this.
Please also note that the new scenery is currently quite heavy and hardly runs and can lead to FG crashes if run on systems with less than 4Gb RAM and if you're not using FG 64 bits. This is being worked on, however keeping a high quality scenery with a lower count of triangles is not easy. The addition of OSM roads added a lot of new triangles, hence the fps reduction.

== Screenshots ==

== Known bugs and limitations ==
# clipping of OSM roads on water showing height glitches (due to bad coast/river lines definitions and bad clipping): clip roads against landmass or add landmass where required? Should roads over bridges get removed, even in places where a 3D bridge model is missing?
# some z-fighting (clipper is generating the correct number of contours, but the airport hole is wound as a boundary, not a hole) and/or triangles on airports (LFRH, EDWJ (partially submerged)...);
# some troubles on very dense cities (such as Paris) leading to grey-white triangles on cities - see also yellow lines @LFPG;
# some line issues on small airfield with LTA specific runways (LFNH, LFLI...) - the small centerlines on the runways are "floating" over the runway (20 cm to 1m), leading to some gear destructions ;-) (they didn't use lines, but surfaces that are defined as transparent and borders defined as the line type. This way you limit the number of "line features"). Probably "hot" = false would solve it. See [http://uppix.net/y1H1NB.png 1] [http://uppix.net/sMdg17.png 2] [http://uppix.net/kAXrdF.png 3] [http://uppix.net/vYuReF.png 4] [http://uppix.net/DQ4NHr.png 5]. Thanks Clément for noticing;
# airport being located over two different tiles sometimes renders bad, leading to z-fighting (LEJR, UKKE...);
# on sharp cliffs, water sometimes climb over the cliffs (see e000n40/e000n49/2958056 and [http://img809.imageshack.us/img809/2082/9n96.jpg this picture] for instance). Thanks clm76 for reporting;
# terrain and ocean z-fighting such as [http://mapserver.flightgear.org/map/?lon=12.73312&lat=55.60834&zoom=15 east of EKCH]. See tile 3155042 and EDWJ;
# clipping between river and terrain is somewhat strange, making the river "climb" over the terrain, noticeably under bridges - probably due to the presence of the roads. See [http://img809.imageshack.us/img809/2082/9n96.jpg this example];
# the Moss Landing airport (on the coast a little bit south of KSFO) is partly submerged into the water and the airport's north end is elevated above the terrain around it. There is an area on the coast just to the north of the Moss Landing airport that is above sea level if you are up above 1000ft but is covered in water is you are on the deck. When flying over this you can see trees sticking up out of the water so the code that is placing random trees thinks this is above sea level. The old scenery didn't have either of these problems. Also if you fly over this at just the right altitude you can see this area switching back and forth between being water and land (thanks hvengel);
# on many airports where the taxiway signs are now taken from the apt.dat and put in the Terrain folder, the old signs still remain in the Object folder. See EDDF, ELLX;
# on ELLX there are some problems with "holes" in the pavement that flicker between grass and tarmac. I saw this (if I remember correctly) with an older development version of terragear, but this was fixed some time ago.
# on EHAM some vertice seems to be inverted [http://uppix.net/AVUaZt.jpg see this picture]
# at LFLI the taxiway is not correctly drawn
# the taxiway signs are not rendered correctly with transition shader set to its maximum in ALS. Quoting ThorstenB, "It occurs because you're using the terrain shader effect on something that isn't part of the terrain but in reality an artificial object placed onto the terrain. The terrain shader effect concludes correctly that a natural vertical surface cannot be anything but rock, so it replaces the default texture with the default steep gradient texture - which is rock. In my view, the proper solution would be to *not* render signs as part of the terrain but to let a different effect handle them (model-default.eff should do the trick for instance, but one could also run a lower quality terrain shader). If that is not acceptable a workaround is to declare the gradient texture for the signs as void.png as described in http://wiki.flightgear.org/Procedural_Texturing#The_gradient_texture which continues to use the terrain-specific effect but instructs the shader not to use a separate texture for steep gradients."
# sometimes some strange water width transitions, like [http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/TG%20bugs/fgfs2013-11-0822-18-06-03_zpsf3527850.jpg for the Rhein] - reported by ot-666
# In a few airports (LEVT, LEGE are two examples), taxiways are defined in using a stack of layers: the bottom layer for the asphalt surface and the upper layer (defined as transparent) is only used to define the lines. Current tools do not support stacks of layers and the upper layer is "transparent" all the way down to the ground. See [http://i.imgur.com/AkOd5Zo.png 1] and [http://forum.flightgear.org/viewtopic.php?f=5&t=21294&p=201132#p201126 2] This is easily fixable in the data by changing transparent layers to asphalt, but it involves a manual intervention in each airport and sending the data back to Robin. And actually, there is not anything wrong with the original data. Other airports such as LFLR do take advantage of transparent taxiways.
:: I am working on a true priority stack for genapt ( while bringing the design to match tg-construct ). Transparent pavement should work just like x-plane, but the orthographic images are not.--[[User:Psadro gm|Psadro gm]] ([[User talk:Psadro gm|talk]]) 18:50, 1 March 2014 (UTC)

Fixed:
* [FIXED] near EHAM there is a pylon under terrain [http://uppix.net/7rFkTR.jpg see this picture]
* [FIXED] glacier landcover is missing, leading to some holes in high moutains, as seen in Switzerland (SW [http://mapserver.flightgear.org/map/?lon=8.12304&lat=46.07741&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF LSMM]), Austria ([http://mapserver.flightgear.org/map/?lon=11.3527&lat=47.25782&zoom=10&layers=B00000000000FTFFTFFTFFFFFFFF south of LOWI]) and Northern Norway (i.e. [http://mapserver.flightgear.org/map/?lon=14.210&lat=65.974&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF near ENMS]);
* [FIXED] triangle winding appears inconsistent - especially when a vertex is shared by 4+ edges. Issue can be visualized here: [https://dl.dropboxusercontent.com/u/29968727/fgfs-screen-116.png messed up binormals and tangents] This may be the root cause of the urban shader issue - reported by i4dnf. Issue understood - Winding is not the issue, duplicate nodes per triangle (zero area triangles) are possible when converting the CGAL exact triangle back to nodes using double floats.

== Features enhancement ==
# enhance landcover data for the rest of the world (OSM? vectorize US-American NLCD2006?) and add more custom scenery and fixes;
# complete CORINE coverage, fix overlaps in CLC2000 and merge with CLC2006;
# use latest ViewFinderPanoramas DEM's;
# find a new svn hosting solution;
# compute the next terrain with textures-lines option;
:: (requires pavement atlas - single texture for all road / rail / streams ) to keep framerate under control
# add some more OSM data (secondary...);
# descent airports priority below roads, so roads and railroads can be shown over airports; have a proper solution for roads running over terrain classified as airfield, maybe extract administrative boundaries from apt.dat;
# retry multi-thread;
# enhance the "random" tree and builds placement to take OSM into account;
# .SPT file support - push Mathias' LOD ideas forward;
# landclass border blurring - Several ideas on this - It would be really nice to be able to do it;
# osm motorway_link (and the other _link) roads should probably have their own width. Perhaps grouped into a separate shapefile, or handled in ogr-decode - single lane is most likely;
# osm line data simplification / preprocessing. - We've done some experimenting, and the results are promising. This should reduce the number of triangles generated. It could create longer continuous roads, which allows better control of the generated texture coordinates - so we could, theoretically, populate the roads with traffic in the future.

== External link ==
* World Scenery 2.0 release announcement on the forum: [http://forum.flightgear.org/viewtopic.php?f=5&t=21226& FlightGear World Scenery 2.0 released]

[[Category:Scenery]]

Talk:FlightGear Newsletter June 2014

2014-07-03T08:56:16Z

F-ojac:

== Attracting new contributors ==

Hi,

while I agree that we need additional contributors, I don't think we should try to achieve that by placing the same (lengthy) texts in every newsletter. Reading the same call for help every month looks rather desperate and might make people avoid our newsletters because they've already read half of it. I personally think the "Contributing" section is sufficient and a lot more attractive.

Cheers,
[[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 09:36, 22 June 2014 (UTC)
: Not sure what you meant with your edit comment, but there's still the "Getting your own ideas and features in FlightGear without having to be a coder" section that was already present in the previous edition; as well as (partly) overlapping with the "Contributing" section.
: [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 20:47, 24 June 2014 (UTC)

:: Okay, apparently I completely misunderstood and have been removing the wrong sections. But feel free to revert/remove whatever you consider redundant. In general, I tend to agree with you - but currently we're not exactly having too many contributors, and not a lot of content either. So I tend to add stuff just to populate the newsletter a little, even though I realize that quality isn't really improving this way (just talked with Thorsten about this). Sorry for removing the wrong sections though...--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 20:54, 24 June 2014 (UTC)

== Newsletter and Android ==

Hi all,
I really enjoy the new theme for the newsletter, however the layout seems to be screwed up on Android default Internet browser.
Has anyone else tried it?

Thanks,
--[[User:F-ojac|F-ojac]] ([[User talk:F-ojac|talk]]) 08:56, 3 July 2014 (UTC)

FlightGear World Scenery 2.0

2014-03-05T20:42:59Z

F-ojac: Terrafit was set with -e10.

:''Follow the dedicated forum thread: [http://forum.flightgear.org/viewtopic.php?f=5&t=21294 FG Worldwide scenery 2.0 - Return of experience]''

The '''FlightGear World Scenery 2.0''' was released during [[FSweekend]] November 2013. This new scenery reflects a major improvement over the existing default world scenery and has taken over five years to complete. A [http://mapserver.flightgear.org/map/?lon=14.56652&lat=-25.18458&zoom=1&layers=B00000000000FTFFTFFTFFFFFFFF much higher level of detail] and internal consistency characterizes this new release, in addition to the fact that it will serve as a stepping-stone for further incremental refinements.

== Source data ==
This FlightGear World Scenery was compiled from:
* ViewFinderPanoramas elevation model by Jonathan de Ferranti (using terrafit.py -x 20000 -e 10),
* VMap0 Ed.5 Worldwide Land Cover
* CORINE Land Cover 2006v16 for Europe (Source : European Union, SOeS, CORINE Land Cover, 2006 - [http://www.ifen.fr/index.php?id=88]). See [http://wiki.osgeo.org/wiki/LandcoverDB_CS_Detail|here] for the correspondance between CORINE and FG textures
* Several custom land cover enhancements (to be listed here...)
* The latest airports (2013.10), maintained by Robin Peel of X-Plane
* Road, rail and rivers courses line data by OpenStreetMap [http://www.openstreetmap.org]

== Distribution ==
World Scenery 2.0 is available through the usual channels:
* [[TerraSync]]
* [http://terasaur.org/item/downloads/flightgear-v2-12/6697 Torrent]
* FlightGear main website
* [[TerraSync by hand using svn]]

== Side note ==
Note that all objects elevation were recomputed. Thus, if some objects were defined with a bad elevation or bad offset, they may have taken a bit of elevation. Use [http://scenemodels.flightgear.org our webforms], if necessary, to fix this.

== Screenshots ==

== Known bugs and limitations ==
# clipping of OSM roads on water showing height glitches (due to bad coast/river lines definitions and bad clipping): clip roads against landmass or add landmass where required? Should roads over bridges get removed, even in places where a 3D bridge model is missing?
# some z-fighting (clipper is generating the correct number of contours, but the airport hole is wound as a boundary, not a hole) and/or triangles on airports (LFRH, EDWJ (partially submerged)...);
# some troubles on very dense cities (such as Paris) leading to grey-white triangles on cities - see also yellow lines @LFPG;
# some line issues on small airfield with LTA specific runways (LFNH, LFLI...) - the small centerlines on the runways are "floating" over the runway (20 cm to 1m), leading to some gear destructions ;-) (they didn't use lines, but surfaces that are defined as transparent and borders defined as the line type. This way you limit the number of "line features"). Probably "hot" = false would solve it. See [http://uppix.net/y1H1NB.png 1] [http://uppix.net/sMdg17.png 2] [http://uppix.net/kAXrdF.png 3] [http://uppix.net/vYuReF.png 4] [http://uppix.net/DQ4NHr.png 5]. Thanks Clément for noticing;
# airport being located over two different tiles sometimes renders bad, leading to z-fighting (LEJR, UKKE...);
# on sharp cliffs, water sometimes climb over the cliffs (see e000n40/e000n49/2958056 and [http://img809.imageshack.us/img809/2082/9n96.jpg this picture] for instance). Thanks clm76 for reporting;
# terrain and ocean z-fighting such as [http://mapserver.flightgear.org/map/?lon=12.73312&lat=55.60834&zoom=15 east of EKCH]. See tile 3155042 and EDWJ;
# clipping between river and terrain is somewhat strange, making the river "climb" over the terrain, noticeably under bridges - probably due to the presence of the roads. See [http://img809.imageshack.us/img809/2082/9n96.jpg this example];
# the Moss Landing airport (on the coast a little bit south of KSFO) is partly submerged into the water and the airport's north end is elevated above the terrain around it. There is an area on the coast just to the north of the Moss Landing airport that is above sea level if you are up above 1000ft but is covered in water is you are on the deck. When flying over this you can see trees sticking up out of the water so the code that is placing random trees thinks this is above sea level. The old scenery didn't have either of these problems. Also if you fly over this at just the right altitude you can see this area switching back and forth between being water and land (thanks hvengel);
# on many airports where the taxiway signs are now taken from the apt.dat and put in the Terrain folder, the old signs still remain in the Object folder. See EDDF, ELLX;
# on ELLX there are some problems with "holes" in the pavement that flicker between grass and tarmac. I saw this (if I remember correctly) with an older development version of terragear, but this was fixed some time ago.
# on EHAM some vertice seems to be inverted [http://uppix.net/AVUaZt.jpg see this picture]
# at LFLI the taxiway is not correctly drawn
# the taxiway signs are not rendered correctly with transition shader set to its maximum in ALS. Quoting ThorstenB, "It occurs because you're using the terrain shader effect on something that isn't part of the terrain but in reality an artificial object placed onto the terrain. The terrain shader effect concludes correctly that a natural vertical surface cannot be anything but rock, so it replaces the default texture with the default steep gradient texture - which is rock. In my view, the proper solution would be to *not* render signs as part of the terrain but to let a different effect handle them (model-default.eff should do the trick for instance, but one could also run a lower quality terrain shader). If that is not acceptable a workaround is to declare the gradient texture for the signs as void.png as described in http://wiki.flightgear.org/Procedural_Texturing#The_gradient_texture which continues to use the terrain-specific effect but instructs the shader not to use a separate texture for steep gradients."
# sometimes some strange water width transitions, like [http://i217.photobucket.com/albums/cc283/oliunterderbruecke/flightgear/TG%20bugs/fgfs2013-11-0822-18-06-03_zpsf3527850.jpg for the Rhein] - reported by ot-666
# In a few airports (LEVT, LEGE are two examples), taxiways are defined in using a stack of layers: the bottom layer for the asphalt surface and the upper layer (defined as transparent) is only used to define the lines. Current tools do not support stacks of layers and the upper layer is "transparent" all the way down to the ground. See [http://i.imgur.com/AkOd5Zo.png 1] and [http://forum.flightgear.org/viewtopic.php?f=5&t=21294&p=201132#p201126 2] This is easily fixable in the data by changing transparent layers to asphalt, but it involves a manual intervention in each airport and sending the data back to Robin. And actually, there is not anything wrong with the original data. Other airports such as LFLR do take advantage of transparent taxiways.
:: I am working on a true priority stack for genapt ( while bringing the design to match tg-construct ). Transparent pavement should work just like x-plane, but the orthographic images are not.--[[User:Psadro gm|Psadro gm]] ([[User talk:Psadro gm|talk]]) 18:50, 1 March 2014 (UTC)

Fixed:
* [FIXED] near EHAM there is a pylon under terrain [http://uppix.net/7rFkTR.jpg see this picture]
* [FIXED] glacier landcover is missing, leading to some holes in high moutains, as seen in Switzerland (SW [http://mapserver.flightgear.org/map/?lon=8.12304&lat=46.07741&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF LSMM]), Austria ([http://mapserver.flightgear.org/map/?lon=11.3527&lat=47.25782&zoom=10&layers=B00000000000FTFFTFFTFFFFFFFF south of LOWI]) and Northern Norway (i.e. [http://mapserver.flightgear.org/map/?lon=14.210&lat=65.974&zoom=9&layers=B00000000000FTFFTFFTFFFFFFFF near ENMS]);
* [FIXED] triangle winding appears inconsistent - especially when a vertex is shared by 4+ edges. Issue can be visualized here: [https://dl.dropboxusercontent.com/u/29968727/fgfs-screen-116.png messed up binormals and tangents] This may be the root cause of the urban shader issue - reported by i4dnf. Issue understood - Winding is not the issue, duplicate nodes per triangle (zero area triangles) are possible when converting the CGAL exact triangle back to nodes using double floats.

== Features enhancement ==
# enhance landcover data for the rest of the world (OSM? vectorize US-American NLCD2006?) and add more custom scenery and fixes;
# complete CORINE coverage, fix overlaps in CLC2000 and merge with CLC2006;
# use latest ViewFinderPanoramas DEM's;
# find a new svn hosting solution;
# compute the next terrain with textures-lines option;
:: (requires pavement atlas - single texture for all road / rail / streams ) to keep framerate under control
# add some more OSM data (secondary...);
# descent airports priority below roads, so roads and railroads can be shown over airports; have a proper solution for roads running over terrain classified as airfield, maybe extract administrative boundaries from apt.dat;
# retry multi-thread;
# enhance the "random" tree and builds placement to take OSM into account;
# .SPT file support - push Mathias' LOD ideas forward;
# landclass border blurring - Several ideas on this - It would be really nice to be able to do it;
# osm motorway_link (and the other _link) roads should probably have their own width. Perhaps grouped into a separate shapefile, or handled in ogr-decode - single lane is most likely;
# osm line data simplification / preprocessing. - We've done some experimenting, and the results are promising. This should reduce the number of triangles generated. It could create longer continuous roads, which allows better control of the generated texture coordinates - so we could, theoretically, populate the roads with traffic in the future.

== External link ==
* World Scenery 2.0 release announcement on the forum: [http://forum.flightgear.org/viewtopic.php?f=5&t=21226& FlightGear World Scenery 2.0 released]

[[Category:Scenery]]