de Joël Tremblet :

je me suis aperçu d'un soucis de config avec les types de vol pour les stat de fin d'années.
La saisie par les pilotes n'est pas rigoureuse et lors d'un vol d'instruction le type de vol local ou nav ne sont pas cochée. Dans OF il suffit d'avoir une case de cochée pour que le programme accepte la saisie. Ces vols ne sont donc pas classés ni en local ni en nav Pour vérifier ta configuration essaye les requetes statistiques exposées sur le Wiki. Comme tu n'as pas beaucoup de vols tu pourras rapidement detecter des ecarts (local + nav <> total des vols)
Je vais bloquer le type de vol instruction pour limité ce cas mais si la config des types de vol est permissive tu n'auras pas les stats en 2009.
Selon ton constat reserre les parametres d'incompatibilité des vols

--------

Réponse MF :

je regardais justement comment "décoder" en SQL les types de vols multiples dans une requête, en examinant la manière dont ils étaient mis en table. Par exemple, pour nous ACCM, pour un vol local (type 1) et en instruction (type 32) il apparait donc 33. Et je me demandai comment j'allais décoder cela pour faire apparaitre le bon libellé dans une zone, en indiquant par exemple "local instruction" !

Je m'étais basé initialement sur les conseils de paramétrage de V2 pour les types de vols (local, navigation, instruction,...), mais en réflichissant bien, et ce que tu me dis me conforte dans ma façon de penser, je m'aperçois qu'il n'est peut-être pas judicieux d'intégrer la notion d'instruction dans le type de vol. Car on peut savoir par ailleurs si le vol est un vol d'instruction par la présence de l'instructeur en second pilote. Ainsi, on pourrait rendre obligatoire la saisie du type de vol et qu'il n'y en ait qu'un seul d'indiqué dans les choix possibles (local, navigation, voltige, montagne, mecanique) tous incompatibles entre eux.

Qu'en penses-tu ?

Et ce sera moins difficile pour décoder et afficher les libellés de types de vols en double comme actuellement mon "33" qui est local + instruction !

J'ai regardé chez nous, pour le moment il n'y a pas eu d'oublis dans les saisies des vols, mais ce n'est que le début !

;-)

Il ne faut pas confondre moyen et but !

Vous avez plusieurs problèmes (but) :

- établir des stats
- décoder des types de vols (qui est aussi un moyen pour établir vos stats)

Et vous avez un moyen : la notion de type de vol qui peut s'additionner dans OF.

Pour décoder les types de vols en SQL il faut utiliser le & pour séparer les différents bits. Je n'ai malheureusement pas le temps de vous construire une bonne requête SQL à partir de là. Mais vous avez tout 2008 pour le faire ;-)

Donc une fois cette difficulté résolue, vous obtiendrez bien la liste des vols selon tous les critères et vous pourrez atteindre votre but : décoder les types de vols sans qu'il y ait besoin de revoir le moyen (qui a l'avantage d'offrir une certaine souplesse).

Ensuite, concernant "vol local" et navigation" ce qui vous embête, si j'ai bien compris, c'est qu'ils puissent être cochés ensemble. Si vous ne le voulez-pas il suffit de les rendre incompatibles entre-eux. C'est d'ailleurs fait pour l'ACCM. C'est peut-être pour cela que vos pilotes ne se sont pas trompés jusqu'à présent ;-)

Il reste donc un seul soucis : si le pilote coche uniquement instruction (et ne précise pas local ou navigation).

Pour ma part, je considère qu'il y a deux solutions possibles pour les stats :
- soit vous réfléchissez à la définition de "navigation" au sens statistique. Et comme vous ne trouverez pas la définition, vous posez la question à la personne qui vous demande de remplir le formulaire (la DGAC) et ensuite vous utiliserez cette réponse pour construire une requête SQL adéquate (qui ne tienne pas compte des types de vols saisis par exemple en disant : vol supérieur à 2 heures ou tout vol avec un aérodrome de départ et un aérodrome d'arrivée différents). Ainsi vous aurez atteint votre but (faire les stats) sans avoir à changer un moyen qui est finalement indépendant de cela.

- soit vous considérez la première solution mais uniquement pour les vols d'instructions non défini (entre vol local et navigation). Et ainsi, vous aurez la satisfaction d'avoir laisser les pilotes orienter les statistiques comme pour un sondage ;-)

(ma préférence va à la première solution, car les stats ne sont pas un sondage et je ne suis pas sûr que chaque pilote connaisse la définition de "navigation" au sens statistique, puisque nous-même nous ne la connaissons pas...).

Christophe LARATTE
OpenFlyers manager

Pas de souci, j'ai déja fini ma requete SQL avec interprétation des types de vol !

Néanmoins je reste toujours dubitatif sur l'utilité de laisser la notion d'instruction dans les types de vol puisqu'elle est redondante avec la notion d'eleve pilote (table flight_pilot : function_id et num), qu'elle complique un peu l'interprétation multiple des libelles de type de vols, et que les pilotes peuvent oublier de saisir local ou navigation en n'indiquant que vol instruction.

Elle sert pour la facturation. Et ça, c'est important la facturation ;-)

Christophe LARATTE
OpenFlyers manager

Affirm ! On est donc bien obligé de garder cette notion, je suis d'accord, la facturation c'est important ;-)

J'ai modifier la condition de contrôle des types de vol et maintenant le "Type de vol obligatoire en cas de second pilote a bord" n'est plus considéré comme suffisant pour valider une saisie. Le cas du vol d'instruction est donc reglé si dans votre config vous avez imposé le type Instruction comme "Type de vol obligatoire en cas de second pilote a bord"

Maintenant il reste tous les autres cas, je conseille donc d'imposer une incompatibilité stricte entre les autres types de vols

Le type de vol navigation est clairement defini pour les Stats par la DGAC dans le logiciel AERAL.

Un point important c'est que hdv local + hdv nav = hdv total
Mon experience d'utilisation des AD depart et arrivé pour comptabiliser les vols de navigation n'est pas concluante car les destinations ne sont pas correctement renseignées par les pilotes. Les chiffres calculés sur l'année 2007 de l'ACJP étaient complétement discordants de ceux calculés depuis + de 20 ans



Modifié 1 fois. Dernière modification le 02/02/08 09:13 par jtremblet.

La modification souhaitée par Joël ne s'insère pas correctement dans le cadre général du gestionnaire des types de vol.

Sur http://aeral.aviation-civile.gouv.fr/ je ne trouve qu'un formulaire et sur ce formulaire je ne trouve pas la définition de "navigation".

Si les destinations ne sont pas correctement saisies par les pilotes il n'y a pas de raison qu'il saisissent mieux le type de vol.

Par contre, il est prévu de faire une vérification sur les champs "départ" et "arrivée" lorsque la durée du vol est supérieure à une certaine valeur et de demander au pilote de confirmer qu'il ne s'est pas trompé.

Car là aussi, les champs "départ" et "arrivée" ont une importance autre que les simples stats : ils peuvent être utiles au club pour retrouver l'origine de certaines taxes d'atterrissages parvenues au club (et qui dit taxe dit facturation ;-)

Christophe LARATTE
OpenFlyers manager

Avec une expérience de 20 ans sur cette pratique je peux assurer que les pilotes respectent très correctement la saisie du type de vol par une case à cocher mais ont certaines réticences qui naissent des qu'ils doivent faire de la saisie
Exemple type :
Il est très courant de voir les carnets de vol avec une seul ligne pour un vol LFRC LFRK LFRC. Si sur le papier on peut facilement écrire entre les cases, il n'en est pas de même en informatique et dans ce cas le pilote ne mets qu'une seule saisie avec Départ LFRC - Arrivée LFRC mais renseigne correctement le type de vol

Je me sens pas l'âme d'un gendarme au sein du club pour réprimandé cette pratique "non réglementaire". Cette attitude ne m'aurait pas permit de rester 20 ans en ardent défenseur de notre aviation
Il y a parfois des attitudes qui ne respectent pas la loi binaire de l'informatique, certains appelleront cela "Politique"