Bonjour Olivier, bonjour à tous les "VFR-Users" ,
Question: à quoi correspondent les 3ième et 4 ième instruction d'une ligne de commande d' un fichier route ...?
Exemple:

45.946388;4.035000;800.5807995385572;0.0
Cordialement,
G.R.

Bonjour,

- Altitude du point en mètres.
- Consigne de vitesse en mètres par seconde.

Cordialement,

Olivier

olivier écrit: (...)
- Altitude du point en mètres.
(...)

et au dixième de picomètre près ! mazette !

On ne rigole pas avec la précision !!

Non, sans rire, c'est juste le résultat d'une conversion de pieds en mètres qui ne tombe pas juste.

olivier écrit: On ne rigole pas avec la précision !!

Non, sans rire, c'est juste le résultat d'une conversion de pieds en mètres qui ne tombe pas juste.

L'important est qu'au rechargement la conversion retombe sur ses pieds !

Un fichier route de VFR pour faire LFOU -> LFJB -> LFCT -> LFOD, c'est ça :

47.081944;-0.877222;122.83439981329171;0.0
46.903055;-0.6975;156.97199976140254;0.0
46.961944;-0.152777;182.8799997220224;0.0
47.256666;-0.113611;182.8799997220224;0.0

Pas de trace dans le fichier du nom des WP, pourtant le log de la route en question les indique bien, ce qui laisse penser qu'un rapprochement des coordonnées des points tournants avec la base de donnée des WP est fait au moment du chargement de la route en mémoire.

Pour comparer, la même route au format GPX, c'est ça :

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="Air Navigation Pro for iOS and Android" xmlns="www.topografix.com/GPX/1/1" xmlns:xsi="www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="www.topografix.com/GPX/1/1 www.topografix.com/GPX/1/1/gpx.xsd">
<rte>
<rtept lat="47.081944" lon="-0.877230">
<geoidheight>135.026400</geoidheight>
<name>LFOU</name>
<desc>CHOLET LE PONTREAU</desc>
<type>Airport</type>
<extensions>
<main_runway_orientation>27</main_runway_orientation>
</extensions>
</rtept>
<rtept lat="46.903890" lon="-0.696390">
<geoidheight>175.564800</geoidheight>
<name>LFJB</name>
<desc>MAULEON</desc>
<type>Airport</type>
<extensions>
<main_runway_orientation>37</main_runway_orientation>
</extensions>
</rtept>
<rtept lat="46.961950" lon="-0.152780">
<geoidheight>103.936800</geoidheight>
<name>LFCT</name>
<desc>THOUARS</desc>
<type>Airport</type>
<extensions>
<main_runway_orientation>121</main_runway_orientation>
</extensions>
</rtept>
<rtept lat="47.256800" lon="-0.113620">
<geoidheight>81.991200</geoidheight>
<name>LFOD</name>
<desc>SAUMUR ST FLORENT</desc>
<type>Airport</type>
<extensions>
<main_runway_orientation>96</main_runway_orientation>
</extensions>
</rtept>
</rte>
</gpx>

C'est du XML dont le décodage "humain" est assez simple même si on n'est pas un pro de l'informatique. Il y a beaucoup plus de données associées, mais, à la réflexion la formule la plus riche ne me semble pas forcément la meilleure.

Le problème est de pouvoir utiliser sur un système, une route préparée sur un autre.
VFR lit indifféremment la route GPX (faite avec AIRNAV PRO ou (évidemment !) son propre format, ce qui est une polyvalence très intéressante, mais la réciproque n'est pas vraie avec AIRNAV PRO (idem pour les EFIS DYNON).

Un logiciel de navigation, devrait pouvoir exploiter un fichier route qui donne juste les coordonnées (et l'altitude) des WP, et les afficher en exploitant sa propre base de donnée. Cela éliminerait les risques de doublons et les pb liés aux façons différentes de codifier certains WP, les points de report VFR par ex.

Donc VFR facilite la vie de ses utilisateurs en absorbant des ROUTES d'origines variées, (merci Olivier), mais n'est pas une plateforme de préparation de ROUTES pour d'autres applications ... ce qui n'est pas une grosse gêne.

PS : le décodage du XML est "assez simple" si on a les indentations qui sont présentes en mode édition mais disparaissent à la publication du post