# Automatisation d'une chaîne de traitement pour la détection précoce d'incendie à partir de données Meteosat Seconde Generation

Sébastien Peillet

► To cite this version:

Sébastien Peillet. Automatisation d'une chaîne de traitement pour la détection précoce d'incendie à partir de données Meteosat Seconde Generation. Géographie. 2016. hal-04198726

HAL Id: hal-04198726

https://hal.univ-reunion.fr/hal-04198726

Submitted on 7 Sep 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
Université de Toulouse

**MASTER 2 GEOMATIQUE**

« **Science de l'Information Géoréférencée** pour la **Maîtrise de l'environnement et l'Aménagement des territoires** » (SIGMA)
http://sigma.univ-toulouse.fr

**RAPPORT DE STAGE**

# AUTOMATISATION D'UNE CHAINE DE TRAITEMENT POUR LA DETECTION PRECOCE D'INCENDIE A PARTIR DE DONNEES METEOSAT SECONDE GENERATION

## PEILLET Sébastien

Université de la Réunion – UMR Espace-Dev

<figure><img src="image_1.png" /></figure>

Maîtres de stage : Pr. Télesphore Brou et Christophe Révillion

Tuteur-enseignant : Sébastien LeCorre

<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

seas-oi

— Reuniwatt —

Septembre 2016
# Résumé

Plus le délai d'intervention sur un incendie est long, plus celui-ci risque de devenir incontrôlable et plus grandes seront les conséquences sur l'environnement. La Réunion a donc souhaité se doter d'un système de détection précoce des incendies en raison de leur fréquence dans la zone de l'océan Indien. Pour cela, elle mise sur la télédétection qui permet de détecter les anomalies thermiques. Pour créer un système opérationnel, les données de télédétection doivent être actualisées le plus fréquemment possible. Les données Meteosat Second Generation ont ainsi été sélectionnées pour l'intervalle de temps de quinze minutes entre chaque acquisition. Une chaîne de traitement en Bash shell et Python 2.7 a été créée pour la détection d'incendies en temps réel, depuis l'acquisition des données MSG jusqu'à la publication des alertes. Celle-ci s'exécute en cinq minutes ce qui permet une réactivité importante du système. Les tests de la chaîne de traitement ont été menés en utilisant les données LRIT (5 canaux disponibles, trois heures d'intervalle entre les acquisitions) sur l'Afrique subsaharienne, en prévision du déplacement d'un satellite MSG sur la zone de l'océan Indien. Ces tests ont révélé un résultat de 85 % de bonnes détections, les 15 % restants étant soit de fausses alertes avérées, soit des alertes impossibles à confirmer ou infirmer. L'utilisation des données HRIT (22 canaux disponibles, quinze de minutes d'intervalle entre les acquisitions) a également été testée avec un résultat de 91 % de bonnes détections. Les alertes sont consultables en direct sur un portail internet.

Mot-clés: Incendies, télédétection, surveillance de l'environnement, chaîne de traitement automatisée, Meteosat Second Generation, SEVIRI

# Abstract

Wildfires are one of the biggest threat for the environment and its consequences depend on the delay between ignition and detection of the wildfire. A fast intervention prevents fire to become larger. Thus, the Reunion Island wishes to develop a fire detection system, based on remote sensing. Indeed the Indian ocean area is heavily impacted by wildfires. High temporal resolution data are required to get a operational warning system. For this purpose, a processing chain has been develop to detect wildfires using Meteosat Second Generation data, which are available every quarter of an hour. The processing chain fulfill the detection in five minutes from downloading until results publication, using Bash shell and Python 2.7 scripts. The accuracy of the processing chain has been tested on the sub-Saharan Africa because there are still no MSG satellite for Indian ocean. The MSG-1 satellite will be reorbitated above Indian ocean in september 2017. The test of the LRIT data (5 channels available, three hourly) reveals a result of 85 % right detections. The 15 % left are false alarms or detections that are impossible to confirm or invalidate. HRIT data (22 channels, 1/4 hourly) has also been tested and obtain a result of 91 % right detections. The results are broadcasted in real time on a web mapping site.

Keywords: wildfire, remote sensing, fire monitoring, automatic processing chain, Meteosat Second Generation, SEVIRI
# Sommaire

<table><tr><td>Résumé</td><td>3</td></tr><tr><td>Abstract</td><td>3</td></tr><tr><td>Sommaire</td><td>4</td></tr><tr><td>Remerciements</td><td>5</td></tr><tr><td>Sigles et abréviations</td><td>6</td></tr><tr><td>Introduction</td><td>7</td></tr><tr><td>I. Contexte</td><td>9</td></tr><tr><td>A) Projet de recherche TAIMPO, UMR ESPACE-DEV</td><td>9</td></tr><tr><td>B) Lieu d'accueil et partenaires</td><td>10</td></tr><tr><td>C) Évaluation de l'existant et des besoins</td><td>11</td></tr><tr><td>II. Développement de la chaîne de traitement</td><td>17</td></tr><tr><td>A) Présentation générale de la chaîne de traitement</td><td>17</td></tr><tr><td>B) Acquisition des données en temps réel et pré-traitement</td><td>20</td></tr><tr><td>C) Détection des anomalies thermiques</td><td>23</td></tr><tr><td>D) Valorisation des résultats et visualisation</td><td>32</td></tr><tr><td>E) Développement d'une interface utilisateur</td><td>34</td></tr><tr><td>III. Perspectives</td><td>36</td></tr><tr><td>A) Déplacement du satellite MSG-1 sur l'Océan Indien</td><td>36</td></tr><tr><td>B) Utilisation des HRIT</td><td>37</td></tr><tr><td>C) Optimisation de la chaîne de traitement</td><td>38</td></tr><tr><td>D) Communication auprès des acteurs de la lutte contre le feu</td><td>38</td></tr><tr><td>IV. Bilan</td><td>40</td></tr><tr><td>Conclusion</td><td>41</td></tr><tr><td>Bibliographie</td><td>42</td></tr><tr><td>Table des matières</td><td>43</td></tr><tr><td>Table des illustrations</td><td>45</td></tr><tr><td>Table des annexes</td><td>46</td></tr></table>
## Remerciements

Je souhaite remercier tout ceux qui m'ont soutenu au cours de ces six derniers mois et qui m'ont aidé à réaliser ce stage :

Christophe REVILLION et Télesphore BROU qui m'ont encadré à la station SEAS-OI pendant toute la durée de mon stage, et même au-delà de leur obligation contractuelle. Je les remercie pour m'avoir permis de réaliser ce stage, de m'avoir conseillé tout au long de celui-ci, y compris pour l'écriture de ce rapport.

L'entreprise Réuniwatt, pour avoir participé à l'élaboration du stage, et plus particulièrement Nicolas SEBASTIEN qui s'est investi dans la réalisation du stage. Je remercie également Mathieu TURPIN avec qui j'ai eu plaisir à échanger sur le traitement des données.

Sébastien LECORRE, mon tuteur-enseignant, pour la pertinence de ses remarques au cours des échanges que nous avons eu. Sa franchise est pour moi toujours une manière de me pousser en avant.

L'ensemble du personnel de la station SEAS-OI à la Région, à l'Université, à l'IRD ou encore d'ailleurs. La station m'a semblé être un terreau fertile aux idées et au partage de connaissances. Un merci particulier à Aurélie SAND qui s'est également intéressé à mon stage et y a apporté de bonnes idées.

L'équipe de développement Pytroll, votre travail m'a beaucoup aidé au cours de mon stage. Et je remercie notamment Martin RASPAUD qui m'a guidé dans les premiers moments d'utilisation des outils Pytroll.

Artadji ATTOUMANE, doctorant à SEAS-OI mais également mon colocataire durant ces quelques mois. Merci pour l'accueil que tu m'as donné, et je ne manquerai pas de venir aux Comores si l'occasion se présente. Bon courage pour la thèse !

Les autres stagiaires de SEAS-OI, avec qui j'ai beaucoup partagé, tant au travail que durant les temps libres.

Mention spéciale à Mathilde ANDRE, Jérémy COMMINS et Évelyne PAYET qui m'ont fait découvrir l'île au fil des randonnées et balades. Mon séjour à La Réunion n'aurait pas été le même sans vous.

Je remercie bien évidemment ma famille, mes parents, mon frère et ma sœur, qu'il me tarde de retrouver en rentrant en métropole.

Et pour finir, merci à Laura MEGEVAND, qui m'a toujours soutenu et à qui j'ai fait part de mes avancées jour après jour alors que la distance nous séparait. Les sept longs mois entre Gabon et Réunion prendront fin bientôt.
Sigles et abréviations

API Applicative Programming Interface (interface de programmation applicative)

AVHRR Advanced Very-High-Resolution Radiometer

BT Brightness Temperature (température de surface)

FAO Food and Agriculture Organization

FTP File Transfer Protocol

HRIT High Rate Image Transmission

HSRS Hotspot Recognition System

IRD Institut de Recherche pour le Développement

LRIT Low Rate Image Transmission

MFG Meteosat First Generation

MODIS Moderate-resolution Imaging Spectroradiometer

MSG Meteosat Second Generation

PF Potential fire (feu potentiel)

PHP Hypertext Preprocessor

SEAS-OI Surveillance de l'Environnement Assistée par Satellite pour l'Océan Indien

SEVIRI Spinning Enhanced Visible and InfraRed Imager

TAIMPO Télédétection Appliquée à l'Imagerie Météorologique pour le développement de Produits Opérationnels

TF True fire (feu véritable)

UMR Unité Mixte de Recherche

VIIRS Visible Infrared Imagery Radiometer Suite

WMS Web Map Service
Introduction

La prévention et la réactivité face aux événements accidentels, tels les incendies ou les inondations, sont des éléments primordiaux pour assurer la protection de l'environnement et des personnes. De plus en plus d'outils émergent pour pourvoir à ce besoin et la télédétection en fait partie. Au sens large, celle-ci correspond au fait de réaliser des mesures à distance, soit aéroportée (avions, drones), soit spatiale (satellites d'observation de la Terre), sur des portions ou la totalité du spectre électromagnétique. En effet chaque corps est à la fois émetteur et réflecteur d'ondes électromagnétiques qui peuvent révéler sa nature. Le potentiel de la télédétection comme système de surveillance de l'environnement a ainsi motivé le lancement de satellites depuis les années 1950. Aujourd'hui, le nombre de données disponibles est croissant mais les systèmes de surveillance utilisant ces données en temps réel restent peu nombreux<fnref n="1" />.

Parmi les événements accidentels présentant un danger important, les incendies sont une préoccupation majeure pour de nombreux pays, tant pour des raisons écologiques que pour la sécurité des personnes. D'un point de vue environnemental, les conséquences des incendies sont importantes. En effet ces derniers provoquent une dégradation des milieux végétatifs et l'érosion des sols, favorisent les phénomènes de nuées d'insectes et participent au réchauffement climatique dû au CO2 relâché. D'un point de vue humain, le nombre de morts causées par les incendies reste difficile à déterminer, mais ils sont aussi responsables de détériorations matérielles (habitations, infrastructures) et affectent également la sécurité alimentaire des pays.

Ainsi la détection des incendies ou anomalies thermiques (hot spot) par télédétection a été mise en place très tôt puisque dès 1978 le satellite TIROS-N (Pelletier C., 2001) fut mis en orbite avec la première version de capteur AVHRR (Advanced Very-High-Resolution Radiometer) capable de détecter les anomalies thermiques (Mbow C., 2000). L'AVHRR restera pendant longtemps le capteur de référence dans ce domaine, équipant successivement les différentes générations de satellites américain TIROS et NOAA. Plus récemment, différents capteurs se sont succédé dans le domaine de la détection des anomalies thermiques parmi lesquels VIIRS (Visible Infrared Imagery Radiometer Suite), MODIS (MODerate-resolution Imaging Spectroradiometer), HSRS (Hotspot Recognition System) ou encore SEVIRI (Spinning Enhanced Visible and InfraRed Imager), le capteur des satellites Meteosat Second Generation (MSG).

La zone de l'océan Indien est un espace particulièrement affecté par les incendies. En effet un rapport de la FAO<fnref n="2" /> (Food and Agriculture Organisation) de 2006 montre que les pays les plus touchés se trouvent en l'Afrique de l'Est (873 840 km<fnref n="2" /> brûlés en 2000, soit 15 % de la superficie totale de la zone), en Afrique australe (677 123 km<fnref n="2" /> brûlés, soit 11,5% de la superficie totale de la zone) ou encore en Asie du

<footnote n="1">1. http://southernafrica.afis.co.za</footnote>

<footnote n="2">2. ftp://ftp.fao.org/docrep/fao/009/a0969e/A0969E00.pdf</footnote>
Sud. Le développement de solutions d'alertes précoces peut donc particulièrement intéresser les pays de ces régions.

Ce type de problématique a motivé le lancement du projet TAIMPO (Télédétection Appliquée à l'Imagerie Météorologique pour le développement de Produits Opérationnels) de l'UMR Espace-Dev de l'Université de La Réunion, dans lequel ce stage s'inscrit. Le projet vise à créer des produits opérationnels issus de l'acquisition de données de télédétection en temps réel. Parmi diverses thématiques possibles, la création d'un produit de détection précoce des incendies a été sélectionnée. En effet La Réunion s'y intéresse particulièrement en raison de la fréquence des feux dans la région. Elle cherche ainsi à mettre en place des outils permettant d'améliorer la surveillance opérationnelle. Le principal objectif du stage est de réaliser une chaîne de traitement automatisée pour l'acquisition de données à très haute répétitivité et leur traitement afin de suivre les départs de feux en temps réel.

Ce mémoire fera tout d'abord état de la problématique de la détection des incendies ainsi que des besoins exprimés par la structure d'accueil. Il sera ensuite fait mention des méthodes et technologies utilisées pour mener à bien le projet. Les résultats ainsi que leur méthode de validation seront présentés et feront l'objet d'une analyse critique. Un bilan personnel sera également dressé sur le déroulement du stage et les compétences développées au cours de ce dernier.
# I. Contexte

## A) Projet de recherche TAIMPO, UMR ESPACE-DEV

### 1) Descriptif du projet TAIMPO

Financé par la région Réunion, TAIMPO (Télédétection Appliquée à l'Imagerie Météorologique pour le développement de Produits opérationnels) est un projet multipartite entre l'UMR Espace-Dev (Université de La Réunion) et la société Réuniwatt. Ce projet a pour objectif d'améliorer la surveillance de l'environnement par télédétection dans l'océan Indien, notamment par l'utilisation de données météorologiques et l'enrichissement du panel de données de la station SEAS-OI. La haute répétitivité temporelle de l'imagerie météorologique (une acquisition toutes les quinze minutes pour les satellites MSG) constitue un atout pour la surveillance de l'environnement. En effet, peu de systèmes de surveillance sont aujourd'hui opérationnels malgré l'afflux croissant de données. L'imagerie météorologique permet la détection rapide d'événements accidentels tels les incendies, les inondations ou encore les pollutions maritimes/atmosphériques. La basse résolution spatiale de l'imagerie météorologique (3 km de côté pour les satellites MSG) peut ensuite être complétée par d'autres images issues de satellites à haute résolution spatiale comme Landsat (30 m et 15 m) et Spot 5 (10m et 2,5) afin de caractériser les impacts sur l'environnement.

Le projet se décompose en 2 volets principaux. Un premier volet (technique) qui consiste à assurer l'acquisition des données météorologiques (MSG) en temps réel. Le second volet (thématique) vise la création de produits opérationnels à partir des données acquises. A terme, le projet devra aboutir à la mise en place de systèmes d'alertes automatisés.

### 2) Organisation du stage

Le stage a pour objectif d'automatiser l'acquisition des données et de mettre en place un prototype de système de détection d'incendies. A terme, ce système d'alerte permettrait d'assurer la surveillance de la zone de l'océan Indien, pour la région Réunion et les pays partenaires.

Un planning de stage fut établi au début du stage, prévoyant trois phases majeures. Dans un premier temps une analyse bibliographique a été réalisée, afin d'approfondir la question de la télédétection des incendies et envisager les solutions possibles. Cette analyse a permis dans un second temps la conception de la chaîne de traitement automatisée et l'évaluation de la qualité des données. La dernière partie du stage concernait la mise en valeur des résultats, par la création d'une interface de visualisation, et de la chaîne de traitement elle-même, par le biais d'une notice utilisateur. Le déroulement précis du stage est illustré par un diagramme de Gantt<fnref n="3" />.

<footnote n="3">3. Annexe 1</footnote>
## B) Lieu d'accueil et partenaires

Le pôle de Surveillance de l'Environnement Assistée par Satellite pour l'Océan Indien (SEAS-OI) est une station d'acquisition et de traitement d'images satellites mise en service en juillet 2012 à la fois par UMR ESPACE-DEV (IRD), la région Réunion et l'Université de la Réunion. Basé à Saint-Pierre de la Réunion, SEAS-OI permet la réception de données sur la zone de l'océan Indien comprenant l'Afrique de l'Est, l'Afrique Austral ainsi que l'ensemble des îles de l'océan Indien occidental (illustration 1). Les données acquises par SEAS-OI sont accessibles<fnref n="4" /> pour les institutions publiques et les laboratoires de recherches travaillant sur l'océan Indien occidental. La station réceptionne des images satellites RADAR et optiques haute résolution.

<figure><img src="image_4.png" /><figcaption>Illustration 1: Zone d'acquisition de l'antenne SEAS-OI<fnref n="4" /></figcaption></figure>

SEAS-OI est aussi un pôle de recherche et de valorisation en télédétection<fnref n="5" /> et géomatique. Les activités de recherche se décomposent en trois axes principaux : la formation universitaire, le portage et le pilotage de projets opérationnels autour de l'amélioration de la couverture de l'imagerie satellitaire et l'accueil de chercheurs, doctorants et stagiaires. De nombreux programmes de recherche y sont adossés, c'est le cas du projet TAIMPO.

L'UMR ESPACE-DEV est une Unité Mixte de Recherche intégrant des chercheurs et des enseignant-chercheurs de l'IRD, l'Université Montpellier 2, l'Université de La Réunion, l'Université de la Guyane, l'Université des Antilles et l'Université de Nouvelle-Calédonie. L'Unité développe des recherches sur les dynamiques spatiales, dans ce but, elle met au point des méthodologies en télédétection spatiale et en intégration des connaissances multidisciplinaires<fnref n="6" />.

L'entreprise Réuniwatt est une start-up spécialisé dans les énergies renouvelables. Basée à La Réunion depuis 2010, elle se focalise sur la prévision

<footnote n="4">4. http://www.seas-oi.org/web/guest/catalogue</footnote>

<footnote n="5">5. http://www.seas-oi.org/</footnote>

<footnote n="6">6. http://www.espace.ird.fr/</footnote>
d'energie solaire, les systèmes d'informations climatiques et l'expertise énergétique.
Investi dans la recherche et le développement, elle participe notamment à des projets
avec des organismes de recherches.

C) Évaluation de l'existant et des besoins

1) Détection d'incendies par télédétection

* Les fondamentaux de la détection d'incendies

La détection d'incendies par télédétection est un sujet largement documenté. Celle-ci est mise en application depuis les années 1980. Pour comprendre comment détecter les anomalies thermiques liées aux incendies, il faut analyser quelles en sont ses propriétés. Ici on ne cherche pas à identifier un élément, tel que l'eau, mais une réaction chimique puisque la combustion est une oxydation réalisée entre un combustible et un comburant. Il faut donc faire l'impasse sur les propriétés spectrales des éléments de la réaction étant donné que ces éléments peuvent différer (bien qu'ici on observera presque exclusivement des feux de forêt). Il faut se focaliser sur les propriétés de la réaction chimique. Une combustion est caractérisée par l'importante quantité d'énergie qui s'en dégage, sous forme de lumière (forte émissivité dans le spectre visible) mais surtout sous forme de chaleur (très forte émissivité dans l'infrarouge thermique).

Cette énergie libérée est, selon la loi de Stefan-Boltzmann (illustration 2), liée à la température en kelvin, tel que M=σ.ε.T⁴ (σ étant la constante de Stefan-Boltzmann, ε un coefficient d'émissivité, et T la température en degré Kelvin). De plus la distribution de luminance du rayonnement thermique se fait en fonction de la température selon la loi de Planck (illustration 2). Pour finir la loi du déplacement de Wien nous apprend que la longueur d'onde du maximum d'émissivité est inversement proportionnelle à sa température.

<figure><img src="image_5.png" /><figcaption>Illustration 2: Loi de Stefan Boltzmann (gauche) et loi de Planck (droite)</figcaption></figure>

Par ces trois lois, on peut donc en déduire qu'un pixel de feu aura une signature
spectrale atypique (fort contraste avec les autres pixels) sur une image de
télédétection dans le canal approprié. La température d'un feu peut se trouver entre
800 K et 1200 K pour les plus intenses ainsi son maximum d'émissivité se trouve entre
3,5 µm et 4 µm (Pelletier C., 2001). En recherchant une émissivité anormale entre ces bornes, on peut détecter les anomalies thermiques dues aux incendies.

Il est ainsi indispensable d'avoir un capteur situé dans le Moyen Infrarouge (MIR). Le plus souvent le capteur est situé aux alentours de la longueur d'onde 3,9µm comme la bande 21 du capteur MODIS (Movaghati S. et al, 2008), la bande 3 du capteur AVHRR, la bande 2 de GOES IMAGER ou encore la bande 4 du capteur SEVIRI (Manyangadze T., 2009). Cette longueur d'onde particulière est utilisée du fait de la fenêtre spectrale laissée entre les émissions thermiques solaires (6000 K) et les émissions de la Terre (moyenne terrestre: 287 K), dont les maximums sont situés respectivement 0,5 µm et 9,7 µm (illustration 3). Le canal 3,9 µm ne subit que peu de perturbations issues de ces deux sources de rayonnement même si elles existent. Il faut notamment noter que les signaux de jour et de nuit seront différents étant donné que le rayonnement solaire n'est présent que de jour. La détection d'anomalie thermique dépend donc de la température relevée à un pixel par rapport à la température normale du globe. Les seuils limites diffèrent selon les recherches et dépendent également de la taille du pixel. Plus un pixel représente une grande superficie moins un feu en influencera la température.

<figure><img src="image_6.png" /><figcaption>Illustration 3: Optimum radiatif du soleil et de la Terre
(source Manyangadze T., 2009)</figcaption></figure>

De plus le canal 3,9µm est plus sensible aux variations thermiques que les autres canaux, en particulier les canaux autour de la longueur d'onde 10,8 µm (illustration 4). La différence de température mesurée entre ces deux canaux sert également d'indice de détection des incendies.
<figure><img src="image_7.png" /><figcaption>Illustration 4: Réponses des canaux 3,9 µm et 10,8 µm selon la part de pixel couvert par un feu (source Manyangadze T., 2009)</figcaption></figure>

Nous nous pencherons sur les seuils de détection au cours de la prochaine partie.

## Imagerie haute et basse résolution, deux finalités différentes

Les détections d'incendies par télédétection sont à la fois réalisables par les mesures de satellites héliosynchrones ou géostationnaires. Les premiers ont une orbite basse permettant ainsi d'avoir une meilleure résolution de pixel, à l'instar de Bird (370 m pour le moyen-infrarouge), et leurs orbites passent au-dessus de la même latitude à la même heure locale de la prise de vue. Ces satellites peuvent détecter les plus petits feux qui existent. Par exemple, le record du plus petit feu pour le satellite Bird correspond à un feu de 12 m² de jour et de 4m² de nuit (Zhukov B. et al, 2004). La détection des incendies par ces satellites peut être utile pour observer précisément l'étendue d'un incendie. Cependant, la faible résolution temporelle empêche de réaliser un réel suivi. Pour cette raison, le suivi des incendies se fait davantage par l'utilisation de drones ou aéronefs (Crombette P., 2010 ; Lewyckyj N. et al, 2007).

Les satellites géostationnaires sont quant à eux utilisés pour la surveillance et la détection précoces des feux. Grâce à leur orbite haute, ces satellites restent à la même position relative par rapport à la Terre. Cela leur permet de surveiller en continu une zone particulière : l'Europe et l'Afrique pour les Meteosat-8 et 9 (une acquisition toutes les quinze minutes), et l'océan Indien pour Meteosat-7 (une acquisition toutes les demi-heures) par exemple. En contrepartie ces satellites ont une orbite haute, ce qui les empêche d'avoir une résolution pixel en deçà du kilomètre (panchromatique MSG : 1km ; canaux thermiques MSG : 3 km). S'ils permettent de détecter les anomalies thermiques, ils ne permettent pas d'avoir la localisation précise des incendies.

Le capteur MODIS présents sur les satellites héliosynchrones américains Aqua et Terra est admis par la communauté scientifique comme une référence dans le domaine de la détection des incendies. En effet l'efficacité du capteur MODIS a été
éprouvée et l'algorithme de détection a été amélioré au fil des années (Wang W. et al, 2007).

## 2) Données accessibles et utiles

SEAS-OI dispose d'imageries optiques (SPOT 5, 6, 7) et RADAR (RADARSAT-2) de haute résolution. Les satellites SPOT utilisent des capteurs dans la partie visible du spectre électromagnétique ainsi que dans le proche infrarouge (0,78µm - 3µm) tandis que RADARSAT-2 effectue des mesures dans les micro-ondes, la longueur d'onde centrale du capteur étant de 5,5cm. Ces satellites ne sont donc pas adaptées à la détection d'incendie car, comme énoncé précédemment, les longueurs d'ondes utiles font partie de la partie infrarouge du spectre électromagnétique (illustration 5).

<figure><img src="image_8.png" /><figcaption>Illustration 5: Canaux utiles pour la détection d'incendies dans le spectre électromagnétique</figcaption></figure>

Par ailleurs, la station SEAS-OI est dotée d'une licence auprès d'Eumetsat, organisme européen gestionnaire des satellites Meteosat. Cette licence permet l'accès aux données Meteosat-7 et MSG à trois heures d'intervalle. La licence peut être étendue pour obtenir des données à un quart d'heure d'intervalle.

Les produits feux MODIS et VIIRS sont accessibles à la fois en format ESRI shape et par service WMS via le portail Earthdata<fnref n="7" /> de la NASA.

## 3) Besoins exprimés

La lutte contre les incendies repose sur deux axes, à savoir la prévention et la vitesse de prise en charge des incendies. C'est sur ce deuxième axe que se place le projet, avec la création d'un système de détections précoces des incendies. Une intervention rapide permet souvent d'éviter que les incendies ne deviennent incontrôlables. L'utilisation de la télédétection permet en outre de surveiller de larges territoires où l'on ne peut pas déployer de moyens humains en permanence. Le système d'alerte doit donc répondre à deux impératifs. Il doit être capable de détecter les incendies avec une marge d'erreur acceptable et fonctionner en semi temps réel.

Nous avons déjà mentionné le fait que le produit Active Fire du capteur MODIS est une référence en la matière. Cependant la répétitivité temporelle de ces acquisitions reste insuffisante pour assurer une surveillance constante et efficace, même si celle-ci est relativement haute pour des satellites héliosynchrones (entre trois à neuf heures). Ces données seront cependant utilisées à titre de comparaison avec les données que nous produirons.

<footnote n="7">7. https://earthdata.nasa.gov/earth-observation-data/near-real-time/firms/active-fire-data</footnote>
Il a semblé assez évidemment que l'imagerie à très haute répétitivité temporelle issue de satellites géostationnaires était à privilégier, à l'instar des satellites MSG. D'ailleurs, l'utilisation des données MSG convient tout à fait à la détection d'incendie (présence des canaux de longueur d'onde 3,9 µm et 10,8 µm). Il a donc été décidé de réaliser le montage de la chaîne de traitement à partir de ces données.

Dans un premier temps, la licence de données à trois heures d'intervalle a été conservée pour la phase test, mais une évolution vers la licence à un quart d'heure d'intervalle est envisageable pour rendre le système d'alerte plus réactif. Seul bémol, aucun satellite MSG ne couvre actuellement la zone de l'océan Indien. Néanmoins, MSG1 va être déplacé à 41,5°E de longitude en septembre 2016. La phase test a ainsi été effectuée sur la zone de l'Afrique subsaharienne étant donné que le satellite utilisé (MSG3) est actuellement en orbite sur le méridien de Greenwich.

Une fois l'algorithme de détection validé, les résultats devront être consultables facilement. A cet effet, une interface cartographique doit être réalisée. L'affichage des alertes incendies doit être synchronisé avec la chaîne de traitement automatisée afin de garantir l'accès en temps réel des dernières détections d'incendies. De plus l'interface de visualisation doit également permettre de réaliser des requêtes pour parcourir la base de données d'incendies dans le temps.

Afin de conduire le développement de la chaîne de traitement une liste des objectifs généraux et des objectifs spécifiques a été établie (illustration 6). Celle-ci a été créée à partir des besoins exprimés par les encadrants du stage.
## Objectif généraux

<figure><img src="image_9.png" /></figure>

1. Automatiser
la chaîne de
traitement

1.1 Etudier les horaires de publication des données

1.2 Configurer la table de cron de l'utilisateur Linux:

<figure><img src="image_10.png" /></figure>

2. Acquérir les
données MSG

2.1 Réaliser une connexion FTP

2.2 Identifier les derniers fichiers mis en ligne

2.3 Télécharger les données:

<figure><img src="image_11.png" /></figure>

3. Classer
les données

3.1 Concevoir l'architecture de l'applicatior

3.2 Classer les fichiers par date

<figure><img src="image_12.png" /></figure>

4. Traiter les
données et
détecter les
incendies

4.1 Créer des rasters géoréférencés

4.2 Détecter les pixels de feux potentiels

4.3 Confirmer les pixels de feux potentiels

<figure><img src="image_13.png" /></figure>

5. Valoriser les
données produites

5.1 Vectoriser les détections

5.2 Créer et entretenir une BD incendie:

5.3 Créer une interface de visualisation des données

<caption>Illustration 6: Les objectifs du stage au sein du projet TAIMPO</caption>

## Objectif spécifiques
# II. Développement de la chaîne de traitement

## A) Présentation générale de la chaîne de traitement

La chaîne de traitement est disponible en téléchargement<fnref n="8" />.

### 1) Environnement général

Lors de la conception de la chaîne de traitement, il n'y avait qu'une contrainte majeure, à savoir que nous utilisons des données MSG. En effet nous avons vu précédemment que l'imagerie MSG semble être la plus adaptée pour répondre aux besoins du projet.

Cette contrainte pose deux questions principales. Comment obtenir les données MSG et comment la traiter ?

La première question trouve rapidement une réponse. Les données MSG sont disponibles en fichiers télémétriques, LRIT/HRIT compressé, sur le service FTP d'Eumetsat<fnref n="9" />, jusqu'à 48h. Une connexion FTP est donc indispensable dans le déroulement de la chaîne de traitement.

La deuxième question est plus complexe. Les fichiers obtenus sont des LRIT/HRIT compressés. Il s'avère que la décompression de ces fichiers ne peut être assurée que par un logiciel d'Eumetsat nommé *Public Wavelet Transform Decompression Library Software*<fnref n="10" />. Ce logiciel n'est disponible que sous système Linux et doit être compilé par l'utilisateur. Par ailleurs, il existe quelques outils pour traiter les fichiers LRIT/HRIT. On peut citer d'un côté les logiciels MSG DATA MANAGER et XRIT2PIC qui se sont spécialisés dans la visualisation mais qui ne permettent pas de manipuler les données, et d'un autre côté les bibliothèques de fonctions Pytroll, développées en Python, qui permettent de traiter et manipuler les données. Ce sont ces dernières qui ont été utilisées dans la chaîne de traitement.

En conséquence, la chaîne de traitement a été développée sur un système d'exploitation Linux. La distribution Ubuntu 14.04 a été sélectionnée car nous avions la garantie que les logiciels SIG libres seraient compatibles. De plus cela représentait une facilité pour la maintenance étant donné que la station SEAS-OI possède déjà des machines opérant sur la même distribution.

<footnote n="8">8. https://github.com/SebastienPeillet/firemsg</footnote>

<footnote n="9">9. oisftp.eumetsat.org</footnote>

<footnote n="10">10. Nécessite une licence Eumetsat</footnote>
## 2) Conception

* **Fonctionnement de la chaîne de traitement**

La chaîne de traitement est composée de différents scripts, écrits soit en Bash Shell (langage système Linux) soit en Python 2.7 (illustration 7). Le choix du langage Python a bien entendu été motivé par l'utilisation des bibliothèques de fonctions Pytroll. Python permet aussi l'utilisation des bibliothèques GDAL/OGR, référence dans la manipulation de données géographiques, raster ou vector.

La chaîne de traitement est décomposée en trois étapes successives, à savoir l'acquisition des données, la détection des anomalies thermiques et enfin la valorisation des résultats. Nous rentrerons dans le détail de chacune de ces étapes par la suite.

<figure><img src="image_14.png" /><figcaption>Illustration 7: Model builder de la chaîne de traitement</figcaption></figure>
* Architecture de la chaîne de traitement

Afin de faire fonctionner la chaîne de traitement, il a fallu élaborer une architecture globale (illustration 8), comme une application. En effet, les scripts ont besoin de chercher les sources des données, il fallait ainsi établir des chemins de stockage des fichiers. Le dossier principal, nommé firemsg, comprend quatre sous-dossiers. Le premier, Auto, a été créé pour répondre au besoin de stockage des fichiers et des sous-répertoires existent pour chacune des étapes de la chaîne de traitement. Le dossier cmd contient tous les scripts relatifs à la chaîne de traitement, ainsi que le fichier de configuration de l'application. Le troisième dossier PublicDecompWT est un répertoire dans lequel la compilation de l'outil d'Eumetsat peut être effectuée. En dernier, le dossier pytroll_config contient des fichiers de configuration des bibliothèques Pytroll. Ces derniers sont à placer dans le dossier d'installation de la bibliothèque mpop.

<figure><img src="image_15.png" /><figcaption>Illustration 8: Architecture de l'application firemsg</figcaption></figure>
## B) Acquisition des données en temps réel et pré-traitement

### 1) Automatisation de la chaîne de traitement

Le chaîne de traitement commence tout d'abord par l'acquisition des données. On cherche à obtenir les données dès que possible, afin d'avoir un système d'alerte le plus réactif possible.

A cet effet, un déclencheur (trigger en anglais) serait le dispositif le plus adapté. Celui-ci répondrait à la fonction suivante : « dès qu'une nouvelle donnée est disponible, lancer le téléchargement de celle-ci ». Malheureusement ce type de déclencheur n'est pas possible sur le serveur FTP d'Eumetsat.

Il a donc fallu opter pour un lancement périodique de la chaîne de traitement. Ceci peut facilement être mis en place sur Linux, grâce à la table de cron.

En observant les heures de mises en ligne des données sur le FTP d'Eumetsat, il est apparu que l'ensemble des données relatives à une prise de vue est disponible après un quart d'heure (illustration 9). Concernant les fichiers LRIT, ces derniers sont disponibles toutes les trois heures (ci-contre). La planification de tâche doit être effectuée dans le crontab en prenant en compte le décalage horaire :

<table><caption>Illustration 9: Heures de lancement de la chaîne de traitement (fuseau UTM+0)</caption><thead><tr><td>Heure de la prise de vue LRIT</td><td>Heure de lancement du traitement</td></tr></thead><tbody><tr><td>2h45</td><td>3h00</td></tr><tr><td>5h45</td><td>6h00</td></tr><tr><td>8h45</td><td>9h00</td></tr><tr><td>11h45</td><td>12h00</td></tr><tr><td>14h45</td><td>15h00</td></tr><tr><td>17h45</td><td>18h00</td></tr><tr><td>20h45</td><td>21h00</td></tr><tr><td>23h45</td><td>00h00</td></tr></tbody></table>

<table><caption>Illustration 10: Configuration du planificateur de tâche Linux pour le LRIT</caption><tr><td>m</td><td>h</td><td>dom</td><td>mon</td><td>dow</td><td>command</td></tr><tr><td>0</td><td>1,4,7,10,13,16,19,22</td><td>*</td><td>*</td><td>*</td><td>bash /home/user/firemsg/cmd/firemsg.sh</td></tr></table>

Ici le script firemsg.sh est programmé pour se lancer à zéro minutes (0) pour chaque heure indiquée (1,4,7,10,13,16,19,22), tous les jours (*) de tous les mois (*) peu importe le jour de la semaine (*)(illustration 10).

Pour télécharger les données HRIT, la configuration du planificateur de tâche est plus simple :

<table><caption>Illustration 11: Configuration du planificateur de tâche Linux pour le HRIT</caption><tr><td>m</td><td>h</td><td>dom</td><td>mon</td><td>dow</td><td>command</td></tr><tr><td>*/15</td><td>*</td><td>*</td><td>*</td><td>*</td><td>bash /home/user/firemsg/cmd/firemsg.sh</td></tr></table>

Il suffit de préciser de le lancer toutes les quinze minutes (*/15)(illustration 11)

Le script firemsg.sh est un script qui permet de lire les variables de configuration et de lancer les différents scripts les uns après les autres en suivant l'ordre de la chaîne de traitement.
## 2) Acquisition par ftp

La première étape de la chaîne de traitement consiste à télécharger les données. Il fallait pouvoir réaliser une connexion FTP sans qu'une présence humaine soit nécessaire pour identification. De plus il fallait pouvoir déterminer les fichiers les plus récents mis en ligne pour télécharger la dernière prise de vue.

Pour les LRIT, une prise de vue correspond à 42 fichiers. Dans le détail la séquence comprend deux fichiers d'en-tête, nommée EPI (epilogue) et PRO (prologue), et huit fichiers de segment par canal (cinq disponibles en LRIT). Les segments sont des découpes horizontales du globe terrestre. Il faut les huit segments pour reconstituer une vue entière du globe (illustration 12).

<figure><img src="image_16.png" /><figcaption>Illustration 12: Image du globe reconstituée à partir de LRIT, canal 3,9µm</figcaption></figure>

Les noms des fichiers sont normalisés (illustration 13). Par exemple « L-000-MSG3_-MSG3______-IR_039__-000005__-201606270545-C_ » peut être décomposé » :

<table><caption>Illustration 13: Formation des noms des fichiers de télémétrie MSG</caption><thead><tr><td>Décomposition</td><td>Signification</td></tr></thead><tbody><tr><td>L</td><td>Type du fichier (L pour LRIT, H pour HRIT)</td></tr><tr><td>000</td><td>Constante</td></tr><tr><td>MSG3</td><td>Catégorie du satellite</td></tr><tr><td>MSG3</td><td>Nom du satellite</td></tr><tr><td>IR_039</td><td>Dénomination du canal</td></tr><tr><td>000005</td><td>Segment du canal (ou EPI/PRO pour les fichiers d'en-tête)</td></tr><tr><td>201606270545</td><td>Concatenation de l'heure de prise de vue : 2016/06/27 à 05h45</td></tr><tr><td>C_</td><td>C_ pour compression, __ si décompressé</td></tr></tbody></table>

L'automatisation de la connexion FTP a été réalisée en shell, grâce à la commande ftp. Celle-ci requiert l'adresse de connexion ainsi que les identifiants fournis par Eumetsat. Afin que l'exécution des commandes se fasse lors de la connexion, elles ont été placées entre les bornes d'une condition EOF (End Of File). Cela permet notamment d'entrer les identifiants automatiquement lors de la
connexion. Il est également nécessaire de renseigner les arguments *prompt* et *binary* pour que l'interpréteur ne demande pas de confirmation à l'utilisateur et que les données soient téléchargées en binaire et non en ASCII. Ce dernier argument est nécessaire du fait du type de fichier téléchargé, ici des fichiers télémétriques codés en binaire.

Nous cherchons à obtenir la dernière prise de vue disponible. Cependant le nombre de commande est réduite lors d'une connexion FTP. Une recherche par heure de publication dans les fichiers disponibles n'est pas directement possible sur le serveur FTP. Il a fallu contourner le problème. Nous nous sommes servis de la présence de l'heure de prise de vue dans le nom des fichiers. Ainsi on retranscrit tous les noms des fichiers disponibles dans un fichier texte, lequel est lu par la suite ligne par ligne. Étant donné que l'heure est notée sous format année, mois, date, heure et minute, la dernière prise de vue est toujours la valeur la plus élevée si on la convertit en nombre. Le script réalise alors une boucle dans laquelle il compare toutes les valeurs de prise de vue et il ne conserve à la fin que la plus forte de ces valeurs. Le script réalise alors une seconde connexion FTP durant laquelle il demande à télécharger tous les fichiers dont le nom répond à l'heure de prise de vue récupérée. Les fichiers sont placés dans le dossier Auto/compressed.

### 3) Pré-traitement des données binaires

Une fois les données LRIT obtenues, il faut d'abord les décompresser. Cette étape est possible grâce au *Public Wavelet Transform Decompression Library Software* d'Eumetsat. Après compilation, l'exécutable XRITDecompress est placé dans le dossier `/bin` de l'ordinateur. Il peut ainsi être appelé par la simple commande XRITDecompress.

Le script decompress.sh utilise cette commande pour décompresser tous les fichiers LRIT présents dans le dossier Auto/compressed et classe les fichiers suivant leur heure de prise de vue.

<table><caption>Illustration 14: Système de classement des fichiers</caption><thead><tr><td>Heure de prise de vue</td><td>Chemin du fichier</td></tr></thead><tbody><tr><td>YYYYMMDDHHMM</td><td>decompressed/YYYY/MM/DD/HHMM</td></tr><tr><td>201606270545</td><td>decompressed/2016/06/27/0545</td></tr></tbody></table>

De plus la variable d'environnement MSG_DATA_PATH est créée et permettra de classer de la même manière tous les autres fichiers produits au cours de la chaîne de traitement (illustration 14).

Les fichiers décompressés portent le même nom que leur pair compressé à l'exception de la terminaison du fichier : le `C_` se transforme en `_`. Le fichier compressé est gardé par défaut dans le dossier Auto/archive.
C) Détection des anomalies thermiques

1) Assemblage des LRIT en raster de température de surface

Les données LRIT contiennent des données qui peuvent être utilisées pour reconstituer des fichiers rasters. Les données binaires contenues dans les LRIT sont organisées par octet. La documentation<fnref n="11" /> Eumetsat précise dans le détail l'organisation des en-têtes et des fichiers de données. Les LRIT doivent ainsi être décodées par groupe d'octets pour délivrer leurs données. Les LRIT contiennent pour chaque canal des informations géographiques (taille du pixel, projection) et des informations radiométriques. La taille des pixels est de 3km sur 3km minimum pour tous les canaux MSG à l'exception du panchromatique (1km) dont nous n'avons pas l'utilité. La donnée radiométrique des pixels est exprimée en radiance (mWm⁻²sr⁻¹(cm⁻¹)⁻¹). Cependant la détection d'anomalies thermiques nécessite d'avoir des mesures en température de surface (brightness temperature en anglais) comme nous l'avons vu dans la première partie. Ainsi il fallait à la fois pouvoir décoder les LRIT et convertir les données en température de surface grâce à la relation suivante :

$$
T = \left[ C_2 v_c / \log \left( \frac{C_1 v_c^3}{R} + 1 \right) - B \right] / A
$$

avec C₁=1.19104 10⁻⁵ mW m⁻² sr⁻¹(cm⁻¹)⁻⁴

C₂=1.43877 K(cm⁻¹)⁻¹

v_c= longueur d'onde central du canal

A,B coefficients relatifs aux canaux (cf. documentation Eumetsat)

Des outils dédiés à la lecture des fichiers LRIT ont déjà été développés et parmi
eux le projet Pytroll<fnref n="12" /> est un des plus avancés. Celui-ci est composé de plusieurs
bibliothèques de fonctions développées en Python 2.7. Nous avons utilisé la
bibliothèque de fonctions mipp (lecture des données satellites), mpop (traitement des
données satellites) et pyresample (utilitaire de ré-échantillonnage de données
géospatiales). Par ailleurs l'API Python de GDAL/OGR a également été utilisée, pour la
création des rasters, tout comme la bibliothèque Pyproj pour effectuer la projection
des données.

La lecture des fichiers LRIT est réalisée par les scripts nommés fire_detect.sh et
fire_detect.py. Pour cela, il est nécessaire de définir les paramètres d'une scène à
traiter :

global_data=GeostationaryFactory.create Newman("meteosat", "10", "seviri", time_slots)

Cette fonction définit une scène pour un satellite géostationnaire, qui répond au nom de meteosat10, doté de l'instrument de mesure SEVIRI. La bibliothèque mpop charge alors les paramètres du satellite du fichier de configuration meteosat10.cfg par analyse syntaxique (parser en anglais). La variable time�, formée à partir de la

<footnote n="11">11. http://www.cgms-info.org/documents/cgms-lrit-hrit-global-specification-%28v2-8-of-30-oct-2013%29.pdf</footnote>

<footnote n="12">12. http://www.pytroll.org/</footnote>
variable d'environnement MSG_DATA_PATH, permet quant à elle de définir l'heure de la
prise de vue mais également le chemin de destination dans lequel se trouve les
fichiers LRIT.

globe/get_area_def("AfSubSahara")
IRchannelList=['IR_039','IR_108']
global_data.load(IRchannelList,area_extent=globe.area_extent,calibrate=1)

L'aire de définition est définie dans le fichier area.def et l'analyse syntaxique permet
de sélectionner l'aire de l'Afrique subsaharienne, créée par nos soins. On choisit
également les canaux à charger. Pour finir, on fait appel à la fonction load pour
charger les données dans la scène. L'argument calibrate permet de définir si l'on
 souhaite obtenir la donnée en radiance (calibrate=2) ou en température de surface
 (calibrate=1). Pytroll nous dispense donc de faire la conversion nous même. La
donnée est alors accessible sous forme de suite de nombres en précisant le canal
souhaité :

print global_data[3.9].data #Affiche la suite de nombre des températures de surface pour le canal 3.9 µm

La bibliothèque GDAL permet de créer un fichier TIFF géoréférencé à partir de la suite
de nombres (illustration 15). Afin de garder la traçabilité des fichiers, leurs noms sont
composés de la manière suivante :

LRIT-MSG3-BT-YYYYMMDD-HHMM-channelnumber.tif

<figure><img src="image_17.png" /><figcaption>Illustration 15: Raster de l'Afrique subsaharienne en température de surface (canal 3,9µm à gauche et 10,8µm à droite), le 2016-06-19 à 11h45</figcaption></figure>

La suite de nombre créée par Pytroll est utilisée par la suite du traitement.
## 2) Algorithme de détection des anomalies thermiques

Les fondamentaux de la détection des anomalies thermiques sont expliqués dans la première partie du rapport. Nous avons pu voir que les incendies sont reconnaissables grâce aux canaux thermiques de 3,9 µm et 10,8 µm. Nous présenterons dans cette partie les indices de détection choisis à l'issue du développement.

La détection des anomalies thermiques se déroule en deux temps, à l'instar de travaux de recherche étudiés dans l'état de l'art (DaCamara C.C et al, 2007 ; Giglio L. et al, 2003 ; Movaghati S. et al, 2008 ; Sifakis N. et al, 2011). La première étape consiste à écarter les pixels ne pouvant pas contenir d'incendie compte tenu de leur température de surface tandis que la seconde étape cherche à déterminer si les pixels restant ont une nature véritablement différente des pixels les entourant, signe qu'un incendie est très probable.

* Le filtre absolu

Ainsi l'algorithme est d'abord composé d'un filtre sur les températures de surface relevées à 3,9 µm et 10,8 µm de longueur d'onde. Ce filtre a pour objectif d'écarter tous les pixels dont les températures sont trop faibles pour être un incendie (illustration 16). Les pixels qui passent le filtre sont considérés comme des pixels de feu potentiel (potentiel fire en anglais, abrégé PF). Pour être retenu comme pixel de feu potentiel, un pixel doit répondre aux conditions suivantes :

$$ - T_{3,9} > 300 \text{ K} \land T_{10,8} > 290 \text{ K} \land \Delta T > 15 \text{ le jour, avec } \Delta T = T_{3,9} - T_{10,8} $$

$$ - T_{3,9} > 300 \text{ K} \land \Delta T > 5 \text{ la nuit} $$

Le temps considéré comme étant le jour s'étend de 5h à 18h considérant le décalage horaire global en Afrique.

<figure><img src="image_18.png" /><figcaption>Illustration 16: Détection des feux potentiels en Afrique du Sud
le 16 mai 2016 à 8h45 (UTM +0)</figcaption></figure>
Le résultat du filtre est sauvegardé à l'intérieur d'une nouvelle suite dont les pixels de feu potentiel répondent à la valeur 2 tandis que les autres répondent à la valeur 1.

## Le filtre contextuel

La suite de l'algorithme réalise alors un filtre contextuel sur les pixels de feu potentiel retenus. Ce filtre utilise une fenêtre mobile afin d'évaluer si un pixel de feu potentiel est effectivement une anomalie thermique au regard de son environnement proche (illustration 17). La taille de la fenêtre retenue est de 5 pixels de côté. Pour être classé comme feu véritable (true fire en anglais, abrégé TF) le pixel de feu potentiel doit alors répondre aux critères suivants :

<figure><img src="image_19.png" /><figcaption>Illustration 17: Principe de la fenêtre mobile</figcaption></figure>

$$ - T_{pf\ 3,9} > \bar{T}_{3,9} + 3,5 * \left( \sum_{i} \frac{|T_{i\ 3,9} - \bar{T}_{3,9}|}{n} \right) $$

$$ - \Delta T_{pf} > \Delta \bar{T} + 3,5 * \left( \sum_{i} \frac{|\Delta T_{i} - \Delta \bar{T}|}{n} \right) $$

Cette formule provient de divers travaux de recherche préconisant l'utilisation de la mean absolute deviation (Giglio L. et al, 2003). La valeur 3,5 dans la formule correspond à un indice d'exigence et peut être modifié. Plus l'indice est grand, plus la différence de température entre le pixel concerné et la moyenne de la fenêtre mobile doit être importante. En cas de surveillance d'une région homogène, il peut être intéressant de modifier l'indice pour accroître une précision du système. Pour une surveillance globale, comme pour notre phase test sur l'Afrique subsaharienne, la valeur de 3,5 s'est révélé être la plus appropriée<fnref n="13" />.

<figure><img src="image_20.png" /><figcaption>Illustration 18: Détection des feux véritables en Afrique du Sud
le 16 mai 2016 à 8h45 (UTM +0)</figcaption></figure>

<footnote n="13">13. Annexe 3</footnote>
Si le pixel de feu potentiel répond aux critères énoncés, il est alors considéré comme un pixel feu véritable (illustration 18). La valeur de température de surface du canal 3,9 µm est sauvegardée dans la suite de nombre tandis que les pixels ne répondant pas aux critères sont codés d'une valeur de 0. Un fichier TIFF est également créé. Enfin, nous verrons que les résultats sont vectorisés et ajoutés à une base Postgresql.

Nous n'avons pas pu vérifier par nous-même la superficie des feux détectés, cependant la littérature rapporte qu'un incendie doit au minimum faire 12 % de la taille du pixel pour être détectable. Les pixels MSG mesurent 9 km², ce qui nous laisse supposer qu'un incendie doit s'étendre sur 1,08 km² minimum pour être détectable.

## 3) Erreurs associées

La chaîne de traitement est fonctionnelle et permet de détecter des incendies. Elle n'est cependant pas infaillible. Quelques erreurs sont classiques lorsque l'on détecte les incendies. Celles-ci peuvent soit être des détections qui ne sont pas réellement des incendies, on parle alors de fausses alertes, soit le système de détection oublie des feux, on parle d'omissions. Ces erreurs interviennent dans plusieurs cas.

### Les bordures nuageuses

Les erreurs liées aux nuages sont les plus nombreuses. En effet ces derniers faussent la détection des feux potentiels. Comme nous l'avons vu, l'algorithme se sert des températures de surface des pixels dans deux canaux thermiques mais aussi de la

différence entre ces deux canaux. S'il n'y a pas de feu, la différence entre les canaux est faible, mais lorsqu'un feu se déclare, alors $T_{3,9} > T_{10,8}$. Les nuages ont un effet inverse. Ils entraînent une plus grande chute de température dans le canal 10,8 µm que le canal 3,9 µm. En cas de couverture nuageuse fine (souvent en bordure des nuages), les températures mesurées restent relativement fortes dans les deux canaux et la présence de nuages permet de répondre au critère de $\Delta T$. Ces erreurs ont lieu en journée.

<figure><img src="image_21.png" /><figcaption>Illustration 19: Erreurs nuageuses du premier test évacuées par le filtre contextuel</figcaption></figure>
Le premier filtre est particulièrement sensible à la présence de nuage, c'est d'ailleurs ce qui a motivé l'ajout du second filtre (illustration 19). La très grande majorité des erreurs liées aux nuages est éliminée par le filtre contextuel mais parfois quelques erreurs persistent.

Par ailleurs, en cas de forte couverture nuageuse, on peut également passer à côté d'incendies étant donné que la température relevée est plus faible lorsque le signal passe à travers les nuages.

* Les surfaces en eau

La mer et les lacs peuvent également être source de fausses alertes. Ces erreurs sont dues à la réflexion quasi-spéculaire sur les surfaces d'eau (illustration 20). Les rayons solaires sont réfléchis et renvoyés dans leur intégralité vers le capteur du satellite.

Plusieurs solutions ont été envisagées afin de réduire le nombre de ces erreurs. L'utilisation d'un masque grâce à un fichier vecteur des surfaces continentales permet d'écarter les détections situées dans les mers et les grands lacs. Tous les lacs ne sont cependant pas numérisés, ainsi il reste quelques erreurs même si elles sont le plus souvent évacuées par le filtre contextuel<fnref n="14" />.

<figure><img src="image_22.png" /><figcaption>Illustration 20: Erreur liée au lac Haïk, Éthiopie (vérification par photo-interprétation d'une composition Natural Color Landsat 8)</figcaption></figure>

<footnote n="14">14. La taille de la fenêtre mobile ne doit pas cependant excéder cinq pixels. Au-delà, le nombre d'erreur augmente.</footnote>
* Les îlots de chaleur

Les îlots de chaleur sont les erreurs plus rares. Elles sont le résultat de l'activité humaine (forte population urbaine, industrie) qui font augmenter la température de surface relevée par le capteur du satellite et crée des fausses alertes. Tout comme les erreurs liées aux surfaces en eau, la solution peut être d'identifier les zones concernées et d'y appliquer un masque en fin de traitement.

Lors de la phase test, nous avons par exemple identifié que l'industrie pétrolière de Soyo, Angola, était la cause d'erreurs sur cette zone. En effet, au cours du mois de mai, pour le même pixel, quatorze détections d'anomalies thermiques sur sept jours différents ont été recensées, ce qui nous a incités à vérifier leur origine.

* Les très grands feux

Il est difficile d'avoir un ordre de grandeur des omissions en matière de détection d'incendie. Cependant, nous avons observé que l'algorithme développé avait parfois du mal à détecter les très grands feux. Ces incendies sont identifiés comme des feux potentiels, mais les pixels de ces incendies sont écartés un à un par le filtre contextuel. En effet, le filtre considère la température particulière d'un pixel par rapport aux températures des pixels environnant, mais si la majorité d'entre eux contiennent des feux, aucun d'entre eux ne se démarque (illustration 21).

<figure><img src="image_23.png" /><figcaption>Illustration 21: Grands feux écartés par le filtre contextuel dans la région de Kwango, République démocratique du Congo (vérification par photo-interprétation d'une composition Natural Color Landsat 8)</figcaption></figure>

Nous avons obtenu de meilleurs résultats sur la détection des grands feux en augmentant la taille de la fenêtre mobile, sans pour autant constater de changement sur la détection des petits incendies. Cependant le nombre de fausses alertes a fortement augmenté, principalement à cause des surfaces en eau, mais aussi à cause des erreurs liées aux nuages.

L'amélioration de la détection des grands feux sera abordée dans les perspectives du rapport.
## 4) Résultats et analyse

Malgré les erreurs énoncées précédemment, les résultats de la chaîne de traitement sont encourageants. Le temps de traitement est raisonnable puisque la chaîne met en moyenne moins de cinq minutes pour exécuter la procédure (le temps dépend surtout du nombre de feux potentiels à confirmer). Nous avons mené une validation des incendies sur treize jours au cours du mois de mai. On trouve à la fois des journées à forte couverture nuageuse et des journées dégagées au cours de la période.

La validation des incendies est réalisée en deux temps. Comme il a déjà été dit, le produit Active Fire du capteur MODIS sert de référence dans le domaine. Par conséquent nous avons d'abord réalisé une vérification automatique de nos alertes au regard du produit Active Fire. Il fallait cependant prendre en compte le décalage de temps de passage des satellites Terra et Aqua avec les prises de vue MSG, ainsi que la différence de résolution spatiale. Pour finir un léger décalage de projection était envisageable. Par conséquent nous avons considéré comme valides les pixels de détection qui présentaient au moins un homologue Active Fire, contenu dans le pixel ou à moins de trois kilomètres (pixels voisins)<fnref n="15" />.

Par la suite, les détections non validées ont fait l'objet d'une vérification individuelle par photo-interprétation. La température mesurée était observée ainsi que l'aspect des détections. En effet les incendies présentent toujours le même aspect. Une détection valide présente un fort contraste avec les pixels qui l'entoure (illustration 22).

<figure><img src="image_24.png" /><figcaption>Illustration 22: Aspect des incendies validés par photo-interprétation</figcaption></figure>

Plusieurs séries de test ont été réalisées afin d'ajuster les variables de détection. L'ensemble des résultats est consultable en annexes<fnref n="16" />. La série des variables présentées dans la partie précédente a été sélectionné de par le nombre important de feux détectés et de son pourcentage de validation de 85,09 % (illustration 23).

<footnote n="15">15. Annexe 2</footnote>

<footnote n="16">16. Annexe 3</footnote>
<table><caption>Illustration 23: Détails des résultats de la validation des alertes LRIT</caption><thead><tr><td>Test au cours du mois de mai - LRIT</td><td>Nombre</td><td>Pourcentage</td></tr></thead><tbody><tr><td>Détection d'anomalies (MSG)</td><td>704</td><td>100</td></tr><tr><td>Nombre de validations automatiques</td><td>466</td><td>66,19</td></tr><tr><td>Nombre d'anomalies supplémentaires validées par photo-interprétation</td><td>133</td><td>18,89</td></tr><tr><td>Total de validation</td><td>599</td><td>85,09</td></tr></tbody></table>

De plus nous avons testé les feux validés afin de savoir sur quel type d'occupation du sol ces derniers se déclaraient (illustration 24). Nous avons pour cela utilisé la classification issue des données MODIS<fnref n="17" />. Les résultats obtenus sont cohérents avec la réalité. En Afrique subsaharienne, c'est sans surprise la savane et la savane boisée qui sont le plus soumis aux incendies (catégorie 8 et 9 pour 78 % des feux validés). Le seul résultat étonnant est la présence de dix-huit feux dans l'eau (catégorie 0). Après vérification, ces détections se trouvent sur le littoral, même s'ils ont été classé comme étant sur de l'eau. Quatre d'entre eux sont effectivement des incendies, mais les quatorze autres sont des erreurs dues à l'activité pétrolière de la ville de Soyo, Angola. Ces erreurs ont été validées automatiquement par correspondance avec Active Fire qui commet également cette erreur.

<table><caption>Illustration 24: Analyse de l'occupation des sols sur lesquels se déclarent les incendies</caption><thead><tr><td>ID_class.Global_Land_Cover</td><td>Description</td><td>Nombre de feu</td><td>Pourcentage</td></tr></thead><tbody><tr><td>0</td><td>Water</td><td>18</td><td>2,56</td></tr><tr><td>1</td><td>Evergreen Needleleaf forest</td><td>0</td><td>0,00</td></tr><tr><td>2</td><td>Evergreen Broadleaf forest</td><td>27</td><td>3,84</td></tr><tr><td>3</td><td>Deciduous Needleleaf forest</td><td>0</td><td>0,00</td></tr><tr><td>4</td><td>Deciduous Broadleaf forest</td><td>1</td><td>0,14</td></tr><tr><td>5</td><td>Mixed forest</td><td>0</td><td>0,00</td></tr><tr><td>6</td><td>Closed shrublands</td><td>0</td><td>0,00</td></tr><tr><td>7</td><td>Open shrublands</td><td>16</td><td>2,27</td></tr><tr><td>8</td><td>Woody savannas</td><td>483</td><td>68,61</td></tr><tr><td>9</td><td>Savannas</td><td>66</td><td>9,38</td></tr><tr><td>10</td><td>Grasslands</td><td>21</td><td>2,98</td></tr><tr><td>11</td><td>Permanent wetlands</td><td>22</td><td>3,13</td></tr><tr><td>12</td><td>Croplands</td><td>11</td><td>1,56</td></tr><tr><td>13</td><td>Urban and built-up</td><td>0</td><td>0,00</td></tr><tr><td>14</td><td>Cropland/Natural vegetation mosaic</td><td>31</td><td>4,40</td></tr><tr><td>15</td><td>Snow and ice</td><td>0</td><td>0,00</td></tr><tr><td>16</td><td>Barren or sparsely vegetated</td><td>8</td><td>1,14</td></tr><tr><td>TOTAL</td><td></td><td>704</td><td>100,00</td></tr></tbody></table>

<footnote n="17">17. http://glcfapp.glcf.umd.edu/data/lc/</footnote>
D) Valorisation des résultats et visualisation

1) Création d'une base de données pour le suivi des incendies

La chaîne de traitement fonctionne en continu, le volume de données est donc
conséquent. Il fallait ainsi mettre en place une base de données pour recueillir tous les
résultats de la chaîne de traitement. Pour cela, plusieurs scripts ont été créés :

- raster2vector.sh et raster2vector.py pour la conversion des rasters en fichiers vecteurs.

- add2pg.sh et add2pg.py pour l'ajout des entités dans une base postgresql

PostgreSQL a été sélectionné car il gère facilement les données spatiales grâce à l'extension Postgis.

La vectorisation en ESRI Shape est facilitée par l'utilisation de la bibliothèque
GDAL/OGR. Le fichier raster de feux véritables (fichier TF) est vectorisé, pour toute
valeur de pixel excepté 0 (pixel écarté par le filtre contextuel), en préservant la
température de surface détectée dans la table attributaire. On renseigne également
l'heure et la date de l'alerte. Les alertes sont sauvegardées sous forme de polygones
de la taille des pixels.

Une table PostgreSQL est créée pour l'ensemble des incendies détectés. Elle possède les champs des fichiers ESRI Shape ainsi que deux nouveaux champs contenant les informations du pays et de l'occupation du sol où se déclare l'incendie. Nous avons en effet ajouté dans notre base une table des pays<fnref n="18" /> et l'occupation du sol issue des données MODIS<fnref n="19" />. L'ajout de ces informations est réalisé grâce à des fonctions Postgis<fnref n="20" />.

2) Interface de visualisation des alertes incendies

La chaîne de traitement n'a d'utilité que si les résultats obtenus sont consultables facilement. Pour cela, une interface de visualisation a été réalisée et sera disponible sur internet. Les données d'incendies sont directement disponibles sur l'interface dès que la base PostgreSQL est mise à jour.

D'un point de vue des technologies utilisées, nous avons utilisé les standards HTML et CSS, associés au PHP pour effectuer les requêtes côté serveur. Le traitement de la requête (API cartographique, graphique) se fait côté client en Javascript. Étant donné que l'API cartographique n'est présente qu'à un but consultatif (pas d'édition de données), nous avons opté pour l'utilisation de Leaflet, une API développée en Javascript, légère et facile d'utilisation.

<footnote n="18">18. http://www.naturalearthdata.com</footnote>

<footnote n="19">19. http://glcfapp.glcf.umd.edu/data/lc/</footnote>

<footnote n="20">20. Annexe 4</footnote>
<figure><img src="image_25.png" /><figcaption>Illustration 25: Page de consultation des feux détectés par la chaîne de traitement</figcaption></figure>

La consultation des données se fait de la manière suivante (illustration 25) : l'utilisateur définit les dates entre lesquelles il souhaite consulter les alertes (1), il valide et la page se recharge avec les données. Par défaut la page affiche les feux des dernières 24h. L'utilisateur peut alors décider de n'afficher que certains feux, suivant la température de surface détectée (2). Il peut également mettre en comparaison nos alertes avec les produits feux MODIS et VIIRS, disponibles en service WMS sur les dernières 24h ou 48h (3). Des statistiques sont mises à disposition de l'utilisateur en cliquant sur le bouton *Statistiques* (4). Les résultats de la requête sont consultables sur l'API cartographique (5).

L'API présente plusieurs fonctionnalités. En plus d'afficher les alertes en fonction de la température de surface, celle-ci est disponible en cliquant sur une alerte, par le biais d'une pop-up. L'heure exacte de détection est également disponible. De plus, pour davantage de lisibilité sur la carte, nous avons fait en sorte que, sur les niveaux de zoom inférieur à 10, les alertes soient représentées par des points et qu'au delà de 10, elles soient représentées par des polygones, afin de mieux percevoir l'emprise potentielle de l'incendie.
<figure><img src="image_26.png" /><figcaption>Illustration 26: Affichage du panneau statistique</figcaption></figure>

Le panneau de statistiques (illustration 26) a été développé grâce à la bibliothèque Javascript D3.js. Elle utilise les mêmes données que celles affichées sur la carte et renvoie deux graphiques détaillant le nombre de feux détectés par pays (1) et par type d'occupation du sol (2).

Les autres pages, Informations et Méthodes, permettront d'avoir davantage d'informations sur le projet TAIMPO et de connaître le détail de la chaîne de traitement.

## E) Développement d'une interface utilisateur

Une fois la chaîne de traitement opérationnelle, des aménagements dans les scripts ont été réalisés afin que le tout soit plus facile à manipuler pour d'autres utilisateurs. Les variables susceptibles de changer entre les utilisateurs comme les chemins d'accès ou les identifiants de connexion (FTP Eumetsat, PostgreSQL) ont été insérées dans un fichier de configuration.

Plusieurs fonctionnalités ont également été ajoutées. Il est possible de désactiver l'ajout des alertes à une base PostgreSQL grâce à la variable ENABLE_POSTGRES, si l'on ne souhaite que garder les fichiers raster et vecteur. De même il est possible de garder ou d'effacer les fichiers intermédiaires (raster BT,PF,TF) avec la variable SAVE_INTERMEDIATE_FILES. Il est également possible de ne pas réaliser la détection d'incendies en désactivant la variable ENABLE_FIRE_DETECTION. La chaîne de traitement compose alors seulement les raster en température de surface. Ces derniers pourront alors être utiles à d'autres fins. Pour finir, il est possible de choisir entre une chaîne de traitement LRIT ou une chaîne de traitement HRIT (cf. Perspectives) suivant les données auxquelles l'utilisateur a accès.
Par ailleurs un script a été ajouté pour permettre le traitement d'archives sur plusieurs jours. Il suffit de renseigner les dates de début et de fin de période dans le fichier de configuration et lancer le script `fd_day_process.sh`. Le script réalise une boucle sur toutes les heures de publications des données durant les journées demandées.

Pour finir une interface graphique a été réalisée à l'aide de la bibliothèque python Tkinter (illustration 27, 28, 29). Celle-ci permet de modifier les variables du fichier de configuration et de lancer les traitements par journée.

<figure><img src="image_27.png" /><figcaption>Illustration 27: Onglet de modification des variables</figcaption></figure>

<figure><img src="image_28.png" /><figcaption>Illustration 28: Onglet de traitement par journée</figcaption></figure>

<figure><img src="image_29.png" /><figcaption>Illustration 29: Onglet des variables avancées</figcaption></figure>
### III. Perspectives

#### A) Déplacement du satellite MSG-1 sur l'Océan Indien

Du fait de l'absence d'un satellite MSG sur la zone de l'océan Indien, nous avons été contraints de mener les tests sur l'Afrique subsaharienne. Le projet TAIMPO a cependant pour objectif de créer des produits opérationnels pour la zone de l'océan Indien et la chaîne de traitement va pouvoir être adaptée pour répondre à ce besoin. En effet, Eumetsat a annoncé le 29 juin 2016 que le satellite MSG-1 serait ré-orbité sur l'océan Indien en septembre 2016 pour un début de service en 2017²¹.

La chaîne de traitement a été développée pour fonctionner en tout point du globe, la seule limite étant la distance avec le point de survol du satellite. Au regard des détections incendies de MODIS, nous avons établi que de la chaîne de traitement était en mesure de détecter les incendies dans un rayon de 40 degrés, soit 4452 km à l'équateur<fnref n="22" />. Les seuls éléments à changer dans la chaîne de traitement seront les paramètres de projection. Une nouvelle définition devra être créée dans le fichier areas.def. Il faudra également vérifier que les heures de publication des données restent identiques.

<figure><img src="image_30.png" /><figcaption>Illustration 30: Portée de détection du satellite MSG-1 à partir de septembre 2016</figcaption></figure>

Compte tenu de la future position du satellite MSG-1 à 41,5°E de longitude, le satellite sera idéalement placé pour détecter les incendies sur la zone de l'océan Indien (illustration 30). Une utilisation en parallèle des satellites MSG-1 et MSG-3 (utilisé lors des tests) permettrait une couverture totale de l'Afrique.

<footnote n="21">21. http://www.eumetsat.int/website/home/News/DAT_3120368.html</footnote>

<footnote n="22">22. Annexe 5</footnote>
## B) Utilisation des HRIT

Il a été possible de tester le traitement HRIT grâce à un jeu de données fourni par l'entreprise Réuniwatt, partenaire du projet. Le jeu de données s'étend sur la même période que les tests effectués en LRIT.

### 1) Une répétitivité des données accrue

Le système de détection actuel est certes fonctionnel mais les données en LRIT ne sont disponibles que toutes les trois heures. Ainsi, l'objectif d'un suivi en temps réel n'est que partiellement atteint. Cependant, il est possible de faire évoluer la licence Eumetsat afin d'accéder aux données HRIT, disponibles toutes les quinze minutes. Le gain en termes de réactivité serait très important. Si l'on ajoute les cinq minutes de traitements nécessaires à la chaîne de traitement, l'information sera disponible toutes les vingt minutes environ.

La chaîne de traitement a déjà été conçue pour traiter les fichiers HRIT. C'est à l'utilisateur de sélectionner dans le fichier de configuration s'il travaille avec des données LRIT ou HRIT.

### 2) Amélioration des résultats

Au cours des tests menés avec les données LRIT, les fausses alertes se sont révélé être en majorité dues à la présence de nuages, comme nous avons pu le voir dans la partie précédente. En effet les nuages affectent les canaux thermiques. Il n'est pas possible de réaliser de masque sur les nuages à partir des données LRIT, car les canaux disponibles ne peuvent pas servir à cet effet. Par contre, tous les canaux étant disponible en HRIT, il est possible de réaliser ce masque et d'éliminer les fausses alertes.

Les filtres destinés à la détection des nuages sont nombreux (Hocking J. et al, 2010). Pour ne pas allonger le temps de traitement nous n'avons pas souhaité multiplier les filtres. C'est un filtre basé sur les canaux visibles qui a été choisi (Amraoui M. et al, 2010) étant donné que ces erreurs n'interviennent qu'en journée. On considère comme nuage les pixels qui répondent aux conditions suivantes :

$$R_{0.6}+R_{0.8}>1,2 \land T_{12}<265$$

avec $R_{0.6}$ et $R_{0.8}$, réflectances des longueurs d'onde 0,6 µm et 0,8 µm et T12, température de surface mesurée par le canal 12 µm.

Ainsi il suffit d'exclure ces pixels lors de la détection des incendies. Le filtre nuage est disponible si l'utilisateur définit qu'il utilise des HRIT en type de données.

<table><caption>Illustration 31: Détails des résultats de la validation des alertes HRIT</caption><thead><tr><td>Test au cours du mois de mai - HRIT, masque nuage</td><td>Nombre</td><td>Pourcentage</td></tr></thead><tbody><tr><td>Détection d'anomalies (MSG)</td><td>5373</td><td>100</td></tr><tr><td>Nombre de validations automatiques</td><td>3286</td><td>61,15</td></tr><tr><td>Nombre d'anomalies supplémentaires validées par photo-interprétation</td><td>1609</td><td>29,95</td></tr><tr><td>Total de validation</td><td>4895</td><td>91,10</td></tr></tbody></table>
On observe des résultats inférieurs en terme de validation automatique (sans doute
dus à un grand nombre de feux détectés entre deux passages MODIS) mais la
validation totale est supérieure celle des données LRIT. En effet, le filtre est efficace et
il reste peu d'erreurs liées aux nuages. Cela permet à la chaîne de traitement
d'afficher un taux de validation des alertes de 91,1 % (illustration 31).

Comme nous l'avons déjà dit, la détection des grands feux n'est encore pas
optimale. Ce problème technique n'est pas un frein à l'utilisation de l'algorithme actuel
pour un passage en phase opérationnelle, l'objectif premier de notre système de détection
étant la mise en place d'alertes précoces, en début d'incendie. Ceci dit, l'utilisation des
données HRIT pourrait améliorer la détection de ces feux. En effet, en utilisant les
données LRIT à trois heures d'intervalle, il est possible qu'un feu ne soit pas détecté
suffisamment tôt et que celui-ci soit ensuite trop étendu pour être détecté. Avec les
données HRIT à un quart d'heure d'intevalle, le feu sera forcément détecté avant que
celui-ci ne soit trop étendu. En outre, d'autres pistes sont explorées pour intégrer les
grands feux dans le système de détection et notamment une détection en deux temps
avec une adaptation du filtre contextuel pour cibler en priorité les feux de grandes tailles.
Ce dernier point est encore en cours de tests car l'augmentation de la taille de la fenêtre
mobile augmente aussi les confusions.

C) Optimisation de la chaîne de traitement

Les temps de traitement de la chaîne ne sont pas excessifs, ils sont de l'ordre de
cinq minutes. Ils pourraient cependant être grandement améliorés. Les scripts qui
prennent le plus de temps sont ftp.sh, du fait du téléchargement des données, et
fire_detect.py, lors du filtre contextuel. Lors de la réalisation de ce filtre, la machine
traite un ensemble de variables sous un même calcul. Actuellement, ce calcul ne peut-
être attribué qu'à un seul processeur, quel que soit le nombre qu'en comporte la
machine (en l'occurrence, huit sur la machine dédiée à la chaîne de traitement).

Adapter la chaîne de traitement, et notamment la réalisation du filtre contextuel,
en plusieurs tâches permettrait de mettre plusieurs processeurs à contribution. La
 scène globale, nommée AfSubSahara dans le fichier areas.def, pourrait être divisée en
 plusieurs parties dont chacune serait affectée à un processeur différent. L'image finale
 serait recomposée après calcul des feux véritables. Une piste pour adapter le script
 python serait d'utiliser la bibliothèque de fonctions Multiprocessing<fnref n="23" />.

<footnote n="23">23. https://docs.python.org/2.7/library/multiprocessing.html</footnote>
D) Communication auprès des acteurs de la lutte contre le feu

Bien entendu, le système de surveillance ne sera efficace si les autorités de lutte
contre le feu ont connaissance de celui-ci. Le projet n'en est encore qu'à un prototype
mais il est possible d'envisager à terme un système d'envoi d'alerte par messagerie
électronique (Diagne M. et al, 2007). Les entités administratives (pays, voire sous-
entités) fourniraient une adresse de messagerie à laquelle envoyer les nouvelles
alertes. Les services de lutte contre le feu relayeraient alors l'information vers le
centre de lutte contre le feu le plus proche de l'incendie déclaré.

Si le système de surveillance atteint ce niveau d'implication avec les acteurs locaux, cela permettra également d'avoir un retour terrain pour la validation des résultats. Peut-être que les résultats récoltés nous inciteront à modifier les indices de détection de la chaîne de traitement. La collecte de données terrain pourrait également approfondir les connaissances que nous avons des capacités du système. Elle pourrait nous renseigner sur la taille minimum des feux détectés ou encore une estimation de la biomasse brûlée.

Par ailleurs, la chaîne de traitement a été conçue pour être utilisable facilement. Ainsi, il est possible que celle-ci soit utilisée à des fins de recherche dans la caractérisation des régimes de feux et dans l'étude de la saisonnalité des incendies (Broucke S., 2009).
## IV. Bilan

Participer au projet TAIMPO à travers la thématique de la détection des incendies a été une opportunité que je suis heureux d'avoir saisie. Si le poste requérait principalement des compétences d'ingénierie, il m'a également permis d'approcher le milieu de recherche et d'avoir ainsi plusieurs casquettes au cours de ce stage.

En effet la conception de la chaîne de traitement a été la principale activité de ce stage. Les objectifs à atteindre était clairement définis par mes encadrants, ce qui m'a permis de rentrer rapidement dans le sujet. De plus ces derniers m'ont laissé une grande liberté quant aux technologies à utiliser. J'ai donc eu à me familiariser avec les différentes technologies existantes pour traiter les données des satellites Meteosat seconde génération et sélectionner celle qui convenait le mieux au besoin du projet. Cela m'a par ailleurs amené à prendre contact avec d'autres développeurs afin de discuter de leurs outils. En définitive, ce stage m'a permis d'adopter une véritable démarche d'ingénierie, de la conception du produit à la réalisation, voire sa promotion. Pendant près de six mois, j'ai pu améliorer mes compétences en programmation et j'ai réellement pris en main le fonctionnement des systèmes Linux. Ce qui n'était d'abord qu'une suite de scripts s'est progressivement changé en application, exportable sur d'autres machines et relativement facile d'utilisation. Pour finir, j'ai apprécié de mener le fruit de mon travail jusqu'au bout en développant une interface de visualisation des données. En effet, c'est essentiellement cette partie du travail que la plupart des personnes verront, la partie visible de l'iceberg.

Concernant le monde de la recherche, j'ai bien entendu bénéficié des conseils de mes encadrants dès que j'en manifestais le besoin. L'étape de validation des alertes était cruciale pour évaluer la performance de la chaîne de traitement et c'est avec leurs conseils que nous avons établi les modalités de validation. Ce stage représente pour moi un bon exemple du fonctionnement de la recherche. Mon rôle était de développer un outil. Je l'ai abordé comme un travail d'ingénierie mais le stage pouvait aussi être abordé comme étant de la recherche appliquée. Au final l'un ne va jamais sans l'autre et il a tout de même fallu que je lise une longue littérature sur la détection des incendies. Par ailleurs, j'ai pu voir en quoi consistait le métier de chercheur par le biais de mes collègues de travail, avec les avantages que cela comporte, comme le partage des connaissances, mais aussi les difficultés.

J'ai particulièrement apprécié l'autonomie dont j'ai joui au cours de ces derniers mois ainsi que la confiance que mes encadrants m'ont accordée. Ils ont su être présents quand j'en avais besoin et me laisser avancer seul lorsque tout allait bien. J'espère que le travail que j'aurai fourni sera estimé et que l'outil créé continuera d'être utilisé.
Conclusion

Les événements naturels accidentels (inondations, incendies...) ont un impact réel sur les populations et l'environnement. Fort de ce constat et du fait que la détection précoce de ces événements peuvent réduire leurs conséquences, l'UMR Espace-Dev a souhaité lancer le projet TAIMPO (Télédétection Appliquée à l'Imagerie Météorologique pour le développement de Produits Opérationnels), dans lequel s'inscrit ce stage.

Les incendies sont les événements accidentels les plus fréquents avec les tempêtes et certaines régions du monde en sont fortement impactées. La surveillance en temps réel par satellite est une opportunité pour accélérer le temps d'intervention. Pour être efficace, les autorités doivent avoir accès aux alertes le plus rapidement possible. L'objectif du stage était ainsi de réaliser une chaîne de traitement capable de rapidement détecter les incendies, depuis le rapatriement des données satellites jusqu'à la publication des résultats.

Actuellement, la chaîne de traitement est en place et la détection d'incendies fonctionne. Les données MSG ont été sélectionnées pour leur très haute répétitivité temporelle. En effet, ces données sont accessibles toutes les trois heures (LRIT) et à l'avenir, elles pourront l'être toutes les quinze minutes (HRIT). Lors de la conception de la chaîne de traitement, nous avons choisi d'utiliser des technologies libres et gratuites (GDAL, Pytroll), et le tout installé sur un système Linux, ce qui a permis un développement à moindre coût et permettra une plus grande flexibilité en cas de portage de l'application.

La chaîne de traitement utilise les données télémétriques des canaux thermiques MSG (3,9 µm et 10,8 µm). Les valeurs de radiance de ces canaux sont converties en température de surface et l'algorithme détecte les incendies à partir de deux filtres successifs. Le premier est un filtre absolu sur les valeurs de température de surface relevées par le satellite ; le second est un filtre contextuel qui détermine si un pixel particulier a une réponse radiative anormale vis-à-vis des pixels qui l'entoure. Suite à la phase de validation des détections, nous avons pu estimer la fiabilité de la chaîne de traitement qui présente un taux de 85 % de bonnes détections avec les données LRIT. Il subsiste donc encore 15 % de fausses alertes ou de détections impossibles à confirmer. La résolution temporelle peut être améliorée par l'utilisation de données HRIT à la place des LRIT. Cela permettrait également selon nos tests d'améliorer le taux de bonnes détections à 91 %, grâce à l'utilisation d'un masque sur les nuages à l'origine de nombreuses erreurs.

L'application est fonctionnelle et facilement adaptable. Le système est aujourd'hui mis en place sur l'Afrique subsaharienne et sera prochainement disponible pour l'océan Indien grâce à la ré-orbitation du satellite MSG-1. L'interface graphique de développement permettra à tous les utilisateurs potentiels de tenter d'affiner la détection des incendies et notamment celle des grands feux.
A peine le traitement terminé, les résultats sont accessibles par le biais d'une interface de webmapping. Le temps de traitement depuis le rapatriement des données satellites jusqu'à leur publication en ligne est de cinq minutes. Actuellement en prototype, l'interface sera par la suite mise en ligne. Avec notamment un objectif de diffusion aux acteurs de la lutte contre les incendies dans le Sud-Ouest de l'océan Indien.

Le système de détection d'incendie est aujourd'hui mis en place, sur l'Afrique subsaharienne actuellement et sur l'océan Indien dans le futur grâce à la ré-orbitation du satellite MSG-1.
Bibliographie

1. AMRAOUI M., 2010, Detection and monitoring of African vegetation fires using MSG-SEVIRI imagery, Remote sensing of environment, n°114, pp. 1038-1052

2. BROUCKE S., juin 2009, État de l'art sur la détermination du régime du feu par des moyens de télédétection, 14p

3. CROMBETTE P., 2010, Optimisation et poursuite des développements du système LiveFire de géolocalisation automatisée et temps-réel de prises de vues aéroportées, Mémoire de master, Université de Toulouse Jean-Jaurès, 65p

4. DACAMARA C.C. et al, 2007, The SAF for land surface analysis wildfire applications, EUMETSAT Conference, pp. 50-57

5. DIAGNE M. et al, 2010, Multisource Data Integration for Fire Risk Management: The Local Test of a Global Approach, Geoscience and remote sensing letters, vol 7, n°1, pp. 93-97

6. GIGLIO L., 2003, An Enhanced Contextual Fire Detection Algorithm for MODIS, Remote sensing of environment, n°87, pp. 273-282

7. HOCKING James et al, janvier 2010, Cloud Detection in Meteosat Second Generation Imagery at the Met Office, Rapport technique R&D du Met Office, n°540, 43p

8. LEWYCKYJ N. et al, 2007, OSIRIS : a European project using a High altitude Platform for forest fire monitoring, 2nd International conference on safety and security engineering, pp. 205-213

9. MANYANGADZE T., 2009, Forest fire detection for near real-time monitoring using geostationary satellites, Mémoire de master, International Institute for Geo-Information Science and Earth Observation, Enschede, Pays-bas, 92p

10. MBOW C., Etude des caractéristiques spatio-temporelles des feux de brousse et de leur relation avec la végétation dans le parc national du Niokolo Koba (sud-est du Sénégal), Thèse de l'Université de Dakar, 2000, 139p

11. MOVAGHATI S., 2008, Samadzadegan F., Azizi A., A comparative study of three algorithms for forest fire detection in Iran, Proc. XXIst ISPRS Congress, Beijing, China, vol. XXXVII, part B8, commission VIII, pp. 379-382

12. PELLETIER C. et al, 2001, Méthodologie de détection des feux de forêt à partir d'images satellitaires NOAA, Mémoire de master, Université du Québec de Chicoutimi, 57p

13. SIFAKIS N et al, 2011, Wildfire Detection and Tracking over Greece Using MSG-SEVIRI Satellite Data, Remote Sensing, n°3, pp. 524-538

14. WANG W., 2007, An improved algorithm for small and cool fire detection using MODIS data: A preliminary study in the southeastern United States, Remote sensing of environment, n°108, pp. 163-170

15. ZHUKOV B. et al, 2006, Spaceborne detection and characterization of fires during the bi-spectral infrared detection (BIRD) experimental small satellite mission (2001–2004), Remote sensing of environment, n°86, pp. 29-51
Table des matières

<table><tr><td>Résumé</td><td>3</td></tr><tr><td>Abstract</td><td>3</td></tr><tr><td>Sommaire</td><td>4</td></tr><tr><td>Remerciements</td><td>5</td></tr><tr><td>Sigles et abréviations</td><td>6</td></tr><tr><td>Introduction</td><td>7</td></tr><tr><td>I. Contexte</td><td>9</td></tr><tr><td>A) Projet de recherche TAIMPO, UMR ESPACE-DEV</td><td>9</td></tr><tr><td>1) Descriptif du projet TAIMPO</td><td>9</td></tr><tr><td>2) Organisation du stage</td><td>9</td></tr><tr><td>B) Lieu d'accueil et partenaires</td><td>10</td></tr><tr><td>C) Évaluation de l'existant et des besoins</td><td>11</td></tr><tr><td>1) Détection d'incendies par télédétection</td><td>11</td></tr><tr><td>Les fondamentaux de la détection d'incendies</td><td>11</td></tr><tr><td>Imagerie haute et basse résolution, deux finalités différentes</td><td>13</td></tr><tr><td>2) Données accessibles et utiles</td><td>14</td></tr><tr><td>3) Besoins exprimés</td><td>14</td></tr><tr><td>II. Développement de la chaîne de traitement</td><td>17</td></tr><tr><td>A) Présentation générale de la chaîne de traitement</td><td>17</td></tr><tr><td>1) Environnement général</td><td>17</td></tr><tr><td>2) Conception</td><td>18</td></tr><tr><td>Fonctionnement de la chaîne de traitement</td><td>18</td></tr><tr><td>Architecture de la chaîne de traitement</td><td>19</td></tr><tr><td>B) Acquisition des données en temps réel et pré-traitement</td><td>20</td></tr><tr><td>1) Automatisation de la chaîne de traitement</td><td>20</td></tr><tr><td>2) Acquisition par ftp</td><td>21</td></tr><tr><td>3) Pré-traitement des données binaires</td><td>22</td></tr><tr><td>C) Détection des anomalies thermiques</td><td>23</td></tr><tr><td>1) Assemblage des LRIT en raster de température de surface</td><td>23</td></tr><tr><td>2) Algorithme de détection des anomalies thermiques</td><td>25</td></tr><tr><td>Le filtre absolu</td><td>25</td></tr><tr><td>Le filtre contextuel</td><td>26</td></tr><tr><td>3) Erreurs associées</td><td>27</td></tr><tr><td>Les bordures nuageuses</td><td>27</td></tr><tr><td>Les surfaces en eau</td><td>28</td></tr><tr><td>Les îlots de chaleur</td><td>29</td></tr><tr><td>Les très grands feux</td><td>29</td></tr><tr><td>4) Résultats et analyse</td><td>30</td></tr><tr><td>D) Valorisation des résultats et visualisation</td><td>32</td></tr><tr><td>1) Création d'une base de données pour le suivi des incendies</td><td>32</td></tr><tr><td>2) Interface de visualisation des alertes incendies</td><td>32</td></tr><tr><td>E) Développement d'une interface utilisateur</td><td>34</td></tr></table>
III. Perspectives..................................................................................................................36

A) Déplacement du satellite MSG-1 sur l'Océan Indien................................................................................36

B) Utilisation des HRIT.................................................................................................................................37

1) Une répétitivité des données accrue........................................................................................................37

2) Amélioration des résultats.................................................................................................................................37

C) Optimisation de la chaîne de traitement........................................................................................................38

D) Communication auprès des acteurs de la lutte contre le feu................................................................................38

IV. Bilan.................................................................................................................................40

Conclusion.................................................................................................................................41

Bibliographie.................................................................................................................................42

Table des matières................................................................................................................43

Table des illustrations................................................................................................................45

Table des annexes.................................................................................................................................46
Table des illustrations

<table><tr><td>Illustration 1: Zone d'acquisition de l'antenne SEAS-OI4</td><td>10</td></tr><tr><td>Illustration 2: Loi de Stefan Boltzmann (gauche) et loi de Planck (droite)</td><td>11</td></tr><tr><td>Illustration 3: Optimum radiatif du soleil et de la Terre (source Manyangadze T., 2009)</td><td>12</td></tr><tr><td>Illustration 4: Réponses des canaux 3,9 µm et 10,8 µm selon la part de pixel couvert par un feu (source Manyangadze T., 2009)</td><td>13</td></tr><tr><td>Illustration 5: Canaux utiles pour la détection d'incendies dans le spectre électromagnétique</td><td>14</td></tr><tr><td>Illustration 6: Les objectifs du stage au sein du projet TAIMPO</td><td>16</td></tr><tr><td>Illustration 7: Model builder de la chaîne de traitement</td><td>18</td></tr><tr><td>Illustration 8: Architecture de l'application firemsg</td><td>19</td></tr><tr><td>Illustration 9: Heures de lancement de la chaîne de traitement (fuseau UTM+0)</td><td>20</td></tr><tr><td>Illustration 10: Configuration du planificateur de tâche Linux pour le LRIT</td><td>20</td></tr><tr><td>Illustration 11: Configuration du planificateur de tâche Linux pour le HRIT</td><td>20</td></tr><tr><td>Illustration 12: Image du globe reconstituée à partir de LRIT, canal 3,9µm</td><td>21</td></tr><tr><td>Illustration 13: Formation des noms des fichiers de télémétrie MSG</td><td>21</td></tr><tr><td>Illustration 14: Système de classement des fichiers</td><td>22</td></tr><tr><td>Illustration 15: Raster de l'Afrique subsaharienne en température de surface (canal 3,9µm à gauche et 10,8µm à droite), le 2016-06-19 à 11h45</td><td>24</td></tr><tr><td>Illustration 16: Détection des feux potentiels en Afrique du Sud le 16 mai 2016 à 8h45 (UTM +0)</td><td>25</td></tr><tr><td>Illustration 17: Principe de la fenêtre mobile</td><td>26</td></tr><tr><td>Illustration 18: Détection des feux véritables en Afrique du Sud le 16 mai 2016 à 8h45 (UTM +0)</td><td>26</td></tr><tr><td>Illustration 19: Erreurs nuageuses du premier test évacuées par le filtre contextuel</td><td>27</td></tr><tr><td>Illustration 20: Erreur liée au lac Haïk, Éthiopie (vérification par photo-interprétation d'une composition Natural Color Landsat 8)</td><td>28</td></tr><tr><td>Illustration 21: Grands feux écartés par le filtre contextuel dans la région de Kwango, République démocratique du Congo (vérification par photo-interprétation d'une composition Natural Color Landsat 8)</td><td>29</td></tr><tr><td>Illustration 22: Aspect des incendies validés par photo-interprétation</td><td>30</td></tr><tr><td>Illustration 23: Détails des résultats de la validation des alertes LRIT</td><td>31</td></tr><tr><td>Illustration 24: Analyse de l'occupation des sols sur lesquels se déclarent les incendies</td><td>31</td></tr><tr><td>Illustration 25: Page de consultation des feux détectés par la chaîne de traitement</td><td>33</td></tr><tr><td>Illustration 26: Affichage du panneau statistique</td><td>34</td></tr><tr><td>Illustration 27: Onglet de modification des variables</td><td>35</td></tr><tr><td>Illustration 28: Onglet de traitement par journée</td><td>35</td></tr><tr><td>Illustration 29: Onglet des variables avancées</td><td>35</td></tr><tr><td>Illustration 30: Portée de détection du satellite MSG-1 à partir de septembre 2016</td><td>36</td></tr><tr><td>Illustration 31: Détails des résultats de la validation des alertes HRIT</td><td>37</td></tr></table>

Sauf indication, les illustrations sont des œuvres personnelles.
# Table des annexes

<table><tr><td>Annexe 1 : Diagramme de GANTT</td><td>47</td></tr><tr><td>Annexe 2 : Requête SQL de validation automatique</td><td>48</td></tr><tr><td>Annexe 3 : Détails des tests réalisés pour les détections LRIT</td><td>49</td></tr><tr><td>Annexe 4 : Code Python avec requête SQL pour l'intégration des alertes à la base de données</td><td>50</td></tr><tr><td>Annexe 5 : Détection et distance au satellite, comparaison entre le nombre de détections SEVIRI, MSG (géostationnaire), et MODIS, Aqua/Terra (héliosynchrones)</td><td>51</td></tr></table>
Stage - Automatisation traitement incendie

Diagramme de Gantt

<figure><img src="image_31.png" /></figure>
Annexe 2 : Requête SQL de validation automatique

DROP TABLE IF EXISTS validation ;
CREATE TABLE validation AS
SELECT fire.id as id,
fire.temp_kelvin as temp_kelvin,
fire geom as geom,
fire.date as date,
fire.time as time,
COUNT(modis_1_20_mai_afrique.id) as nb_modis,
MAX(modis_1_20_mai_afrique.brightness) as max BT modis
FROM fire,
modis_fire
WHERE ST_CONTAINS(ST_BUFFER(fire2 geom, 0.0405), modis_1_20_mai_afrique.geom)
AND fire.date = modis_1_20_mai_afrique.acq_date
GROUP BY fire.id;
1. ALTER TABLE validation_ ADD PRIMARY KEY (id);
Annexe 3 : Détails des tests réalisés pour les détections LRIT

<table><thead><tr><th>Test du 1er au 19 mai</th><th>Paramètre 1</th><th>Paramètre 2</th><th>Paramètre 3</th><th>Paramètre 4</th><th>Paramètre 5</th></tr></thead><tbody><tr><td>Détection d'anomalies (MSG)</td><td>704</td><td>381</td><td>1382</td><td>487</td><td>749</td></tr><tr><td>Nombre de validations automatiques</td><td>466</td><td>263</td><td>802</td><td>287</td><td>466</td></tr><tr><td>Pourcentage d'anomalies validées automatiquement</td><td>66,19%</td><td>69,03%</td><td>58,03%</td><td>58,93%</td><td>62,22%</td></tr><tr><td>Nombre d'anomalies supplémentaires validées par photo-interp</td><td>133</td><td>64</td><td>nd</td><td>nd</td><td>nd</td></tr><tr><td>Pourcentage d'anomalies validées manuellement</td><td>18,89%</td><td>16,80%</td><td>nd</td><td>nd</td><td>nd</td></tr><tr><td>Total d'anomalies validées</td><td>85,09%</td><td>85,83%</td><td>nd</td><td>nd</td><td>nd</td></tr></tbody></table>

Résultats des tests selon les paramètres choisis

<table><thead><tr><th rowspan="2"></th><th colspan="2">Paramètre 1</th><th colspan="2">Paramètre 2</th><th colspan="2">Paramètre 3</th><th colspan="2">Paramètre 4</th><th colspan="2">Paramètre 5</th></tr><tr><th>jour</th><th>nuit</th><th>jour</th><th>nuit</th><th>jour</th><th>nuit</th><th>jour</th><th>nuit</th><th>jour</th><th>nuit</th></tr></thead><tbody><tr><td>Heure journée</td><td colspan="2">h>8 and 18<h</td><td colspan="2">h>8 and 18<h</td><td colspan="2">h>8 and 18<h</td><td colspan="2">h>5 and 18<h</td><td colspan="2">h>5 and 18<h</td></tr><tr><td>T3.9</td><td>300</td><td>300</td><td>300</td><td>300</td><td>300</td><td>300</td><td>300</td><td>300</td><td>300</td><td>300</td></tr><tr><td>T10.8</td><td>290</td><td>nd</td><td>290</td><td>nd</td><td>290</td><td>nd</td><td>290</td><td>nd</td><td>290</td><td>nd</td></tr><tr><td>Delta</td><td>15</td><td>5</td><td>20</td><td>5</td><td>15</td><td>5</td><td>10</td><td>5</td><td>15</td><td>5</td></tr><tr><td>Indice d'exigence</td><td>3,5</td><td>3,5</td><td>3,5</td><td>3,5</td><td>3</td><td>3</td><td>4</td><td>4</td><td>3,5</td><td>3,5</td></tr></tbody></table>

Détails des paramètres de test
Annexe 4 : Code Python avec requête SQL pour l'intégration des alertes à la base de données

for feature in layer :

date=feature.GetField("Date")
time=feature.GetField("Time")
temp=feature.GetField("Count")
geom=str(feature.GetGeometryRef())
exe_arg="""INSERT INTO %s(date,time temp_kelvin,country,landCover,geom)"""

SELECT

'%s',
'%'s',
'%'s',
pays.sovereight,
global_lc_merge.libel,ST_GeomFromText('%s',4326)

FROM

pays,
global_lc_merge

WHERE

ST_CONTAINS(pays geom, ST_CENTROID(ST_GeomFromText('%s', 4326)))
AND
ST_CONTAINS(global_lc_merge.st_union, ST_CENTROID(ST_GeomFromText('%s', 4326)));
'''' % (PG_TABLENAME, date, time, temp, geom, geom, geom)

cursor.execute(exe_arg)

connection.commit()
<figure><img src="image_32.png" /><figcaption>Annexe 5 : Détection et distance au satellite, comparaison entre le nombre de détections SEVIRI, MSG (géostationnaire), et MODIS, Aqua/Terra (héliosynchrones).</figcaption></figure>