ANTHOINE Emmanuel Rapport de stage 2ème Année ENSIMAG

Q

EXTRACTION DE DONNEÉS

1 - - -

I

RADAR

Responsables : Frédéric CAZENA VE et Thierry LEBEL.

Dates : Di1 3 au 28 juillet et dLi 21 août au 15 Septembre 199.5.

y3254

1

Table des matières

1 Présentation générale 4 1.1 L’ORSTOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Sonrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2 Sa structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 L’ORSTOM à Grenoble : le groupe PRAO . . . . . . . . . . . . . . . 5 1.2.1 Les lieux et les personnes . . . . . . . . . . . . . . . . . . . . . 6

2 Le contexte de mon stage 7 2.1 Les logiciels du projet EPSAT-Niger . . . . . . . . . . . . . . . . . . 7

2.1.1 SANAGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 BADORA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Déroulement de mon stage . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Présentation de Tcl/Tk et Xf . . . . . . . . . . . . . . . . . . . . . . 8

3 Le programme bdrextract 9 3.1 Le cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Description des données radar . . . . . . . . . . . . . . . . . . 9 3.1.2 La transformation des données . . . . . . . . . . . . . . . . . . 10 3.1.3 Les extractions possibles . . . . . . . . . . . . . . . . . . . . 11 3.1.4 Les formats du fichier de sortie . . . . . . . . . . . . . . . . . 12

3.2 Le travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . t . 12 3.2.1 Description de l’interface . . . . . . . . . . . . . . . . . . . . . 12 3.2.2 Les programmes d’extraction . . . . . . . . . . . . . . . . . . 13

2

Remerciements

Je tient tout d’abord à remercier Frédéric CAZENAVE, mon maître de stage, pour m’avoir suivi et aidé dans ma tâche, ainsi que Thierry LEBEL, responsable de l’équipe grenobloise de I’ORSTOM.

Je remercie également toute l’équipe de 1’ORSTOM avec laquelle j’ai été en collaboration durant ce stage, pour leur sympathie, leur disponibilté et leurs compé- tances en hydrologie qui n’est pas mon domaine.

Enfin, je remercie l’ensemble des personnes du LTHE (Laboratoire d’étude des Transferts en Hydrologie et Environement), pour leur accueil et leur gentillesse.

1

3

Introduction

Ce rapport présente le stage que j’ai effectué au sein de l’antenne grenobloise de l’ORSTOM, situé dans les locaux du LTHE, à l’école d’hydrolique du campus universitaire de Grenoble.

L’ORSTOM a lancé depuis quelques année déjà un programme d’étude des précipitations en Afrique. Les informations recueillies sur place ont été stockées dans des banques de données propres à ce projet, et de nombreux programmes ont été développés pour effectuer divers traitements, en aval de ces banques.

Mon objetif a été de rassembler ces programmes en un seul, et de l’équiper d’un interface graphique à la fois conviviale et complet, sous Tcl/Tk. Pour ce faire, une sorte de ”cahier des charges” fut élaboré lors d’une réuninon avec les futurs ut il is at eurs.

A la fin de mon stage, une première version de ce logiciel d’extraction fonction- nait, même si certaines options n’ont pas été implémentées. L’ORSTOM a l’intention de l’utiliser rapidement puisque ce programme est au cœur de l’étude que mènent actuellement certains élèves en thèse ou en DEA.

4

Chapitre 1

Présentation générale

1.1 L’ORSTOM L’ORSTOM est l’Institut français de recherche scientifique pour le dévelopement

en coopération. C’est un établissement public, à caractère scientifique et technologique, placé

sous la tutelle des ministres chargés de la Recherche et de la Coopération. Depuis cinquante ans, il conduit des recherches sur les milieus intertropicaux qui sont devenus des références internationales.

Aujourd’hui, son budget annuel avoisinne le milliard de francs, il employe 2600 agents dont 800 sont originaires des pays du Sud et il est implanté sur 40 sites répartis dans une trentaine de pays.

1.1.1 Son rôle

I1 propose à ses partenaires du Sud et aux acteurs du développement des pro- grammes et des résultats sur quatres grands thèmes :

i !

- environement et grands écosystèmes océaniques, aquatiques et terrestres,

- agriculture en milieux tropicaux fragiles,

- environement et santé,

- hommes et société en mutation.

I1 propose également ses capacités de diagnostic et d’expertise aux organismes pu- blics et privés français, éhangers ou internationaux.

Ces recherches sont conduites en coopération avec des instituts du Sud, en fonction de choix scientifiques et techniques associant partenaires français et étran- gers. L’ORSTOM participe au renforcement des capacités scientifiques du Sud par la formation à la recherche et par des appuis spécifiques.

1.2. L’ORSTOM À GRENOBLE: LE GROUPE PRAO 5

1.1.2 S a structure L’ORSTOM est structuré en 5 départements pluridisciplinaires qui élaborent et

mettent en œuvre les programmes exécutés par des équipes relevant de 38 Unités de Recherche. Ces départements sont :

- Terre, Océan, Atmosphère,

- Eaux Continentales,

- Milieux et Activité Agricole,

- Santé,

- Sociétés, Urbanisation, Développement.

L’interdisciplinarité thématique et méthodologie est la voie privilégiée de la recherche à 1’ORSTOM.

L’ORSTOM est également constitué de 7 commissions scientifiques, chargées d ’évaluer régulièrement le déroulement des programmes et la carrière des chercheurs qui les exécutent. Elles regroupent plus de 40 disciplines sous leurs intitulés :

- géologie et géophysique,

- hydrologie et pédologie,

- hydrobiologie et océanographie,

- sciences du monde végétal,

- sciences biologique et biochimique appliquées à l’homme,

- sciences sociales,

- sciences de l’ingénieur et de la communication. I l

1.2 L’ORSTOM à Grenoble : le groupe PRAO Le groupe de recherche PRAO (PRécipitations Afrique de l’Ouest) s’est constitué

lors du lancement de l’expérience EPSAT-Niger (Estimation des Pluies par SATel- lite) en 1988, et est basé à Montpelier, à Grenoble, au Niger et au Sénégal.

Le but de l’expérience EPSAT-Niger est d’améliorer notre connaissance des systèmes précipitants d’Afrique Soudano-Sahélienne, et de mettre au point des algorithmes opérationnels d’estimation des pluies dans cette région. Pour cela, elle s’appuie sur l’utilisation conjointe d’un réseau de pluviographes à maillage fin (un peu plus de 100 pluviographes installés sur une zone de 16000 km2 carrés) mesurant la pluie au sol et d’un radar météorologique apportant des informations de méso- échelle.

6 CHAPITRE i. PRESENTATION G ~ N ~ R A L E

1.2.1 Les lieux et les personnes L’équipe PRAO de 1’ORSTOM est intallée dans les bâtiments de 1’ENSHMG

(École Nationale Supérieure d’Hydrolique et de Mécanique de Grenoble) sur le campus de Grenoble. Elle est rattachée administrativement au LTHE, puisque ces deux organismes ont déjà été amenés à réaliser des projets communs.

Pour ma part, je travaillais sur station Sun, partageant un burreau avec trois personnes :

- Frédéric CAZENAVE, mon maître de stage, qui tient la fonction d’assitant ingénieur en informatique pour 1’ORSTOM ;

- Hervé Bknichou, ingénieur Météo-France délégué à l’ORSTOM, qui vient d’a- chever son DEA intitulé : ”Utilisation d’un radar météorologique pour la me- sure des pluies au Sahel : étude du phénomène d’atténuation” ;

- Jean Lecocq, actuellement en thèse au sein de l’ORSTOM, dont le sujet est: ”Climatologie des systèmes précipitants Sahéliens.

J’était sous la responsabilité de Thierry LEBEL, responsable du groupe de re- cherche PRAO. I1 encadra également plusieurs campagnes de saisie des données radar au Niger (auxquelles a particité F. CAZENAVE) et est auteur de plusieurs ouvrages en hydrologie.

Chapitre 2

Le

2.1

contexte de mon stage

Les logiciels du projet EPSAT-Niger

2.1.1 SANAGA

Le radar de Niamey a été numérisé en 1989 par le laboratoire d’Aérologie de l’université Paul SABATIER à Toulouse. L’acquisition numérique des données est réalisée à l’aide du système SANAGA (Système d’Acquisition Numérique pour l’Ana- lyse des Grains Africains), qui gère également l’archivage et la visualisation couleur. I1 est constitué d’un convertisseur analogique-numérique, d’un micro-ordinateur et d’un logiciel d’acquisition des données brutes et de reconstitution d’images radar corrigées. L’éCho radar est codé sur un octet pour un pixel donné et la visualisation couleur est opérée sur 16 niveaux. L’archivage se fait directement sur le disque du micro et peut ensuite être transféré sur cartouches magnétiques, à l’aide d’un lecteur interne. SANAGA permet ainsi de travailler en temps réel et sert de base aux traitements utltérieurs visant à l’étalonnage du radar et à l’étude des systèmes précipitants.

I i

2.1.2 BADORA

Afin de conserver et de traiter la masse de données acquises au cours des saisons des pluies il a été nécessaire de concevoir et de réaliser des banques de données radar, grâce au logiciel BADORA (BAnque de Données RAdar). Celui-ci fonctionne aussi bien sur micro-ordinateur que sur station de travail dotée d’un système d’exploita- tion Unix. Les données y sont stockées selon une structure d’épisodes: les images sont regroupées par veilles1 et les veilles regroupées dans la banque (un banque par saison des pluies).

En aval de ces banques des outils d’extraction ont été développés pour permettre aux utilisateurs de traiter ou visualiser les données des images radar.

1. Une veille ou évènement pluvieux est l’ensemble des informations recueillis lors du passage d’une pluie dans le champ du radar.

8 CHAPITRE 2. LE CONTEXTE DE M O N STAGE

Aujourd’hui, 1’ORSTOM s’apprête à rendre public une partie de ces données sous la forme d’un serveur Web et d’un CD-ROM.

2.2 Déroulement de mon stage Jusqu’ici, l’exploitation des données de ces banques devait passer par ces pro-

grammes, ecrits en langage C, qui ne permettent pas de changer rapidement les paramètres d’extraction, de formattage des données ... En effet, l’utilisateur était souvent ammené à en modifier les sources! C’est pourquoi il m’a été demandé de rassembler ces codes en une même application, de manière à effectuer plus rapidement ces réglages.

Pour plus de convivialité, je devais l’accompagner d’un interface graphique pour n’avoir à rentrer qu’un mininmum d’informations au clavier. Le langage choisi par I’ORSTOM pour le réaliser fut Tcl/Tk, compte tenu de sa gratuité et de sa facilité d’accès.

La première partie de mon stage fut consacrée à l’étude des programmes déjà existants concernant l’application BADORA, ainsi qu’à l’apprentissage du langage Tcl/Tk qui m’était totalement inconnu.

À la demande de F. CAZENAVE, je devais également écrire un manuel utilisateur et une documentation technique concernant mon application. Faute de temps, je ne pu les réaliser qu’une fois mon stage terminé.

2.3 Présentation de Tcl/Tk et Xf Tcl et Tk sont des librairies C du domaine public qui permettent de gérer les

déments d’interfaces graphiques (tels que des fenêtres, des cadres, des boutons ...) au moyen de commandes assez simples. Tcl est la partie qui interprète ces commandes (de la même manière qu’un Shell interprétant un script) et Tk est dédié à la gestion des objets graphiques sous X11. Une telle application est donc portable sur de nombreuses machines.

Afin de faciliter la conception du script Tcl/Tk, j’ai également utiliser l’outil graphique Xf. Conçu par une université allemande, Xf est lui-même un interface graphique réalisé sous Tcl/Tk qui permet construire de tel scripts et d’en voir le résultat, en temps réel, au cours même de la construction. La mise au point des programmes est alors grandement simplifiée et accélérée.

L’utilisation de Xf pose cependant un problème: le code généré par Xf est un script Tcl/Tk et le dialogue avec des programmes C ne peut se faire alors que par l’intermédiaire du Shell, En revanche, sans Xf, il est possible d’appeler les procédures Tk depuis un programme C directement.

9

Chapitre 3

Le programme bdrextract

3.1 Le cahier des charges

3.1.1 Description des données radar Le radar utilisé par 1’ORSTOM sert à mesurer le réflexivité (voir au 3.1.2) et a

un rayon d’action de 350km sur 360 degrés, dont le découpage se fait par radiales de 1.5 degré de largeur. Chaque radiale est découpée suivant sa longueur en 512 portes de même taille, qui peut être 250, 500 ou 750 m, suivant la résolution choisie.

Deux modes d’observation sont possibles pour le radar (voir en annexe un exem- ple de chaque) :

- P P I : c’est le mode le plus utilisé. Le radar effectue un balayage horizontal, avec un site1 quasi-constant et très faible (typiquement 0.8 ou 1.2 degré), et l’azimut peut varié sur les 360 degrés ;

- R H I : dans ce mode, c’est l’azimut qui est fixe et le site varie de O à 90 degrés de manière à obtenir une coupe verticale du nuage. I

Pour avoir une bonne qualité de données, les images ne sont retenues que si elles remplissent certaines conditions, telles qu’un site ne variant pas plus de deux dixième de degré au cours du balayage qui doit couvrir un secteur supérieur à 90 degrés.. .

Une fois numérisées les données recueillis par le radar sont stockées dans trois types d’enregistrement (les radiales, les images et les veilles) :

/*--------------- */

*/ /* Type radiale */

typedef s t r u c t

1. Le site est l’angle que fait l’axe du radar avec la surface du sol. 2. L’azinut est l’angle que fait l’axe du radar avec la direction du Nord.

10 CHAPITRE 3. LE PROGRAMME BDREXTRACT

< ‘ int rad-azimut; /* Azimut de la radiale */ int rad- s it e ; /* site de la radiale */ unsigned char rad-porte [BDRC-NBR-PORTEI ; /* Tableau des portes */

1 rad-t;

*/ /*---------------

*/ /*---------------

c

/* Type image */

t ypedef struct

long img-date-long; int img-secteur-couvert ; int img-s it e ; int img-resolution; int img-nombre-rad; rad-t img-rad [BDRC-NBR-RADI ; int img-ppirhi ;

1 img-t;

/* date de 1 ’ image */ /* secteur couvert par l’image */ /* site moyen de l’image */ /* resolution de l’image */ /* nb de radiales de l’image */ /* les radailes de l’image */ /* image est PPI ou RHI */

long evt-date-deb-long; long evt-date-fin-long; int evt-nombre-image; /* nb de l’images deml’evenement */

/* date de la premiere image */ /* date de la derniere image */

3 evt-t; &

Pour accéder à un élément de la banque, on utilise des procédures basées sur le gestionnaire de fichier C-ISAM, qui s’occupe des accès concurrents, de la cohérence des banques, des droits ...

3.1.2 La transformation des données

Suivant le type d’étude à réaliser sur les données, il doit être possible d’effectuer diverses corrections sur les données brutes du radar, puis de les mettre dans des unités bien précises.

3.1. LE CAHIER DES CHARGES

La nature des données à obtenir

11

Dans le cahier des charges, les données de la base peuvent prendre trois formes différentes dans le fichier de sortie:

1. dB badora : les valeurs sont laissées brutes, c’est-à-dire telles qu’elles sont dans la base de données radar. Elles sont entières et comprises entre O et 255 ;

2. dBí?: Z désigne ici la réflexivité (en mm6/m3). La valeur en dBZ est un réel, calculée à partir de la valeur en dB badora selon l’équation :

dBZ = dBbadora - 15 3

3. R : cette valeur, qui représente l’intensitée de pluie (en mmlh), est un réel, calculé à partir de la valeur en Z selon la relation ZR suivante: 2 = aRb. Lorsque l’on choisi ce type de valeurs de sortie, il faut également préciser les valeurs des coefficients a et b.

Le traitement à effectuer

Les images extraites de la base peuvent être corrigées de trois manières :

1. correction e n distance: compte tenu de l’ouverture des radiales (1.5 degré), le volume d’une porte n’est pas le même suivant la distance à laquelle elle se trouve du radar et la réfexivité mesurée en est affectée. Pour prendre en considération ce phénomène, on ramène toutes les portes à lOkm du radar, par une correction en l / r 2 ;

2. correction en calibration : on suppose que la chaîne de réception du radar sous- estime ou surestime la réflectivité. On ajoute alors une valeur constante en dBZ sur toute les valeurs de l’image; I1 est possible de passer une valeur‘positive ou négative.

3. correction en atténuation : la méthode de correction en atténuation est basée sur l’utilisation de l’algorithme Hitschfeld-Bordan. I1 est nécessaire d’introduire les constantes des relations ZR et KR. Cette dernière lie le coefficient d’atté- nuation I< à l’intensité de pluie, selon l’équation : li’ = a‘Rb’.

I \

3.1.3 Les extractions possibles

Comme il était possible de le faire avant, l’utilisateur doit pouvoir extraire n’importe quel ensemble de valeurs de la base, cet ensemble pouvant changer d’une image à l’autre. Cela comprend l’extraction sur des stations3, sur une radiale, sur un, segment et sur une surface.

3. Une station est un point du scope radar, repéré généralement par ses coordonnées cartésiennes par rapport a u radar.

12 CHAPITRE 3. LE PROGRAMME BDREXTRACT

Dans le cas d’une surface, il doit également être permis de définir un masque à l’intérieur duquel les valeurs ne sont pas extraites. De plus, une classe de distance peut aussi exclure de l’extraction les stations d’une surface situées à une distance trop faible ou trop élevé du radar. On doit aussi pouvoir choisir si l’extraction se fait en coordonnées polaires ou cartésiennes et si les valeurs en dehors de la surface doivent figurer dans le fichier de sortie ou non.

3.1.4 Les formats du fichier de sortie

11 m’était demandé à l’origine huit formats de sortie, se ressemblant plus ou moins: FTS 12, FTS 21, Excel, SURFER, Spyglass, Matlab, GIF et MPEG. I1 est d’ailleurs possible de les classer en 3 catégories : les formats FTS, développés pour des études statistiques et propres à l’hydrologie, les fichiers colonnes, tels que Excel ou SURFER, et les formats matriciels que sont Spyglass, GIF et MPEG.

3.2 Le travail réalisé Compte tenu de tous les choix qui doivent être accordés à l’utilisateur, énor-

mément de possibilités doivent être implémentées. Cependant, certaines options ne sont pas compatibles, et il fallut avant tout les identifier pour simplifier la création de l’interface appelé bdrextract.

L’utilisation de l’interface, et d’une manière générale bdrextract, est détaillée en annexe, dans le Manuel Utilisateur. Vous trouverez également en annexe la Documentation technique de tous le codage réalisé pendant mon stage.

3.2.1 Description de l’interface

Pour résumer, une extraction se déroule en trois étapes qui peuvent être accom- plies dans un ordre quelconque:

1 I,

1. choisir la banque puis les images sur lesquelles vous désirez travailler ;

2. choisir le type d’extraction à effectuer et en régler les paramètres ;

3. choisir le nom du fichier de sortie.

Pour respecter cela, j’ai donc essayer de créer trois parties au niveau de l’interface.

Les banques, les images

Pour mémoriser d’une session à l’autre la liste des banques accessibles depuis bdrextract, il a été nécessaire de créer le fichier .badora, propre à chaque utili- sateur, contenant cette liste, ainsi que la banque active lors de la fin de la dernière session. On y trouve également, plus accessoirement, les couleurs des principaux éléments de l’interface, que l’utilisateur peut choisir à sa guise.

3.2. LE TRAVAIL R I ~ A L I S ~ 13

L’utilisateur peut, depuis une fenêtre spéciale de bdrextract modifier sa liste de banques, qui sera automatiquement sauvegarder dans .badora pour la prochaine session. Le champ Banques du menu Entrée est également mis à jour puisque c’est là qu’il va pouvoir choisir une nouvelle banque de travail.

En ce qui concerne les images, l’utilisateur peut choisir plusieurs images, de veilles différentes, mais d’une même banque. Pour cela, il dispose d’une fenêtre, dont une partie est réservée au parcours de la banque qui peut être vue comme une arborescence. Les images retenues sont concaténées dans l’autre partie de la fenêtre. Pour faciliter le choix des images, l’utilisateur peut se servir de filtres, qui imposent certaines caractéristiques aux images pour être retenues.

Pour donner une idée des temps de traitement qui l’attendent, le nombre d’images sélectionnées est affiché dans la fenêtre.

Définir des ensembles de points

Pour une plus grande conviviaIité, l’utilisateur peut définir les éléments qu’il souhaite extraire à la souris, directement sur l’image radar voulue qui s’affiche à l’écran. Certaines définitions pouvant être fastidieuses à refaire, il a la possibilité de les sauvegarder sur disque sous forme de listes des coordonnées. Ce système permet d’utiliser des fichiers de coordonnées déjà existants sans trop de modifications.

Cette même souplesse a été prévue pour tous les paramètres de l’application, qui peuvent être sauvegardés et restaurés.

Les extractions et leurs paramètres

L’extraction respecte quasiment les exigences initiales. Seule la suppression des valeurs en dehors de la surface à extraire n’est pas implanté dans la version actuelle. Ceci mis à part, les quatres types d’extraction fonctionnent, avec leurs options.

Pour I’extraction de surface, il est possible de définir un domaine d’étude, c’est-à- dire la région du scope radar dans laquelle des valeurs peuvent être extraitesl cette zone étant invariante pour toute les images d’une même extraction. L’utilisateur peut ensuite définir sa surface, à l’intérieur du domaine, et même la redéfinir à chaque image. Voir un exemple d’extraction de surface en annexe.

Les formats de sortie

Parmis les huit formats de sortie initialement prévus, seuls quatres sont opéra- tionnels: FTS 12, FTS 21, Excel et Spyglass.

3.2.2 Les programmes d’extraction

L’extraction n’as pas pu être paramétrée par le type d’extraction à réaliser, car tous les types sont bien distincts : j’ai donc créer quatres programmes d’extraction séparés.

14 CHAPITRE 3. LE PROGRAMME BDREXTRACT

’ Pour que le script Tcl puisse contrôler l’avancement des ces programmes, il a été nécessiare d’utiliser une redirection de l’entrée et de la sortie des routines d’extraction. Ainsi, les programmes C et Tcl se passe la main tour à tour, ce qui permet notament à bdrextract de remetre à jour certaines de ces variables, et d’arrêter l’extraction entre deux images, si l’utilisateur le désire.

15

Conclusion

Grâce à mon stage de première année, j’ai pu effectuer ce stage dans un laboratoi- re et ainsi me permettre de comparer la recherche à l’ingénérie. En fait, le contexte de travail est plus agréable, plus libéral qu’en entreprise, mais le travail lui-même reste aussi prenant.

Ce fut donc une expérience enrichissante pour moi, d’autant plus que j’ai pu apprendre une nouvelle méthode de programmation grâce au langage Tcl/Tk: la programmation pilotée par évènements, donc en temps réel, dont les concepts sont très différents de la programmation traditionnelle. Ceci m’a permis de mettre en application le cours de Systèmes de cette année et de conforter mon choix de l’option Systèmes Distribués et Temps Réel pour la 3ème année.

C’est égalmement la première fois que je me suis plongé dans un code aussi gros que l’application BADORA ce qui m’a permi de me rendre compte à quel point des programmes structurés et commentés sont utiles pour la rapidité de compréhension.

Enfin, j’ai trouvé très intéressant le fait de construire un logiciel en collaboration avec les futurs utilisateurs, non imformaticiens. Sans la mise en commun de connais- sances en informatique et en hydrologie, un tel logiciel n’aurai pas été faisable.

16 CHAPITRE 3. LE PROGRAMME BDREXTRACT

17

Annexes

Un exemple d’image PPI et RHI

Un exemple d’extraction de surface

Le manuel utilisateur de bdrextract

La documentation technique de bdrextract

18 CHAPITRE 3. LE PROGRAMME BDREXTRACT

Image PPI

Image RHI

45

30 ! I !

50 1 O0 I

3.2. LE TRAVAIL RhALISl?

Exemple d’extraction de surface

Image initiale

Définition du domaine Ré sul t at

19

b

20 CHAPITRE 3. LE PROGRAA4hdE BDREXTRACT

Définition de la surface Résultat

Définition du masque Résultat

3.2. LE TRAVAIL RI~ALISI~

Avec classe de distance (entre 100 et 200 km)

Avec correction en calibration et en atténuation

21

I !