Exemple-Rapport de Stage Developpment

Département RÉSEAUX ET TÉLÉCOMMUNICATIONS
Développement d’une application web qui visualise les

données de la technologie DAS
Rapport de stage rédigé par Ker Chee TUNG
PROMOTION 2020/2022
Illustration 1 : Bâtiment Fizeau de Laboratoire Lagrange à Valrose
Observatoire de la Côte d’Azur

Bd de l’Observatoire – CS 34229
06302 Nice-Cedex 4, France
stephane.mazevet@oca.eu
+33 04 92 30 00 11
Lu et approuvé par…
André FERRARI
Professeur – andre.ferrari@univ-cotedazur.fr
Autorise la diffusion en interne Michel GAUTERO

N’autorise pas la diffusion Maitre de conférences en informatique
Michel.GAUTERO@univ-cotedazur.fr
Institut Universitaire de Technologie
Département Réseaux et Télécommunications
650, route des Colles
06560 Valbonne
Tél. 04.93.95.51.70
Fax. 04.93.95.51.89
iutsoph.unice.fr
PRÉSENTATION DE RAPPORT DE STAGE
Développement d’une application web qui visualise les

données de la technologie DAS
Volume 1/1
Rapport rédigé par :
Ker Chee TUNG
Étudiante de DUT Réseaux et Télécommunications

I.U.T Nice Côte d’Azur
Promotion 2020/2022
Tuteur de stage : Tuteur à l’IUT :

M. André FERRARI M. Michel GAUTERO
Professeur Maitre de conférences en informatique
Université de Nice Côte d’Azur Dept. Réseaux et Télécommunications
IUT de Nice Côte d’Azur
Copies du présent document :
Département Réseaux et Télécommunications : 1

Observatoire de la Côte d’Azur : 1
Ker Chee TUNG : 1
KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 2

REMERCIEMENTS
Je tiens en premier lieu à remercier mon maitre de stage, M. André FERRARI, professeur
au sein de l’Université de Nice Côte d’Azur et chercheur au Laboratoire Lagrange, sans qui ce
stage n’aurait pas été possible. Je le remercie de m’avoir offert ce stage qui m’a donnée
l’opportunité d’intégrer son équipe et de m’avoir accompagnée tout au long de mon stage. J’ai
particulièrement apprécié la confiance qu’il m’a accordée et l’aide qu’il m’a offerte. J’ai aussi pu,
grâce à lui, acquérir des compétences qui me seront utiles dans mon cursus professionnel.
Ensuite, je voudrais exprimer mes sincères remerciements à tout le personnel de l’équipe

Signal & Image (SI) au Laboratoire Lagrange pour leur enthousiasme et leur convivialité qui m’ont
accompagnée pendant toute la durée de mon stage. Leurs conseils prodigués et leurs explications
sur le projet m’ont beaucoup motivée et ont assuré le bon déroulement de mon stage. La
particularité de chacun a enrichi ma vision sur le monde du travail, que ce soit professionnellement
ou humainement parlant.
J’adresse également mes remerciements à mon tuteur, M. Michel GAUTERO, maitre de

conférences à l’Université de Nice Côte d’Azur pour son suivi et ses conseils tout au long de mon
stage. Je remercie aussi tout particulièrement Mme. Celine THEYS pour son aide dans la recherche
de mon stage, ce qui m’a permis de postuler au sein du Laboratoire Lagrange et d’effectuer un stage
très enrichissant.
Enfin, je tiens à remercier toute l’équipe pédagogique et administrative du département

Réseaux et Télécommunications à l’IUT de Nice Sophia Antipolis pour leur investissement et leur
implication au cours de mes deux années d’études. Je souhaiterais aussi exprimer ma
reconnaissance à Mme. Emmanuelle BOUCHÉ qui m’a prodiguée des précieux conseils pour la
rédaction du rapport de stage et la préparation de soutenance.

TABLE DES MATIÈRES
REMERCIEMENTS ........................................................................................................... 3
PRÉSENTATION DE L’OBSERVATOIRE DE LA CÔTE D’AZUR ............................. 5
PRESENTATION DU LABORATOIRE LAGRANGE ET DE L’ÉQUIPE SIGNAL ET
IMAGE (SI) ……………………………………………………………………………….....7
PRÉSENTATION DU PROJET ........................................................................................ 8
ABSTRACT…………………………………………………………………………………10
INTRODUCTION GÉNÉRALE ...................................................................................... 11
I. Visualisation de la carte de Nice et de la trace de fibre optique sur l’interface web ... 12
1.1 Choix des outils et des logiciels pour l’environnement de développement ........................................12
1.2 Réalisation de la carte de Nice avec la librairie « Leaflet »................................................................15
1.3 Insertion de la trace de fibre optique sur la carte réalisée ...................................................................17
II. Extrait des positions et la calibration des capteurs ..................................................... 21
2.1 L’extrait des coordonnées des capteurs positionnés à un intervalle défini.........................................21
2.2 L’affichage des capteurs le long de la fibre avec plugin « Leaflet.markercluster » ...........................25
2.3 La calibration des capteurs .................................................................................................................28
III. La structure du menu et l’insertion de la base de données …………..……………...37
3.1 La structure et le fonctionnement du menu ........................................................................................37
3.2 L’insertion de la base de données « InfluxDB » ................................................................................45
3.3 La présentation des données en interagissant avec la base de données ..............................................48
CONCLUSION ................................................................................................................. 52
BIBLIOGRAPHIE ............................................................................................................ 53
ANNEXES…………………………………………………………………………………...54
Annexe A : Journal de Bord du stage avec deux exemples ......................................................................54
Annexe B : Le code pour afficher des capteurs dans le mode calibration ................................................56
Annexe C : Le code pour la calibration des capteurs................................................................................58
Annexe D : L’exemple des données stockées dans InfluxDB sur web UI................................................60
Annexe E : Le code pour récupérer et afficher les informations du bucket choisi ...................................61
TABLE DES ILLUSTRATIONS ..................................................................................... 62
LISTE DES ABRÉVIATIONS ......................................................................................... 64

PRÉSENTATION DE L’OBSERVATOIRE DE
LA CÔTE D’AZUR
L’Observatoire de la Côte d’Azur (OCA) est situé à Boulevard de l’Observatoire, CS 34229 - F
06304 NICE Cedex 4. Il s’agit d’un établissement public national d’enseignement supérieur et de
la recherche à caractère administratif qui a été fondé en 1881 par M. Raphael BISCHOFFSHEIM,
associant le Centre National de la Recherche Scientifique (CNRS), l'Université Nice Sophia
Antipolis (UNS) et IRD (Institut de Recherche pour le Développement).
L’OCA se contribue dans les activités de recherche en sciences de la Terre et de l’Univers de la

région azuréenne. Il se compose d’une unité de services (Galilée) et de trois unités de recherche
multi tutelles : Artémis, Géoazur et Lagrange.
Illustration 2 : Les trois laboratoires de recherches constitués sous OCA
L’Observatoire de la Côte d’Azur est actuellement dirigé par M. Stéphane MAZEVET depuis le
1er juillet 2021, avec un effectif d’environ 450 personnes. Il est localisé sur 4 sites géographiques :
1) Mont Gros où se trouve le siège (site historique de l’Observatoire de la Côte d’Azur)

2) Valrose (campus de la faculté de sciences de l’Université de Nice Sophia Antipolis)
3) Site de Géoazur dans la technopole de Sophia Antipolis
4) Site d’observation du plateau de Calern
Les trois domaines principaux de l’OCA sont la :

1) Recherche - contribuer au progrès de la connaissance de l’univers par l’acquisition
,systématique de données d’observation, le développement et l’exploitation de moyens
théoriques, expérimentaux et techniques appropriées, dans les domaines de l’astronomie,
des géosciences, des sciences connexes et de leurs applications.
2) Formation - contribuer à la formation initiale et continue d'étudiants et de l'ensemble des

personnels de recherche.
3) Culture Scientifique - concourir à la diffusion des connaissances, en particulier auprès du

personnel enseignant et des usagers du service public de l’enseignement.
.

Illustration 3 : L’organigramme de l’OCA
Les responsabilités de l’OCA sont d’explorer, de comprendre et de valoriser les sciences de la Terre
et de l’Univers, que ce soit en astrophysique, en sciences de la Terre, mais également dans les
sciences connexes le traitement du signal et l’optique. D’autre part, les laboratoires de l’OCA
contribuent à la formation universitaire à l’UNS de la licence jusqu’au doctorat. Il est impliqué
dans sa mission de diffusion de connaissances vers tous les publics et la mis en place d’un dispositif
d’observations en astrophysiques et en géosciences.

PRESENTATION DU LABORATOIRE LAGRANGE ET DE
L’ÉQUIPE SIGNAL ET IMAGE (SI)
Durant mon stage pendant 11 semaines, j’ai été accueillie par le laboratoire J.-L. LAGRANGE qui
est l’une des unités de recherche de l’OCA. Il se constitue de deux sites : Bâtiment Fizeau à Valrose
Université Nice Côte d'Azur et Pavillon Evry Schatzman à Boulevard de l'Observatoire Nice. Je
travaillais dans le bâtiment Fizeau dans l’équipe Signal et Image (SI).
Ce laboratoire rassemble des équipes d’astrophysique (planétologie, physique stellaire et solaire,

galaxies et cosmologie), de traitement du signal et images, de mécanique des fluides et
d’instrumentation pour l’observation astronomique à résolution spatiale élevée. Les chercheurs
développent de nouvelles théories et modèles et les confrontent à des observations acquises.
Actuellement dirigé par M. Philippe STEE, le Laboratoire Lagrange emploie 118 permanents et 23
doctorants, ceux-ci sont repartis dans les 6 équipes suivantes :
1) Équipe Galaxies et Cosmologie
2) Équipe Méthodes Physiques pour l’Observation (MPO)
3) Équipe Physique Stellaire et Solaire
4) Équipe Signal & Image (SI)
5) Équipe Théorie et Observations en Planétologie (TOP)
6) Équipe Turbulence Fluide et Plasma
Je me suis intégrée dans l’équipe Signal et Image (SI) qui est dirigée par mon maître de stage, M.
André FERRARI. Cette équipe a pour vocation de développer des algorithmes avancés en
traitement du signal et des images dans le cadre des Sciences de l’Univers, en particulier de
l’astronomie.
Les missions et les activités de l’équipe SI sont liées sur :
• Le développement des théories et méthodes en traitement du signal et des données

astronomiques.
• L’instrumentation optique atmosphérique à haute résolution.
• L’Imagerie à haute résolution angulaire et très haute dynamique.
Dans l’équipe SI, je travaillais avec l’équipe DAS qui n’incluent pas tous les personnels de l’équipe
SI. Cette équipe DAS se compose de 8 personnes : 3 permanents, 1 postdoctorant, 1 étudiant
doctorant et 3 stagiaires.

Permanent Post-Doc Doctorant Stagiaires
André Martijn Yacine Selina

FERRARI VAN DEN ENDE KHACEF CHEGGOUR
Wan Nur
Cédric
Munira BINTI
RICHARD
ZAIDAN
Anthony Ker Chee

SLADEN TUNG
Illustration 4 : Organigramme de l’équipe DAS
Mon stage a débuté le 4 avril 2022. J’ai travaillé avec une autre stagiaire, Munira, qui est ma
camarade à l’IUT. Le matériel qui m’a été fourni est un ordinateur iMac de marque Apple et je
travaillais dans un open-space au quatrième étage du bâtiment.
Illustration 5 : Mon bureau de travail avec un iMac

PRÉSENTATION DU PROJET
Au cours des onze semaines de stage passées au Laboratoire Lagrange, j’ai assumé les
fonctions de développeuse Frontend. Mon rôle était de réaliser une application web en utilisant
javascript afin de visualiser de façon interactive les données de la technologie DAS développées
par l’équipe SI. J’ai occupé 10% de mon temps à la visualisation de la carte et la trace de fibre
optique, 30% à l’affichage des capteurs et la réalisation de mode calibration, 40% à l’insertion de
la base de données et l’affichage des données, les 20% restant ont été consacrés à la rédaction du
rapport.
Dans un premier temps, j’ai été amenée à comprendre ce que la technologie DAS mesure
le long de la fibre et quels sont les résultats récupérés par l’équipe qui développe les algorithmes.
Pour ce faire, mon maître de stage, M. FERRARI nous a fait une courte présentation afin de nous
expliquer le fonctionnement de l’interrogateur DAS et nous montrer les données mesurées. Pendant
les deux premières semaines de ce stage, j’ai travaillé avec Munira sur la même tache. Notre
première mission était de créer la page HTML, contenant la carte de Nice avec la trace de fibre
optique. Une fois cette étape a été accomplie, avec les coordonnées de la trace de fibre optique,
nous avons ensuite déduit les coordonnées des capteurs qui sont positionnés à un intervalle défini
(distance de jauge) le long de la fibre.
Ma seconde mission était de réaliser la calibration des positions des capteurs sur
l’application web. A partir de ce moment-là, Munira et moi avons travaillé séparément. Pour savoir
concrètement ce qu’ils demandaient, j’ai beaucoup discuté avec M. FERRARI, M. RICHARD et
M. VAN DEN ENDE. Enfin, j’ai développé un algorithme qui nous permet de changer les postions
des capteurs automatiquement sur l’application web. Pour ce faire, j’ai appliqué la suggestion de
M. VAN DEN ENDE, calibration des capteurs avec les points de contrôles choisis par les
utilisateurs.
La mission suivante qui m’a été confiée était l’insertion de la base de données dans
l’application web pour remplacer le fichier CSV local. De nos scripts Javascript, j’ai récupéré les
données d’énergie, de pression et de comptage des véhicules qui sont stockées dans InfluxDB et
les ai affichées sur l’interface. L’utilisateur peut choisir la date et la durée pour visualiser les
données spécifiques. Par la suite, j’ai fait animer la trace en affichant les différents couleurs
correspondants à l’énergie à chaque capteur.
Au terme de ce stage, une application web qui sert à la visualisation des données et à la
vision globale de ce projet DAS a été réalisée. Ce sera un outil flexible et interactif pour faire des
analyses et les modifications dans le domaine des recherches en utilisant DAS.

ABSTRACT
During the eleven weeks of my internship done at Laboratory Lagrange, I assumed the
tasks of a Frontend developer, my job was to create a web application by using JavaScript to
visualize DAS data developed by the team SI. I spent 10% of my time for visualization of map and
trace of optical fiber, 30% for display of sensors and creation of calibration mode, 40% for data
base application and data display and the remaining 20% of my time was spent for writing my
report.
First and foremost, I had to understand how DAS technology measures along the fiber and
what were the results retrieved by the team who develops the algorithms. Thus, my tutor, M.
FERRARI did a brief presentation to explain how DAS interrogator works and to show us the data
measured by the team. During the first two weeks of internship, I worked together with Munira on
the same task. Our first mission was to create a HTML page, containing the map of Nice with the
line of optical fiber. Once this task is accomplished, with all coordinates of the optical fiber, we
have deduced the coordinates of sensors which are located at a defined interval (gauge length)
along the fiber.
My second mission was to create calibration of positions of sensors on the interface.

Starting from that moment, Munira and I worked separately. In order to understand what they were
requesting, I have had a lot of discussion with M. FERRARI, M. RICHARD and M. VAN DEN
ENDE. At last, I had developed an algorithm which allows us to change the positions of sensors
automatically on the interface. Besides, I applied the suggestion of M. VAN DEN ENDE,
calibration of sensors using control points chosen by users.
The next mission which was given to me was insertion of data base in the web application
to replace the local CSV file. By using our JavaScript code, I retrieved the energy data, strain data
and vehicle count data, which are stocked in InfluxDB, and I displayed them on the interface. Users
are able to choose date and duration to visualize some specific data. Next, I animated the trace by
showing different colors which correspond to energy at each sensor.
At the end of this internship, a web application used for visualization of data and for a
global vision of DAS project was produced. It will be a flexible and interactive tool to do analysis
and modifications in the research domain using DAS.

INTRODUCTION GÉNÉRALE
De nos jours, nous passons du temps sur les gadgets électroniques dans nos vies
professionnels et également nos vies privées. Envoyer des mails, regarder des vidéos sur YouTube,
télécharger un fichier sur Internet, tout ça est rendu possible grâce à un maillage de câbles de fibre
optique qui se trouve partout sous le sol des villes. A part de s’en servir comme un câble de
télécommunication, il est possible d’utiliser les fibres optiques de ces câbles pour une application
plus intéressante – le concept de Smart City. Avec la technologie DAS (Distributed Acoustic
Sensing), nous pouvons donc détecter les vibrations le long de la fibre optique, collecter les
informations sur la circulation des autoroutes et déterminer la condition des voies et des trains sur
les chemins de fer.
DAS est une technologie d’impulsion laser qui convertit les câbles de fibre optique en
milliers de capteurs de vibrations, positionnés tous les quelques mètres le long du câble à fibre
optique. Un interrogateur envoie systématiquement de courtes impulsions de lumière de laser à une
autre extrémité de la fibre et mesure la phase et l’amplitude des photons rétrodiffusés qui ont
interagi avec les nano courbures dans la fibre optique. En utilisant ces données, l’équipe SI a
effectué une étude de suivi du trafic et des véhicules sur un câble à fibre optique de 20 km déployé
le long d’une route principale à Nice, France.
Avec les algorithmes développés par l’équipe SI, une énorme quantité de données est donc
récupérée par exemple : les séries temporelles du signal, les données d’énergie, le nombre de
véhicules, l’estimation de la vitesse etc. Le fait qu’ils ont beaucoup de données mais qu’il n’y a pas
d’interface pour les représenter n'est pas optimale car c’est moins compréhensible avec les données
qui ne sont pas bien visualisées et regroupées. D’autre part, ils ont effectué la modification des
positions des capteurs manuellement, mais ceci leur a pris beaucoup de temps pour les vérifier un
par un.
C’est donc pour ces raisons que l’équipe SI nous a demandé de réaliser une application
web, qui peut leur faciliter la visualisation des résultats DAS de façon interactive et d’effectuer les
modifications flexibles. Cette application web va les aider à analyser les données efficacement et à
économiser leur temps de travail.

I. Visualisation de la carte de Nice et de la trace de
fibre optique sur l’interface web
Au début de ce stage, je travaillais avec Munira sur les mêmes tâches en utilisant les outils et les
logiciels comme Visual Studio Code et Git. La première partie de notre travail consistait à créer
la page HTML contenant la carte de Nice en utilisant JavaScript. Pour réaliser cette étape, j’ai
utilisé la librairie « Leaflet », qui m’a permis d’afficher la carte sur l’interface et d’utiliser ses
fonctionnalités de cartographie que j’aurais eu besoin pour les tâches suivantes. Une fois cette
étape terminée, je devais visualiser la trace de la fibre optique où l’équipe récupérait les données
avec DAS, sur la carte que j’avais réalisée. Pour ce faire, j’ai utilisé un fichier de format GeoJSON
qui contient les coordonnées de la fibre optique et j’ai tracé la ligne de fibre optique en utilisant
Leaflet API. Cette première mission m’a pris 5 jours pour l’accomplir.
1.1 Choix des outils et des logiciels pour l’environnement de développement
Durant ce stage, j’utilisais l’outil « Visual Studio Code », un éditeur de code extensible et open
source, pour écrire les lignes de code de Javascript de façon structurée et compréhensible. Il a été
classé comme l’outil d’environnement de développement le plus populaire. La facilité d’installer
des extensions, qui ajoutent des fonctionnalités supplémentaires, est la raison principale pour
laquelle je l’ai choisi comme mon outil d’environnement.
Par exemple, afin de pouvoir construire et tester notre application web dynamique, il m’a fallu un
serveur local, qui me permet d’actualiser automatiquement à chaque changement dans les scripts.
Avec Visual Studio Code, j’ai donc installé l’extension « Live Server » et ce qui me permettait de
lancer le serveur simplement sur l’outil afin qu’il actualise le navigateur lorsqu’il détecte les
changements dans nos scripts statiques. Cela me permettait de développer mes scripts et voir les
résultats en temps réel.
Illustration 6 : Les quatre outils et logiciels utilisés

Ensuite, j’ai également utilisé le logiciel Git et GitHub pour suivre les changements effectués et
pour collaborer avec Munira facilement. Git est un logiciel de gestion de versions qui sauvegarde
tous les changements, je pouvais ainsi toujours revenir sur certaines versions comme je le voulais.
Git m’a permis de travailler avec Munira sur les différentes tâches, sur le même fichier et en même
temps.
Nous avons travaillé sur des branches différentes. Une fois que nous avions terminé les
modifications, nous avons fusionné les deux branches avec la commande « git merge ». De plus,
nous pouvions récupérer les dernières modifications distantes du projet et les fusionner dans la
branche courante avec « git pull ».
L’illustration ci-dessous est un graphe de chronologie qui montre la répartition des branches. La
ligne noire représente la branche principale (main), les lignes bleues et vertes sont les branches qui
représentent les différentes étapes de travail. Les labels sont les noms des branches. Une fois une
étape accomplie, la branche va rejoindre la branche principale.
Illustration 7 : Le schéma de répartition des tâches avec les branches
Au début du stage, je travaillais avec Munira sur la création de la carte et la visualisation de la trace
de fibre optique. Par la suite, nous nous sommes répartis nos tâches. Je travaillais sur l’affichage
des capteurs et la calibration, quant à Munira, elle travaillait sur la création du menu et l’affichage
des données avec Plotly. Au final, nous travaillions ensemble sur l’insertion de la base de données.
Illustration 8 : La répartition du travail entre Munira et moi

Avec tous ces outils et logiciels, nous nous sommes répartis efficacement nos tâches, je pouvais
également travailler de façon plus organisée et structurée, et bien distinguer toutes les étapes de
travail. Tous les jours, je notais les tâches que j’accomplissais avec tous les détails (durée, contexte,
difficultés, …) dans mon journal de bord, ce qui a facilité la rédaction de mon rapport de stage.
(Cf. Annexe A) pour voir deux exemples de mon journal de bord et la répartition de travail.
Illustration 9 : La structure de dossier SequoiaFE
Pour construire cette application web, j’ai utilisé beaucoup de plugins et de libraires open-source.
Par conséquent, il y avait de nombreux fichiers. Tous les fichiers de type JavaScript, CSS, HTML,
JSON et les images sont bien organisés dans le dossier SequoiaFE. Les images, les scripts CSS et
les fichiers complémentaires se situent dans le sous dossier « src ». Les scripts principaux comme
script.js, menu.js, plotEnergyData.js, plotSrainData.js, plotVehicleData.js et index.html sont placés
directement dans le dossier SequoiaFE. Ainsi, je pouvais trouver et éditer facilement les fichiers et
bien garder la hiérarchie des fichiers.

1.2 Réalisation de la carte de Nice avec la librairie « Leaflet »
En arrivant, mon maître de stage a fait une présentation de type PowerPoint, afin de nous expliquer
le fonctionnement de la technologie DAS et de nous montrer les résultats interprétés par l’équipe
qui s’occupe du développement de l’algorithme IA. En même temps, il nous a indiqué ce qu’il
attendait de nous et leurs besoins pour réaliser cette application web. Le premier travail qu’il m’a
confié était d’apprendre à utiliser la librairie « Leaflet » et à visualiser la carte de Nice en utilisant
« Leaflet ». « Leaflet » est une bibliothèque JavaScript libre de cartographie en ligne qui peut être
utilisée avec de nombreux plugins et qui a des APIs faciles à utiliser et bien documentées.
Illustration 10 : Le logo de librairie Leaflet
Illustration 11 : Le code pour visualiser la carte avec Leaflet
D’après la documentation sur le site de Leaflet, nous avons donc réalisé la carte de Nice sur
l’interface web avec le centre de la carte de coordonnées :
[43.69315081744552, 7.245756233588564]

Nous avons choisi le niveau maximal de zoom à 19.5 pour pouvoir bien visualiser les capteurs pour
l’étape suivante.
Illustration 12 : La carte de Nice sur l'application web
A part l’affichage en vue normale de la carte, nous avons également proposé l’option de l’affichage
en vue satellite dans le menu en haut à gauche. Les détails concernant la structure du menu vont
être expliqués dans les parties suivantes. Le fait d’avoir une vue satellite va faciliter la localisation
des capteurs quand ils vont zoomer sur la carte. En effet, c’est essentiel de connaitre les positions
précises des capteurs quand nous analysons les données DAS, pour savoir à quelle position
correspond le signal capturé. Avec la vue satellite, nous avons une vision plus claire sur la
localisation des capteurs.
Illustration 13 : La carte de Nice en vue satellite

Illustration 14 : La carte de Nice en vue satellite agrandie
Ce premier travail nous a pris 3 heures pour le réaliser. Nous avons passé beaucoup de temps sur
Internet pour des recherches et sur l’appréhension de l’utilisation de Leaflet, puisque nous allions
utiliser ses APIs tout au long de projet. Leaflet est facile à utiliser et les documentations sont claires
et simples à comprendre. En outre, de nombreuses personnes l’utilisent, d’où des communautés qui
proposent des solutions aux difficultés rencontrées en utilisant Leaflet.
Après avoir visualisé la carte de Nice sur l’application web, l’étape suivante était de tracer la fibre
optique où ils récupéraient les données sur la carte.
1.3 Insertion de la trace de fibre optique sur la carte réalisée
Afin de tracer la fibre optique sur la carte, nous avions besoin de nombreuses coordonnées qui
constituent la fibre optique. Ainsi, M. FERRARI nous a donné un fichier de format GeoJSON, qui
contenait toutes les coordonnées représentant les géo localisations des points sur la fibre. GeoJSON
(géographique JSON) est un format ouvert d'encodage d'ensemble de données géospatiales simples
utilisant la norme JSON (JavaScript Object Notation). Il permet de décrire des données de type
point, ligne, chaîne de caractères, polygone. « Leaflet » prend en charge tous les types GeoJSON
ci-dessus. Le fichier GeoJSON que nous avions contenait les données de type point (les
coordonnées).
Au début, nous avons inséré directement le fichier GeoJSON dans notre script Javascript, c’est-à-
dire que le fichier se situait dans le dossier local et était lu directement par le script. Néanmoins,
M. FERRARI nous a dit que cette application devrait pouvoir être utilisée par tout le monde et être
utilisée ailleurs (les autres projets DAS). Ainsi, j’ai fait un changement dans notre code –
l’utilisateur peut importer son fichier GeoJSON sur l’application web et les coordonnées contenues
seront lues et récupérées par notre script.

L’illustration ci-dessous montre la fonction qui sert à lire les données de fichier GeoJSON
importées et à extraire les données. Pour ce faire, j’ai utilisé « FileReader », qui permet de lire le
fichier et de transformer les données récupérées en format JSON. Le problème que j’ai rencontré
était que les données récupérées n’existaient que dans la fonction « fr.onload », par conséquent, je
n’arrivais pas à sortir les résultats. Afin de résoudre ce problème, j’ai fait beaucoup de recherches
sur Internet et enfin j’ai trouvé une solution : sauvegarder le résultat dans le stockage de session,
dans la fonction « fr.onload ». Si je voulais l’utiliser en dehors de la fonction, j’avais juste besoin
d’aller le chercher dans le stockage de session.
Illustration 15 : Le code pour lire le fichier GeoJSON importé
Illustration 16 : Les données sous format GeoJSON récupérées

Ce sont les données de ficher GeoJSON récupérées par la fonction « importJsonFile() ». Nous
constatons qu’il est de type « FeatureCollection » et que les coordonnées stockées sont sous la
forme de tableau. Chaque tableau répresente une coordonnée de la fibre avec sa longitude et sa
latitude. Ici, nous avons 1984 points pour pouvoir tracer la fibre optique.
J’ai donc réorganisé les données en récupérant seulement les coordonnées et les ai rangées dans un
tableau. Ensuite, j’ai utilisé le Leaflet API : « L.polyline » pour connecter tous les points et donc
former la trace de la fibre optique sur la carte. La couleur de polyligne assignée est bleu.
Illustration 17 : Le code pour réaliser la trace de fibre optique
Une couche GeoJSON a été ajoutée sur la carte. La ligne bleue représente la trace de la fibre
optique, où l’équipe a effectué ses recherches – les routes principales de Nice d’une longueur 20km.
Elle part de la mairie de Nice pour se terminer au Parc Phoenix, en passant par les stations de trams,
les voies de trains et les autoroutes.
Illustration 18 : La ligne de fibre optique sur la carte

La difficulté de cette étape était la compréhension du format GeoJSON, dans la mesure où je n’avais
jamais utilisé ce type de fichier avant. Afin que nous puissions mieux comprendre comment le
fichier GeoJSON fonctionnait, M. FERRARI nous a expliqué le format. Avant de décider d’utiliser
la classe « L.polyline », j’ai essayé d’utiliser la classe « L.geoJSON » mais cela n’a pas marché
parce que le fichier GeoJSON qu’il m’a donné n’était pas conforme avec le fichier GeoJSON que
Leaflet demandait. Ainsi, j’ai récupéré toutes les coordonnées, et au lieu d’utiliser « L.geoJSON »,
j’ai utilisé « L.polyline » pour tracer la ligne.
Durant cette première semaine de stage, j’ai accompli mon objectif, réaliser la page HTML
contenant la carte de Nice et la trace de fibre optique. J’ai appris à utiliser la librairie Leaflet,
qui est très efficace pour réaliser les cartes interactives. J’ai également pris connaissance du
format GeoJSON, qui m’a permis de visualiser la géo localisation de la fibre optique. En outre,
j’ai appris à utiliser Git pour travailler en même temps avec Munira, ce qui m’a énormément
aidé à organiser mon environnement de travail. Enfin, j’ai eu l’opportunité d’approfondir ma
compréhension sur le langage Javascript dans la mesure où je n’ai appris que la base de
javascript à IUT. Comme nous avons visualisé les éléments essentiels de cette application web,
l’étape suivante était de travailler sur les positions des capteurs le long de la fibre optique.

II. Extrait des positions et la calibration des
capteurs
La deuxième partie de mon travail était de déduire les positions des capteurs, qui étaient
positionnés à un intervalle défini par l’utilisateur le long de la fibre optique. En utilisant le plugin
« Leaflet.GeometryUtil », j’ai pu extraire les coordonnées des capteurs. En utilisant le plugin
« Leaflet.markercluster », les capteurs ont été regroupés à chaque niveau de zoom. Grâce à cette
fonctionnalité, les capteurs sont plus visibles. Ensuite, il faut pouvoir corriger les positions des
capteurs directement sur l’interface, en raison de l’existence des bobines (fibre enroulée). Pour
calibrer les capteurs, il m’a fallu réfléchir à un algorithme qui corrige les positions en interagissant
avec l’application. Donc, après l’interprétation de ce problème, j’ai développé une méthode pour
réaliser cette étape importante. La deuxième mission m’a pris trois semaines pour l’accomplir.
2.1 L’extrait des coordonnées des capteurs positionnés à un intervalle défini
La technologie DAS transforme la fibre optique en milliers de capteurs virtuels, qui sont
positionnés à un intervalle appelé « gauge » le long de la fibre optique. Tous les capteurs
correspondent à un canal et les signaux sont détectés à chaque canal. Par conséquent, il est
primordial de représenter les positions correctes des capteurs avant d’afficher les données
interceptées. M. FERRARI nous a donné le fichier « h5_to_json.html » en tant que référence pour
trouver les coordonnées des capteurs, mais il était écrit en Python.
Illustration 19 : L'exemple représentant les positions des capteurs avec gauge = 6m
Ce graphe avec latitude comme axe des ordonnées et longitude comme axe des abscisses montre
les capteurs qui sont placés à un intervalle de 6m.

Afin de trouver comment je pouvais utiliser les coordonnées de fichier GeoJSON pour déduire les
coordonnées des capteurs, j’ai fait beaucoup de recherches sur Internet. Cela m’a pris 2 heures. J’ai
appliqué « Leaflet.GeometryUtil », un plugin open-source Javascript qui fournit des fonctions
géométriques (la distance, les longueurs accumulées, etc.) en utilisant les coordonnées. Sur notre
application web, l’utilisateur peut saisir l’intervalle (gauge) et peut créer un fichier JSON contenant
les coordonnées des capteurs. Dans notre script, en se basant sur un fichier GeoJSON, il va trouver
les coordonnées des capteurs avec l’intervalle comme paramètre et va générer un fichier JSON, qui
va être téléchargé directement dans notre dossier local.
Illustration 20 : Le code pour générer un fichier JSON contenant des coordonnées des capteurs
Pour obtenir les coordonnées des capteurs, il y a 5 étapes à implémenter et nous avons 2
informations, les coordonnées dans le fichier GeoJSON qui nous a permis de tracer la fibre et la
distance entre deux capteurs, définie par l’utilisateur.
1) Avec la fonction « accumulatedLengths », il retourne un tableau qui contient les distances
entre deux coordonnées GeoJSON.
D’après l’illustration 20, le premier élément de

tableau est 0 car c’est le premier point. Le
deuxième élément a une valeur de 0,399257… qui
représente la distance entre le premier point et le
deuxième point et ainsi de suite pour les éléments
suivants.
Illustration 21 : Le tableau de distances accumulées

2) Avec ce tableau des distances accumulées, nous pouvons donc faire la somme de toutes les
distances et nous trouverons la longueur totale de la fibre optique en mètre :
3) Nous avons la longueur totale de la fibre, qui est la distance entre deux capteurs, nous
pouvons ainsi calculer le nombre de capteurs positionnés le long de la fibre en faisant le
calcul suivant: Longueur totale / Intervalle entre deux capteurs. Avec l’intervalle de 10m,
nous avons
capteurs.
4) En utilisant le nombre de capteurs et la distance gauge, il crée un tableau contenant des

ratios sur chaque capteur.
Pour le premier capteur, il y a un ratio de 0, car c’est

le point d’origine. Le deuxième capteur a un ratio
de (1/1874), le troisième capteur a un ratio de
(2/1874) et ainsi de suite.
Illustration 22 : Le tableau de ratio calculé
5) Avec la fonction « interpolateOnLine », il prend en paramètre la carte, le tableau des ratios

et les coordonnées GeoJSON et il retourne un tableau contenant les coordonnées des
capteurs.
Illustration 23 : Le tableau des coordonnées des capteurs

Tant qu’il a trouvé toutes les coordonnées des capteurs, il va générer un fichier JSON appelé
« sensors. json » qui contient toutes ces coordonnées. Ce fichier va donc être téléchargé directement
dans notre dossier « Téléchargement ». Comme la distance de « gauge » pouvait être modifiée dans
le projet DAS, il faut pouvoir trouver les coordonnées des capteurs avec un intervalle défini par
l’utilisateur, mais pas fixé. La possibilité de télécharger le fichier va leur permettre de réutiliser le
même fichier, sans régénérer un autre fichier à la prochaine utilisation. Ensuite, il faut juste
importer ce fichier JSON pour avoir les capteurs sur l’interface. Les noms de fichiers importés sont
également indiqués dans le menu.
Illustration 24 : La création et le téléchargement de fichier JSON sur l'interface
Avant de trouver le plugin Leaflet.GeometryUtil, je ne savais pas comment obtenir les coordonnées
des capteurs le long de la fibre. Grâce à ce plugin, qui me donnait des fonctions très utiles, j’ai pu
accomplir cette tâche, sans rester longtemps bloquée. Cette tâche m’a pris 2 heures pour la réaliser.
Nous avions toutes les coordonnées des capteurs dans un fichier JSON. L’étape suivant était
l’affichage de tous les capteurs sur l’interface.

2.2 L’affichage des capteurs le long de la fibre avec plugin « Leaflet.markercluster »
Au début, afin d’afficher tous les capteurs sur l’application web, j’ai utilisé la classe
« L.marker » pour afficher l’ensemble des marqueurs bleus. Néanmoins, avec un intervalle de
10 m entre les deux capteurs, nous avons 1875 capteurs. Par conséquent, nous voyons tous les
1875 capteurs sur l’interface en même temps, si nous ne faisons pas de zoom. Et c’est
impossible de distinguer les capteurs, car ils sont tous superposés les uns sur les autres.
L’illustration ci-dessous est un exemple que tous les capteurs sont affichés en même temps sur
l’interface, mais ce n’est pas efficace si nous voulons faire des actions sur les marqueurs. La
ligne bleu représentant la trace fibre optique n’est plus visible. J’ai également constaté que
l’application web est devenue plus lente quand tous les marqueurs sont affichés.
Illustration 25 : L’ensemble des marqueurs affichés sur l'interface
Afin d’assurer la fluidité de l’interface et la visualisation claire des capteurs, M. FERRARI nous a
proposé le plugin « Leaflet.markercluster », qui permet le groupement des marqueurs en fonction
du niveau de zoom (cluster) et la personnalisation des markers. Elle offre par défaut des
comportements intéressants :
• A chaque clique sur un cluster, ce dernier se sépare en sous-cluster ou marker simple de

façon animé.
• La fonctionnalité « spiderfy» (plusieurs marqueurs à la même position) est directement
incluse.
• L'ensemble est très paramétrable (apparence des clusters, activation/désactivation
d'options)
Ainsi, je pouvais utiliser ce plugin pour éviter l’affichage de tous les capteurs en même temps, et
pour regrouper les marqueurs à chaque niveau de zoom.

Premièrement, j’ai téléchargé les deux fichiers : leaflet.markercluster.js et
MarkerCluster.Default.css, puis je les ai mis dans le dossier « SequoiaFE/src/css ». La mise en
œuvre du groupement des marqueurs se fait très simplement avec la classe L.MarkerClusterGroup.
Ensuite, il suffit d’ajouter chaque marqueur au cluster construit. Enfin, j’ai ajouté le cluster à la
carte en tant que nouveau Layer (couche).
Sur l’application web, nous pouvons choisir d’afficher les marqueurs ou pas, en cliquant sur un
bouton de radio qui s’appelle « Markers ». Ce bouton se trouve dans le sous-menu « View », où le
bouton « Satellite View » se situe. Si ce buton est activé, les marqueurs sont affichés sous la forme
cluster.
Illustration 26 : Le code pour afficher les capteurs de forme marker cluster
Nous voyons que les clusters affichent la plage des indexes des capteurs, par exemple : 178 – 268,
c’est-à-dire que les capteurs 178 jusqu’aux capteurs 268 sont situés dans cette aire. Pour ce faire,
j’ai modifié le code dans le fichier leaflet.markercluster.js, au lieu d’afficher le nombre des capteurs
dans ce cluster par défaut, il affiche la plage des indexes des capteurs.
Illustration 27 : Les capteurs affichés sous la forme cluster

Quand nous cliquons sur ce cluster, il va faire un zoom et nous voyons plus de clusters dans cette
aire, qui montrent des plus petites plages des capteurs.
Illustration 28 : Les clusters quand nous cliquons sur un cluster
Si nous cliquons sur le cluster jusqu’au zoom maximum, nous voyons les marqueurs bleus mais
plus de cluster. En cliquant sur les marqueurs, un message popup va apparaître pour nous indiquer
l’index de ce capteur, par exemple : Sensor 231.
Illustration 29 : Les marqueurs avec une démonstration de popup au capteur 231
Pour conclure, grâce au plugin « Leaflet.markercluster », j’ai pu afficher environs 1900 capteurs
(intervalle de 10m) de façon organisée et visible sur l’application web. Avec la modification
ajoutée, nous pouvons savoir exactement où se situe un capteur spécifique en regardant la plage
des indexes sur les clusters. De plus, la documentation sur GitHub était claire pour que je puisse
utiliser les fonctionnalités de ce plugin. Le temps consacré à cette étape a été 5 heures.

2.3 La calibration des capteurs
A partir de la troisième semaine du stage, Munira et moi, nous nous sommes réparties différentes
tâches. Je devais réaliser la calibration des capteurs et Munira devait représenter les données
d’énergie dans une fenêtre popup.
Après avoir affiché les capteurs sur l’interface, M.FERRARI m’a fait part d’un gros problème pour
la visualisation des capteurs. En effet, sur l’interface, nous voyons que les capteurs sont positionnés
le long de la route à un intervalle de 10 m. Mais, en réalité, les fibres optiques sont souvent
enroulées sous la forme d’une bobine et non en ligne droite comme sur l’interface. Les positions
des capteurs que j’ai extraites dans l’étape précédente était le long du tuyau, mais pas le long de la
fibre. Donc, les positions des capteurs que nous avions n’étaient pas correctes. Il a fallu les corriger
avec l’application web. Avant de réaliser cette application, ils ont vérifié manuellement les
positions des capteurs, basé sur les données d’énergie, et les ont corrigées un par un. Cela leur a
pris beaucoup de temps et n’a pas été efficace. C’est la raison pour laquelle que M. FERRARI m’a
demandé de réaliser la calibration des capteurs directement sur l’interface.
Ce fut la tâche la plus dure que j’ai eu à faire au cours de ce stage, parce qu’il m’a fallu réfléchir à
un algorithme fiable, afin de réaliser la calibration. Premièrement, M. FERRARI m’a donnée des
idées, avec l’application, il faut :
1) Savoir quels sont les marqueurs à glisser, mais pas tous les marqueurs.
2) Pouvoir faire glisser le marqueur de sa mauvaise position à la position correcte.
3) Repositionner tous les autres marqueurs automatiquement après avoir fait glisser un
marqueur.
4) Générer un fichier JSON contenant les coordonnées des capteurs.
Pour accomplir cette tâche, j’ai beaucoup discuté avec M. FERARRI, M. RICHARD et M. VAN
DEN ENDE. M. VAN DEN ENDE m’a suggéré d’appliquer les points de contrôle. Ce sont des
marqueurs qui peuvent être glissés et qui se situent souvent aux endroits où les véhicules s’arrêtent
(feu rouge, station de tram, arrêt de bus, intersection, …). L’idée est de pouvoir sélectionner les
points de contrôle sur l’interface et de faire glisser ces points de contrôle. Ensuite, seulement les
marqueurs autour de ce point de contrôle vont changer leurs positions automatiquement. La
démonstration ci-dessous va mieux expliquer le fonctionnement de cette calibration.
Illustration 30 : La démonstration des marqueurs avant la calibration

Dans l’illustration 31, il y a 7 capteurs qui sont positionnés tous les 10m le long du tuyau,
l’utilisateur a choisi les 1er , 4ème et 7ème capteurs en tant que points de contrôle. De plus, il y a un
feu rouge qui se situe au milieu du 2ème et du 3ème capteur. En se basant sur les données d’énergie
qui sont montrées dans une fenêtre popup, l’utilisateur a constaté que les véhicules se sont arrêtés
au 4eme capteur.
Illustration 31 : Le plot des données d’énergie pendant 10 minutes
C’est un exemple de données d’énergie en série temporelle que les utilisateurs peuvent voir sur
l’application web. Les traces jaunes montrent le mouvement des véhicules sur la route, et la
discontinuité de trace signifie un arrêt des véhicules.
Ainsi, la position du 4ème capteur était fausse, car le feu rouge se situe avant le 3ème capteur. En
effet, il y a une bobine de fibre optique enroulée près du 1er capteur. Avec l’application web,
l’utilisateur avait juste besoin de faire glisser le 4ème capteur à la vraie position (au feu rouge), et
les autres capteurs autours de ce point de contrôle (2ème, 3ème, 5ème, 6ème capteur) vont être
repositionnés le long de la fibre avec la même distance entre chacun d’eux. Les points de contrôle
avant et après le 4ème capteur ne changent pas leurs positions.
Illustration 32 : Les capteurs repositionnés après la calibration
Après la calibration, nous voyons que les capteurs entre le 1er et le 2ème point de contrôle sont à
moins de 10m entre eux. En revanche, les capteurs entre le 2ème et le 3ème point de contrôle sont à
plus de 10m entre eux. Mais ils sont toujours équidistants les uns des autres. Par la suite, l’utilisateur
peut continuer à sélectionner les points de contrôles et à les calibrer jusqu’à ce que toutes les
positions des capteurs soient correctes.

Le fait d’utiliser les points de contrôle permet de nous simplifier la tâche, car nous n’avons pas
besoin de faire glisser tous les marqueurs. En outre, il évite de repositionner tous les autres
marqueurs, quand nous ne faisons glisser qu’un seul point de contrôle. Seulement les marqueurs
autour de ce point de contrôle sont affectés.
J’avais déjà cette idée de comment faire la calibration. Donc la première étape à faire était de
pouvoir choisir les points de contrôles et les afficher avec des icônes différentes. Dans le menu,
nous pouvons choisir le mode calibration, et quand nous sommes dans ce mode, tous les capteurs
sont affichés en même temps sur l’interface. Je n’avais pas appliqué le plugin
« Leaflet.markercluster » pour afficher les capteurs, car je n’arrivais pas à visualiser tous les
marqueurs même si le zoom est au maximum. En cliquant sur le marqueur, un message popup va
apparaître, mais il est différent de l’affichage en marker cluster.
Au début, il n’était possible que de sélectionner les points de contrôle, mais les options des raisons
n’étaient pas fournies. Pendant la réunion hebdomadaire, qui a eu lieu le mercredi, mes collègues
m’ont suggéré de mettre les propositions des raisons dans le popup et de changer les icônes, dans
la mesure où ce serait plus précis pendant la calibration. J’ai donc appliqué leur suggestion. Le
popup nous autorise à sélectionner ce capteur en tant que point de contrôle en justifiant la raison. 4
boutons radios (feu rouge, intersection, station de tram et arrêt de bus) sont fournis en tant que
raisons principales, sinon, il est possible que l’utilisateur saisisse sa raison dans le champ de texte
fourni.
Illustration 33 : Le message popup d'un capteur dans le mode calibration
Quand nous cliquons sur « Select as control point », un message d’alerte est affiché pour nous
indiquer que le capteur a été sélectionné comme point de contrôle.
Illustration 34 : Le message alerte quand nous sélectionnons un point de contrôle

Si nous n’avons pas sélectionné ou saisi une raison, le marqueur sélectionné s’affichera en rouge.
Dans le message popup, il indique que la raison n’est pas fournie. Nous pouvons le désélectionner
comme point de contrôle, et un message alerte va s’afficher.
Illustration 35 : Le message popup d'un point de contrôle
Illustration 36 : Le message alerte quand nous désélectionnons un point de contrôle
En choisissant des raisons différentes, les icônes des points de contrôles changent.
Illustration 37 : Les différents icônes des points de contrôles

A chaque fois que l’utilisateur sélectionne un point de contrôle, il va ajouter ses coordonnées dans
un tableau de points de contrôle. Ce tableau est rangé en ordre croissant d’après l’index des capteurs
et va être utilisé pour faire la calibration. En outre, chaque capteur est associé à un indicateur
« control point », si c’est un point de contrôle, son indicateur a une valeur de 1 et il a un autre
indicateur « reason » . Avec ces deux indicateurs, il peut identifier les points de contrôle et les
afficher en différentes icônes.
(Cf. Annexe B) pour voir le code d’affichage des capteurs dans le mode calibration.
J’ai passé beaucoup de temps à réaliser la case à cocher dans le message popup, car il ne
fonctionnait pas quand je cliquais sur la case. Je n’arrivais pas à vérifier si la case était validée,
Pour résoudre ce problème, j’ai effectué des recherches sur internet afin de trouver des exemples.
Enfin, je suis arrivée à vérifier si la case a été validée avec la librairie jQuery. Le temps que j’ai
consacré pour finir le message popup a été de 2 jours. Pourtant, il y a un problème que je n’ai pas
pu résoudre – il n’y a pas de coche quand nous cliquons sur la case à cocher dans le popup :
Après la sélection des points de contrôles, je devais réfléchir à un algorithme de code qui
repositionne les capteurs affectés, en faisant glisser les points de contrôles. En effet, c’était l’ étape
la plus dure, et j’ai essayé différentes méthodes qui n’ont pas fonctionné. Pour le repositionnement
des capteurs, j’avais besoin des coordonnées de la ligne de fibre optique. Par exemple, je voulais
utiliser les coordonnées des capteurs pour repositionner les capteurs le long de la fibre, mais comme
les capteurs étaient équidistants, il y avait donc un problème.
Illustration 38 : La déformation de fibre si les coordonnées des capteurs sont utilisées dans calibration
La forme de la fibre est comme dans l’illustration 36, les deux boules jaunes représentent les deux
capteurs. Si les coordonnées des capteurs sont utilisées comme repositionnement, la fibre optique
va être déformée. Donc, pour éviter ce problème, au lieu d’utiliser les coordonnées des capteurs,
j’ai utilisé les coordonnées dans le fichier GeoJSON, mais cela a été compliqué.
▪ Difficulté 1 : Il faut s’assurer que les points de contrôles glissés se collent sur la trace de la
fibre optique, bien qu’ils ne soient pas positionnés exactement sur la trace.
▪ Difficulté 2 : Il faut trouver où se situent les points de contrôles dans le fichier GeoJSON,
pour savoir quelles sont les coordonnées qui devraient être utilisées.
Ainsi, j’ai utilisé les fonctions dans le plugin « Leaflet.GeometryUtil » pour atteindre mon objectif.
En utilisant la fonction closest, j’ai pu trouver la nouvelle coordonnée sur la ligne de fibre optique.
Ensuite, j’ai également appliqué la fonction isPointOnLine pour chercher les segments auxquels les
points de contrôles se situaient.

1 4 7
Segment 1 Segment 5
Illustration 39 : Démonstration de calibration
L’illustration ci-dessus est un exemple de calibration faite par le script. Les trois marqueurs rouges
sont les points de contrôles et les marqueurs bleus sont les capteurs normaux. Toutes les petites
croix représentent les coordonnées dans le fichier GeoJSON et ils ne sont pas équidistants. La
condition est : Le deuxième point de contrôle a été glissée vers le pointeur vert mais il n’est pas
positionné exactement sur la trace de fibre optique. Pour que le point de contrôle se colle sur la
trace, premièrement, il va trouver la coordonnée d’origine. Cela étant, cette coordonnée est passée
comme paramètre dans la fonction closest et cette fonction prend en paramètres de la carte, les
coordonnées GeoJSON et la coordonnée d’origine. Ensuite, il va chercher une coordonnée liée sur
la trace qui est la plus proche avec la coordonnée d’origine et va retourner cette valeur.
Normalement, cette nouvelle coordonnée est la projection orthogonale de la coordonnée d’origine
sur la trace. Nous avons donc la coordonnée qui est positionnée exactement sur la trace de fibre
optique.
Illustration 40 : Le code pour trouver la coordonnée sur la trace quand le point de contrôle est glissé
L’étape suivante était le repositionnement des capteurs affectés en utilisant cette nouvelle
coordonnée. Pour ce faire, j’ai créé la fonction :
updatePositionSensors(lat,lng,index,points,arrayControlPoints,arrayCoordinates)
qui prend comme paramètres la latitude et la longitude de la nouvelle coordonnée, ainsi que l’index
de point de contrôle glissé, les coordonnées des capteurs, les coordonnées des points de contrôles
et les coordonnées GeoJSON.

Dans cette fonction, il contient trois conditions :
• Le premier point de contrôle est glissé
• Le dernier point de contrôle est glissé
• Il y un point de contrôle avant et après le point de contrôle glissé
Dans ces trois conditions, la différence est le nombre d’appels de la fonction RearrangePoints.
Cette fonction prend en compte deux paramètres, soit (point de contrôle avant, point de contrôle
glissé) ou (point de contrôle glissé, point de contrôle après). 8 étapes doivent être accomplies
dans cette fonction. En prenant l’exemple de l’illustration 37 qui est la 3ème condition, il
contient deux fonctions :
Rearrange Points (controlPointBefore, controlPointDragged)

RearrangePoints (controlPointDragged, controlPointAfter)
Les étapes de la première fonction sont expliquées ici :

1) Ajouter la coordonnée du premier point de contrôle dans un tableau
« arraySensorsAffected ».
2) Chercher le segment où se situe le premier point de contrôle dans les coordonnés GeoJSON
avec la fonction isPointOnLine – Segment 1.
3) Chercher le segment où se situe la nouvelle position de point de contrôle glissé dans les
coordonnés GeoJSON avec la fonction isPointOnLine – Segment 5.
4) Ajouter toutes les coordonnées de segment 1 jusqu’à segment 5 (les croix orange) dans le
tableau « arraySensorsAffected ».
5) Ajouter la nouvelle coordonnée de point de contrôle glissé dans le tableau
« arraySensorsAffected ».
6) Calculer le nombre de capteurs qui doivent être repositionnés en faisant une soustraction
des indexes des deux points de contrôles : 4 – 1 = 3 capteurs.
7) Repositionner ces 3 capteurs le long de la fibre entre le premier et le deuxième point de
contrôle, en se basant sur le tableau « arraySensorsAffected » avec la fonction utilisée avant
« interpolateOnLine ».
8) Mettre à jour les coordonnées des capteurs.
Les 8 étapes sont répétées avec le point de contrôle glissé et le troisième point de contrôle. Nous
voyons que les capteurs autour du 2ème point de contrôle sont repositionnés.
Illustration 41 : Les capteurs après la calibration
(Cf. Annexe C) pour voir le code des deux fonctions « updatePositionSensors » et

« RearrangePoints ».

Illustration 42 : L'exemple de calibration sur l'application web
La partie de l’affichage des données d’énergie a été réalisée par Munira et moi-même. Nous devions
choisir la date et la durée pour récupérer certaines données dans la base de données. La mission
concernant la base de données va être énoncée dans la partie suivante.
Illustration 43 : Le graphique de données d'énergie
L’illustration ci-dessus est un graphique de données d’énergie de capteur 1 au capteur 58.

L’utilisateur peut choisir une certaine zone des capteurs pour voir plus précisément leurs données.
Les traces bleues sur le graphique signifient les points de contrôles choisis.
Si nous avons fini la calibration sur tous les capteurs ou si nous voulions arrêter la calibration, nous
pouvons télécharger un fichier JSON qui contient toutes les coordonnées des capteurs calibrés. Ce
fichier sauvegarde les points de contrôle, donc nous pouvons toujours reprendre la calibration pour
la prochaine fois, si nous n’avons pas pu la finir. L’importation de ce fichier se fait exactement
comme avant.

Illustration 44 : Le téléchargement de fichier JSON après la calibration
Bien que ce soit une mission difficile, j’ai pu l’accomplir grâce à mon tuteur et mes collègues qui
m’ont aidé et m’ont proposé des idées quand je restais bloquée. En outre, sans avoir les fonctions
fournies par le plugin « Leaflet.GeometryUtil » , je n’aurais pas pu réaliser la calibration en peu de
temps. En fait, cette tâche m’a pris plus de temps pour réfléchir que pour écrire le code, ce qui est
très intéressant et je suis heureuse d’avoir pu réussir.
Durant ces trois semaines, j’ai pu déduire les coordonnées des capteurs d’après le fichier
GeoJSON en utilisant le plugin « Leaflet.GeometryUtil ». Ensuite, j’ai affiché tous les capteurs
avec le groupement des marqueurs en fonction de zoom en utilisant le plugin
« Leaflet.markercluster ». La dernière tâche qui m’a pris plus de 2 semaines était la calibration
des capteurs en interagissant avec l’application web. J’ai surmonté les difficultés et j’ai développé
un algorithme qui fonctionne bien. Tous les mercredis, je devais présenter les tâches accomplies
et ils m’ont prodigué des conseils utiles que j’ai beaucoup appréciés. J’ai appris à utiliser les
différents librairies et plugins qui me servaient à développer mon code. En outre, j’étais de plus en
plus à l’aise avec le langage Javascript.

III. La structure du menu et l’insertion de la base de
données
La troisième partie de mon travail était l’insertion de la base de données pour utiliser les données
stockées dans InfluxDB. Il faut pouvoir récupérer les données et les afficher dynamiquement sur
l’interface. Il est impossible d’afficher les données en temps réel, car les données qu’ils ont
récupérées sont importantes et qu’un fichier CSV local n’est pas efficace. Donc, pour se connecter
à la base de données depuis le code JavaScript, j’ai importé les modules de la bibliothèque cliente
JavaScript pour les navigateurs web. Ensuite, le code va exécuter les requêtes en se basant sur les
actions des utilisateurs afin de récupérer les données DAS. J’ai également créé différents types
d’affichage des données sur l’application web. Parallèlement avec l’insertion de la base de
données, la structure du menu se développe pour que l’utilisateur puisse faire des actions. Le menu
a été modifié et amélioré tout au long de ce stage et c’est essentiel pour comprendre comment il
fonctionne. Cette dernière tâche m’a pris presque un mois.
3.1 La structure et le fonctionnement du menu
J’ai apporté des modifications aux différentes étapes de création du menu, qui ont été réalisées par
Munira. Je vais ici expliquer le fonctionnement du menu et les modifications que j’ai faites. Au
début, le menu n’était pas divisé en sous menus et toutes les fonctionnalités étaient groupées
ensemble. Ce qui n’était pas claire pour qu’un utilisateur qui n’avait pas de guide d’utilisation. De
plus, le menu va ainsi se développer au fur et à mesure, ce qui va permettre de bien repartir les
différentes fonctionnalités. Ainsi, M. FERRARI nous a demandé de changer la structure du menu
et de le diviser en différentes parties, afin de bien distinguer les fonctionnalités. Par conséquent, le
menu a été amélioré au cours de ce stage. La dernière version du menu se compose de quatre sous
menus et d’un bouton pour actualiser et réinitialiser la page. Le menu se situe en haut à gauche de
la page.
• Setup : La configuration de l’application web (importation de fichier GeoJSON, création

et importation de fichier JSON contenant des capteurs).
• Calibration : La calibration des capteurs d’après les données d’énergie et téléchargement
d’un nouveau fichier JSON.
• Analysing data : La récupération des données de la base de données et l’affichage des
données.
• View : Le choix de vue satellite et l’affichage des capteurs.
Illustration 45 : Les quatre sous menus qui se constituent le menu

1) Setup
Ce sous menu sert à la configuration de l’application web, car c’est ici que nous devons importer
les fichiers GeoJSON et JSON pour afficher la trace de fibre optique et les capteurs sur l’application
web. C’est la première étape que l’utilisateur doit faire quand il lance cette application.
Illustration 46 : Le sous menu "Setup"
Premièrement, l’utilisateur doit choisir un fichier de format GeoJSON qui contient les coordonnées
de la fibre optique. Une fois qu’il clique sur le bouton « Import », une trace bleue va être affichée
directement sur l’interface. En outre, le nom de fichier GeoJSON importé est montré dans ce sous
menu dans la partie « Current JSON File ».
Ensuite, si c’est la première fois que l’utilisateur lance cette application et qu’il n’y a pas de fichier
contenant les coordonnées des capteurs, il peut le créer et le télécharger. Pour ce faire, il doit cliquer
sur la case « Create sensors file » et il doit choisir la distance de jauge ou l’intervalle entre deux
capteurs. En cliquant sur le bouton « Create and download », ce fichier va être téléchargé et va se
trouver dans le dossier local « Téléchargement ».

Illustration 47 : La création du fichier JSON contenant les coordonnées des capteurs
Enfin, il faut importer ce fichier JSON créé pour pouvoir afficher les capteurs positionnés à un
intervalle défini. Mais l’affichage des capteurs ne se fait pas directement en cliquant sur le bouton
« Import ». Le nom de fichier JSON importé est également affiché dans ce sous-menu dans la partie
« Current Sensor File ».
2) Calibration
Si les capteurs n’ont pas encore été calibrés, l’utilisateur doit d’abord faire la calibration afin
d’avoir les positions correctes des capteurs. Quand l’utilisateur choisit le mode calibration, tous les
capteurs sont affichés à la fois. Ensuite, nous voyons qu’il y a deux cases à cocher, « Choose date
and Time » pour choisir la date et la durée des données d’énergie que nous voulons regarder pour
faire la calibration. La case « Energy data » nous permet d’afficher les données choisies sous la
forme heatmap.
Illustration 48 : Le sous menu "Calibration"

Illustration 49 : La case pour choisir les données à un horodatage spécifique
Avant d’afficher les données d’énergie, l’utilisateur doit choisir la date et la durée, puis cliquer sur
« Submit » pour que la requête soit exécutée avec la durée donnée. Par la suite, il faut cocher la
case « Energy data » pour afficher les données d’énergie de tous les capteurs.
Illustration 50 : L'affichage des données d'énergie en cochant la case "Energy data"
Après avoir fini la calibration, il est possible de télécharger un fichier JSON contenant les
coordonnées des capteurs calibrés en cliquant sur le bouton « Download ». Pour importer ce fichier,
il faut revenir dans le sous menu « Setup ».

3) Analysing data
Cette partie est utilisée pour afficher les données brutes ou les données interprétées par l’équipe
avec les algorithmes IA. Quand l’utilisateur est dans le mode analyse, les capteurs ne seront pas
affichés. Ce sous menu contient quatre sections : Date and Time, Energy, Strain et Vehicle Count.
La section « Date and Time » est utilisée pour la configuration de l’affichage et les trois sections
restantes sont les différents types de données stockées dans la base de données.
Illustration 51 : Les modes dynamique et statique dans la partie "Display Energy
La section « Date and Time » est comme dans le sous menu « Calibration », il sert à choisir la date
et la durée des données dans la base de données. En revanche, la différence est qu’il faut d’abord
choisir le « bucket » (il peut avoir plusieurs buckets qui stockent les différentes données, « bucket »
signifie le tableau qui contient les données). Ensuite, il faut choisir l’intervalle d’horodatage afin
de récupérer les données avec une durée choisie. Pour terminer, il est possible de choisir un
intervalle de capteurs pour avoir l’affichage dans certaine zone.
Illustration 52 : La section "Date and Time" pour la configuration
Si l’utilisateur veut analyser les données d’énergie, il faut aller dans la section « Energy » qui
contient trois parties : « Query Energy Data », « Display Energy » et « Time Series ». En cliquant
sur le bouton « Query Energy Data », il va chercher les données d’énergie dans la base de données
d’après la configuration faite dans la section « Date and Time ». La partie « Display Energy » nous

permet de visualiser les données de façon dynamique ou statique. L’affichage dynamique nous
montre toutes les données que nous avons choisies pendant certaine durée et l’affichage statique
montre les données à un certain instant. En plus, les données sont visualisées directement sur la
trace en mode spatiale.
Illustration 53 : L'affichage dynamique et statique des données d'énergie
Nous pouvons aussi visualiser les données en mode temporelle en cliquant la section « Time
Series ». Ici, deux options sont fournies, soit les données d’énergie de tous les capteurs, soit d’un
seul capteur. Les données sont affichées dans une fenêtre popup sous la forme de graphe. Cette
partie d’affichage a été réalisée par Munira et j’ai réalisé la partie « Display Energy ».
Illustration 54 : L'affichage de série temporelle des donnés d'énergie
Dans la section « Strain », l’utilisateur peut visualiser les données de pression en cochant la case
« Strain data » et les données seront affichés sous la forme graphe dans une fenêtre popup. Les
explications de sous-menu « Analysing data » seront indiqués dans la partie suivante.
Illustration 55 : La section "Strain" dans le sous menu "Analysing data"

La section « Vehicle Count » affiche le nombre de véhicules passés sur chaque capteur dans un
intervalle de temps. Ces données ont été analysées par l’équipe DAS. En revanche, les données
d’énergie et de pression sont les données brutes. Dans cette section, nous trouverons les mêmes
parties que la section « Energy ». Nous pouvons également exécuter les requêtes, afficher en mode
dynamique ou statique et afficher les séries temporelles (le nombre de véhicule sur un capteur
choisi ou sur tous les capteurs).
Illustration 56 : La section "Vehicle Count" dans le sous menu "Analysing data"
4) View
Dans le sous menu « View », il contient deux cases à cocher « Satellite view » et « Markers ». Il
permet de changer la couche pour la vue satellite ou la couche pour afficher les capteurs en cluster.
À la fin, nous avons le bouton « Actualiser », qui permet de tout réinitialiser pour revenir sur le
point d’origine, c’est-à-dire tout effacer, sauf le fichier GeoJSON et le fichier JSON.
Illustration 57 : Le sous menu "View"
Comme indiqué dans la partie « Calibration » et « Analysing data », il faut afficher tous les
marqueurs quand le mode calibration est sélectionné et il faut cacher tous les marqueurs quand le
mode analyse est sélectionné. De plus, nous devons rester dans le même mode après avoir rafraîchi
la page (rafraîchir sans utiliser le bouton). Pour ce faire, j’ai ajouté la fonction handleClick dans les
deux boutons radios « Calibration » et « Analysing data ». Si l’un des deux boutons est cliqué, il
vérifie s’ils sont sélectionnés et il ajoute soit vrai ou faux dans le stockage de session.
Illustration 58 : Le code pour vérifier quel mode a été sélectionné

Ensuite, il récupère ces deux valeurs à chaque actualisation de page, si
sessionStorage.getItem('calibrationChecked') égale à « Vrai », la couche de tous les capteurs sera
ajoutée. Cependant, si sessionStorage.getItem('analyseChecked') égale à « Vrai », toutes les
couches des marqueurs seront enlevées. J’ai passé une journée à réaliser cette fonctionnalité, car je
n’arrivais pas à maintenir le mode choisi après avoir actualisé la page. Pour résoudre ce problème,
j’ai ajouté la fonction handleClick(), ce qui a bien fonctionné.
Illustration 59 : Le code pour vérifier quel mode a été choisi
La structure du menu est très importante pour créer une application web qui est facile à utiliser. Il
faut aussi être clair pour que les autres puissent ajouter d’autres fonctionnalités. C’est la raison pour
laquelle Munira et moi-même avons mis du temps à développer et à améliorer ce menu. J’ai
beaucoup réfléchi sur la structure de menu avec Munira pour pouvoir mettre en place l’ensemble
des fonctionnalités que nous avons créées sur l’interface. Nous sommes satisfaites de ce menu
réactif et flexible.

3.2 L’insertion de la base de données « InfluxDB »
Avant d’utiliser la base de données pour accéder aux données DAS, nous avons mis en place un
fichier CSV contenant les données d’énergie pour visualiser la trace dynamique et pour réaliser les
graphes de séries temporelles. Cependant, les données dans le fichier CSV étaient très limitées et
le navigateur ne pouvait pas supporter une énorme quantité de données. Par conséquent, la
meilleure solution était de stocker tous les différents types de données dans une base de données,
et l’application web devait pouvoir accéder à cette base de données en exécutant les requêtes.
Pendant une semaine, ils ont cherché et essayé plusieurs bases de données (QuasarDB,
TimeScaleDB, …), afin de trouver la meilleure base de données pour stocker les séries temporelles.
En même temps, M. FERRARI nous a demandé de chercher comment modifier nos scripts pour
qu’ils tournent dans le serveur Node.js au lieu de tourner dans le navigateur. En effet, la plupart
des bases de données fournissent API de librairie des clients pour Node.js mais pas pour JavaScript
sur navigateur.
Pour ce faire, j’ai fait des recherches sur Internet mais c’était plus compliqué que je ne le pensais
car nous avons dizaines de fichiers (CSS, HTML, JS) qui construisent cette application web. Donc,
c’était dur de combiner tous les fichiers différents. En fait, j’ai essayé d’appliquer le Framework
« express » et d’utiliser « express.static » qui met tout le dossier en public. L’application web
fonctionnait quand je l’ai lancée en Node.js. Mais l’application web avait l’air de tourner toujours
dans le navigateur, mais pas dans Node.js. Ainsi, j’ai abandonné cette fonction après quelques jours
d’essai. Finalement, ils ont choisi la base de données « InfluxDB », qui supporte JavaScript sur le
navigateur. Elle mobilise une librairie client JavaScript pour interagir avec l’API InfluxDB dans
les navigateurs des clients frontend.
Illustration 60 : Le logo de "InfluxDB"
Illustration 61 : L'interface web d'utilisateur sur InfluxDB

Nous pouvons accéder à la base de données en passant par web UI de « InfluxDB » avec l’adresse
suivante : http://192.168.108.171:8086/. La base de données a été installée dans le serveur, qui
est un ordinateur local au laboratoire. Avec cette interface web, nous pouvons exécuter les requêtes
pour récupérer les données dans les « buckets » créés. J’ai souvent utilisé cette interface pour faire
le débogage en regardant les résultats des requêtes. (Cf. Annexe D)
Afin de se connecter sur la base de données InfluxDB depuis JavaScript sur le navigateur, il faut
tout d’abord importer les modules à partir de la dernière distribution du navigateur de la
bibliothèque cliente.
Illustration 62 : Le code pour l'importation des modules InfluxDB
Ensuite, j’avais besoin de 3 variables d’environnement, l’identifiant de l’organisation, l’url

(http://192.168.108.171:8086/) et le token API. En utilisant ces trois variables, j’ai récupéré un
client configuré par l’organisation. Ce « client » va être utilisé pour exécuter les requêtes.
Illustration 63 : Le code pour créer un client configuré
L’étape suivante était de définir une requête avec le nom de bucket, où nous devions chercher les
données et la durée ( heure de départ et heure de fin). Comme indiqué dans la partie précédente (la
structure du menu), l’utilisateur peut choisir le bucket et la durée pour les données d’énergie, les
données de pression ou les données de comptage des véhicules. Alors, la requête contient trois
paramètres flexibles : le nom de bucket, l’heure de départ et l’heure de fin. Ici c’est un exemple de
requête pour récupérer les données de pression. Nous voyons que le filtre est défini pour récupérer
les données de type « strain ».
Illustration 64 : La définition de requête pour récupérer les données de pression
Par la suite, l’observateur qui allait traiter le résultat de cette requête devait être défini aussi. Il va
collecter les résultats ligne par ligne. Une fois que tous les résultats sont récupérés, ils vont être
envoyés à d’autres fonctions en tant que paramètres pour pouvoir les afficher en graphique. Ici,
toutes les lignes sont arrangées d’après l’index de capteur, car ils ne sont pas en ordre. À chaque
ligne, il récupère la valeur et le temps, puis les ranger dans un tableau avec l’index de capteur
comme le label. De plus, il récupère toutes les valeurs dans un tableau pour calculer son écart type.
Illustration 65 : Les résultats récupérés après les avoir arrangés

Illustration 66 : L'observer qui traite la requête
Finalement, il exécute la requête avec deux paramètres : la requête et l’observer.
Illustration 67 : Le code pour l'exécution de la requête
Au total, il y a 5 différentes requêtes, une pour afficher les informations du bucket quand
l’utilisateur soumet un bucket. Il récupère et affiche les intervalles de temps pour les différentes
données disponibles. (Cf. Annexe E)
Illustration 68 : Le message alerte pour montrer les informations du bucket
Les trois autres requêtes servent à récupérer les données d’énergie, les données de pression et les
données de comptage de véhicules dans le mode « Analysing data ». Une requête est utilisée pour
récupérer les données d’énergie dans le mode « Calibration ». La structure des requêtes est à peu
près pareille, ce qui est différent c’est la fonction appliquée pour utiliser ces données. Une fois les
données récupérées, un message d’alerte va être affiché.
Illustration 69 : Le message alerte quand il a fini la récupération des données

Grâce à la possibilité d’exécuter les requêtes directement sur le navigateur des clients, nous n’avons
pas besoin d’un environnement Node.js pour accéder à la base de données. La vitesse pour la
récupération des données dépend de la durée choisie. Plus la durée est longue, plus long est le temps
d’attente pour que les données soient chargées complètement. InfluxDB était assez facile à utiliser
et j’ai beaucoup travaillé sur la documentation d’API pour adapter notre code à l’insertion de la
base de données. J’ai passé toute une journée avant de réussir à me connecter sur la base de données
et à exécuter les requêtes. L’étape suivante était de réaliser l’affichage en utilisant ces données, et
il nous a fallu faire des modifications de code pour s’adapter à la base de données. Cette troisième
mission a pris plus de temps.
3.3 La présentation des données en interagissant avec la base de données
Dans le mode « Analysing data », nous pouvons visualiser les données spatialement et
temporellement sur l’application web. Comme indiqué dans la partie précédente, toutes les données
sont récupérées de la base de données à chaque fois que nous faisons une action. Pour réaliser cette
mission, Munira et moi avons travaillé ensemble la plupart du temps, mais l’affichage de graphique
en utilisant Plotly dans une fenêtre popup a été réalisé par Munira. Pour ma part, je travaillais plutôt
sur l’affichage spatial et l’adaptation de code avec la base de données. Comme la section « Energy »
et la section « Vehicle Count » se ressemblent, je résous ici la réalisation de la partie « Display
Energy », qui sert à montrer les données d’énergie directement sur la trace spatialement, mais je
n’explique pas la partie « Time Series » qui a été réalisé par Munira.
Disons que nous avons fait la configuration pour la récupération des données dans la partie « Date
and Time » car nous voulons analyser les données d’énergie spatialement. Après avoir cliqué sur
le bouton « Query Energy Data » qui va exécuter la requête, nous allons dans la section « Display
Energy », et ensuite nous cliquons sur le bouton radio « Dynamique ». Nous voyons l’intervalle
des capteurs que nous avons choisi dans la section « Date and Time ». Ici, nous avons choisi tous
les capteurs donc 1 – 1875. En cliquant sur le bouton « Submit », les données d’énergie seront
affichées sur la trace de fibre optique de façon dynamique, nous voyons un mouvement de la trace
en changeant les couleurs à chaque instant. Plus précisément, les couleurs correspondent à
l’intensité d’énergie sur chaque capteur, et en faisant une boucle pour montrer les données à chaque
instant, nous voyons un mouvement des couleurs sur la trace.
Illustration 70 : Le choix des capteurs dans l'affichage dynamique

Illustration 71 : L'affichage dynamique des données d'énergie
Pour ce faire, j’ai appliqué le plugin « Leaflet.hotline », un plugin pour dessiner des dégradés
colorés le long des polylignes. Ceci est utile pour visualiser les valeurs le long d'un parcours par
exemple, l' altitude et la vitesse. Donc, notre cas est l’intensité d’énergie. J’ai utilisé la fonction «
L.hotline » qui prend en paramètre un tableau des coordonnées (latitude, longitude) et les valeurs
d’énergies à chaque capteur. La configuration pour le dégradé de la palette est : vert – jaune –
rouge. De plus, la valeur minimale attendue est 0 et la valeur maximale attendue est 3, car les
valeurs d’énergie sont dans cet intervalle. Afin d’afficher les données en boucle, j’ai créé la fonction
animateLines() qui fait la récurrence en utilisant la fonction
window.requestAnimationFrame(animateLines).
Illustration 72 : Le code pour faire l'affichage en mode dynamique
La fonction « L.Hotline » prend comme paramètre un tableau « time » qui a la structure dans
l’illustration ci-dessous. Pour faire cette boucle, j’ai utilisé un compteur pour répéter l’animation.
Quand ce compteur a une valeur égale à la longueur de tableau « time », il remet ce compteur à 0.
Cependant, si le compteur est inférieur à la longueur de tableau, elle appelle sa fonction elle-même.
Illustration 73 : Le tableau "time" pour faire l'animation de la trace

Le deuxième cas de l’affichage en dynamique est le choix d’une zone des capteurs. Par exemple,
nous avons choisi les capteurs 660 – 950 qui sont des capteurs positionnés le long de la voie Mathis.
Donc, sauf l’affichage dynamique sur la voie Mathis, il faut également montrer la trace bleue en
dehors des capteurs 660 - 950.
Illustration 74 : L'affichage dynamique sur la voie Mathis
Pour arriver à visualiser la trace bleu avant le capteur 660 et après le capteur 950, j’ai créé deux
tableaux, le premier contient les coordonnées de capteur 1 à capteur 660 et le deuxième contient
les coordonnées de capteur 950 à capteur 1875. Ensuite, ces deux tableaux sont utilisés pour ajouter
deux polylignes sur la carte.
Illustration 75 : Le code pour ajouter les deux polylignes dans le mode dynamique
En cliquant sur le bouton radio « Statique », nous devons choisir un horodatage pour visualiser les
données d’énergie à un instant spécifique. Quand la requête est exécutée, il récupère les valeurs
d’énergie et aussi les temps. Dans le mode statique, il va chercher les valeurs d’énergies
correspondant à l’instant choisi puis créer un tableau contenant ces valeurs et les coordonnées.
Ensuite, j’ai utilisé « L.hotline » pour créer la couche, qui va être ajoutée sur la carte. Comme c’est
l’affichage en mode statique, il n’y a donc pas besoin de boucle. La configuration de l’affichage en
mode statique est la même que celle en mode dynamique.

Illustration 76 : L'affichage des données d'énergie en mode statique.
Par la suite, j’ai également réalisé l’affichage spatial des donnés de comptage des véhicules dans
la partie « Display Count ». La réalisation était la même comme pour les données d’énergie –
l’affichage dynamique et statique.
La difficulté de cette mission était l’adaptation de code, car nous avons préalablement réalisé
l’affichage des données, mais avec un fichier CSV. Donc, nous avons eu des problèmes de
condition, c’est-à-dire quel type d’affichage doit être montré avec les options choisies par
l’utilisateur. Nous avons réfléchi sur la structure du code pour fixer ce problème. De plus, il n’y a
pas beaucoup de communauté publique sur l’utilisation de InfluxDB. Donc, je ne pouvais que me
baser sur la documentation fournie par InfluxDB. Cette tâche a été réalisée jusqu’à la dixième
semaine. Enfin, j’ai ajouté les commentaires dans le code pour que mes collègues ou les prochains
stagiaires puissent continuer ce projet.
Grâce à l’utilisation de la base de données, il est possible de choisir et récupérer les données
spécifiques. L’extension possible sera la récupération et l’affichage des données en temps réel. J’ai
atteint mon objectif fixé – créer une application web interactive qui visualise les résultats DAS de
façon dynamique. J’ai pris connaissance de l’application de la base de données InfluxDB avec
Javascript et de l’intégration de code avec InfluxDB. Avec le menu qui donne des options variées,
l’utilisateur peut illustrer les différents types de données afin de réaliser facilement des analyses.
L’utilisation des plugins m’a permis de faciliter ma tâche et de pouvoir réaliser ces beaux
affichages des données. En outre, j’ai également appris que la réflexion logique avant de coder est
très importante pour produire une solution efficace. Cette étape m’a pris plus de temps.

CONCLUSION
Durant ces 11 semaines de stage passées au Laboratoire Lagrange dans l’équipe SI, j’ai pu
accomplir ma mission de construire une application web interactive qui facilite les interprétations
des données DAS et leur permette d’avoir une vision globale de ce projet DAS. Cette application
web a été développée en se basant sur les besoins de l’équipe. Guidé par M. FERRARI, j’ai donc
pu réaliser une interface qui leur permette de faire la calibration des capteurs, d’analyser les
données et de présenter le projet DAS au public de façon plus compréhensible. De plus, avec les
conseils et les aides de mes collègues, j’ai réussi à répondre à leurs besoins en adaptant l’interface
au fur à mesure pour qu’elle soit plus performante. J’ai découvert comment utiliser les librairies et
les plugins JavaScript pour mettre en place les fonctionnalités utiles pour une réalisation efficace
des différentes étapes de mon travail.
D’un point de vue plus personnel, j’ai beaucoup apprécié ce stage car j’ai approfondi mes
compétences dans le domaine du développement web en utilisant JavaScript. J’ai pu acquérir des
connaissances dans des domaines que je n’ai pas pu aborder pendant mes cours à l’IUT. De plus,
les réunions hebdomadaires m’ont permis de développer mes compétences de présentation, dans la
mesure où j’ai dû présenter l’avancement de mon travail pour que mes collègues puissent me suivre
et me prodiguer des conseils. J’ai aussi appris à travailler en équipe et à utiliser l’outil Git pour bien
répartir le travail. Ce stage très enrichissant m’a donné l’opportunité de comprendre comment une
activité de recherche fonctionne. Il m’a également permis de rencontrer des professionnels dans le
domaine des recherches. Ce que j’ai particulièrement apprécié était la réflexion pour trouver la
solution et la satisfaction après avoir eu le résultat. Cela m’a énormément motivée tout au long de
ce stage.
Actuellement, bien que cette application web fournisse des fonctionnalités variées, il reste
encore des améliorations à faire, car le projet DAS n’est pas encore terminé. La structure du menu
de l’interface pourra être plus performante pour optimiser la fluidité de l’interface. De plus, il reste
encore des possibilités dans la partie affichage des données car l’équipe travaille toujours sur
l’analyse des données DAS. Donc, il existe les données qui ne sont pas encore intégrées dans
l’application et également les autres façons de présentation des données. Ce sont les améliorations
qui pourront être faites par les futurs stagiaires.

BIBLIOGRAPHIE
1) AGAFONKIN, V., Leaflet [en ligne]. 18 avril 2022, [consulté le 4 avril 2022].
Disponible sur https://leafletjs.com/
2) BECQUET, B., Leaflet.GeometryUtil [en ligne]. 24 mars 2013, 1 février 2019,

[consulté le 7 avril 2022]. Disponible sur
https://github.com/makinacorpus/Leaflet.GeometryUtil
3) LEAVER, D., Leaflet.markercluster [en ligne]. 8 juillet 2012, 18 octobre 2021,

https://github.com/Leaflet/Leaflet.markercluster
4) WANG, F., Leaflet.hotline [en ligne]. 20 juillet 2015, 28 février 2017, [consulté le 11
avril 2022]. Disponible sur https://github.com/iosphere/Leaflet.hotline
5) Window.requestAnimationFrame() [en ligne]. 16 mars 2022, [consulté le 12 avril

2022]. Disponible sur
https://developer.mozilla.org/fr/docs/Web/API/Window/requestAnimationFrame
6) Leaflet changing Marker color [en ligne]. 9 mai 2014, consulté le 20 avril 2022].
Disponible sur https://stackoverflow.com/questions/23567203/leaflet-changing-
marker-color
7) Download JSON object as a file from browser [en ligne]. YU, E., 1 novembre 2013,
https://stackoverflow.com/questions/19721439/download-json-object-as-a-file-from-
browser/30800715#30800715
8) Plotly [en ligne]. [consulté le 6 mai 2022]. Disponible sur https://plotly.com/
9) Query with the InfluxDB JavaScript client library [en ligne]. [consulté le 16 mai
2022]. Disponible sur https://docs.influxdata.com/influxdb/cloud/api-guide/client-
libraries/nodejs/query/

ANNEXES
Annexe A : Journal de Bord du stage avec deux exemples et la répartition du travail

Annexe B : Le code pour afficher des capteurs dans le mode calibration

Annexe C : Le code pour la calibration des capteurs

Annexe D : L’exemple des données stockées dans InfluxDB sur web UI

Annexe E : Le code pour récupérer et afficher les informations du bucket choisi

TABLE DES ILLUSTRATIONS
Illustration 1 : Bâtiment Fizeau de Laboratoire Lagrange à Valrose ................................................................. 1
Illustration 2 : Les trois laboratoires de recherches constitués sous OCA .......................................................... 5
Illustration 3 : L’organigramme de l’OCA ........................................................................................................ 6
Illustration 4 : Organigramme de l’équipe DAS ................................................................................................ 8
Illustration 5 : Mon bureau de travail avec un iMac .......................................................................................... 8
Illustration 6 : Les quatre outils et logiciels utilisés......................................................................................... 12
Illustration 7 : Le schéma de répartition des tâches avec les branches ............................................................. 13
Illustration 8 : La répartition du travail entre Munira et moi ........................................................................... 13
Illustration 9 : La structure de dossier SequoiaFE .......................................................................................... 14
Illustration 10 : Le logo de librairie Leaflet .................................................................................................... 15
Illustration 11 : Le code pour visualiser la carte avec Leaflet .......................................................................... 15
Illustration 12 : La carte de Nice sur l'application web ................................................................................... 16
Illustration 13 : La carte de Nice en vue satellite............................................................................................. 16
Illustration 14 : La carte de Nice en vue satellite agrandie .............................................................................. 17
Illustration 15 : Le code pour lire le fichier GeoJSON importé ........................................................................ 18
Illustration 16 : Les données sous format GeoJSON récupérées ...................................................................... 18
Illustration 17 : Le code pour réaliser la trace de fibre optique ....................................................................... 19
Illustration 18 : La ligne de fibre optique sur la carte ..................................................................................... 19
Illustration 19 : L'exemple représentant les positions des capteurs avec gauge = 6m ....................................... 21
Illustration 20 : Le code pour générer un fichier JSON contenant des coordonnées des capteurs ..................... 22
Illustration 21 : Le tableau de distances accumulées ....................................................................................... 22
Illustration 22 : Le tableau de ratio calculé..................................................................................................... 23
Illustration 23 : Le tableau des coordonnées des capteurs ............................................................................... 23
Illustration 24 : La création et le téléchargement de fichier JSON sur l'interface ............................................. 24
Illustration 25 : L’ensemble des marqueurs affichés sur l'interface .................................................................. 25
Illustration 26 : Le code pour afficher les capteurs de forme marker cluster .................................................... 26
Illustration 27 : Les capteurs affichés sous la forme cluster ............................................................................. 26
Illustration 28 : Les clusters quand nous cliquons sur un cluster ..................................................................... 27
Illustration 29 : Les marqueurs avec une démonstration de popup au capteur 231 ........................................... 27
Illustration 30 : La démonstration des marqueurs avant la calibration ............................................................ 28
Illustration 31 : Le plot des données d’énergie pendant 10 minutes ................................................................. 29
Illustration 32 : Les capteurs repositionnés après la calibration ...................................................................... 29
Illustration 33 : Le message popup d'un capteur dans le mode calibration ....................................................... 30
Illustration 34 : Le message alerte quand nous sélectionnons un point de contrôle .......................................... 30
Illustration 35 : Le message popup d'un point de contrôle ............................................................................... 31
Illustration 36 : Le message alerte quand nous désélectionnons un point de contrôle ....................................... 31
Illustration 37 : Les différents icônes des points de contrôles .......................................................................... 31
Illustration 38 : La déformation de fibre si les coordonnées des capteurs sont utilisées dans calibration .......... 32

Illustration 39 : Démonstration de calibration ................................................................................................ 33
Illustration 40 : Le code pour trouver la coordonnée sur la trace quand le point de contrôle est glissé ............ 33
Illustration 41 : Les capteurs après la calibration ........................................................................................... 34
Illustration 42 : L'exemple de calibration sur l'application web ....................................................................... 35
Illustration 43 : Le graphique de données d'énergie ........................................................................................ 35
Illustration 44 : Le téléchargement de fichier JSON après la calibration ......................................................... 36
Illustration 45 : Les quatre sous menus qui se constituent le menu ................................................................... 37
Illustration 46 : Le sous menu "Setup" ............................................................................................................ 38
Illustration 47 : La création du fichier JSON contenant les coordonnées des capteurs ..................................... 39
Illustration 48 : Le sous menu "Calibration" ................................................................................................... 39
Illustration 49 : La case pour choisir les données à un horodatage spécifique ................................................. 40
Illustration 50 : L'affichage des données d'énergie en cochant la case "Energy data" ...................................... 40
Illustration 51 : Les modes dynamique et statique dans la partie "Display Energy ........................................... 41
Illustration 52 : La section "Date and Time" pour la configuration ................................................................. 41
Illustration 53 : L'affichage dynamique et statique des données d'énergie ........................................................ 42
Illustration 54 : L'affichage de série temporelle des donnés d'énergie.............................................................. 42
Illustration 55 : La section "Strain" dans le sous menu "Analysing data" ......................................................... 42
Illustration 56 : La section "Vehicle Count" dans le sous menu "Analysing data" ............................................ 43
Illustration 57 : Le sous menu "View" ............................................................................................................. 43
Illustration 58 : Le code pour vérifier quel mode a été sélectionné .................................................................. 43
Illustration 59 : Le code pour vérifier quel mode a été choisi .......................................................................... 44
Illustration 60 : Le logo de "InfluxDB" ........................................................................................................... 45
Illustration 61 : L'interface web d'utilisateur sur InfluxDB .............................................................................. 45
Illustration 62 : Le code pour l'importation des modules InfluxDB .................................................................. 46
Illustration 63 : Le code pour créer un client configuré ................................................................................... 46
Illustration 64 : La définition de requête pour récupérer les données de pression ............................................ 46
Illustration 65 : Les résultats récupérés après les avoir arrangés .................................................................... 46
Illustration 66 : L'observer qui traite la requête .............................................................................................. 47
Illustration 67 : Le code pour l'exécution de la requête ................................................................................... 47
Illustration 68 : Le message alerte pour montrer les informations du bucket .................................................... 47
Illustration 69 : Le message alerte quand il a fini la récupération des données ................................................ 47
Illustration 70 : Le choix des capteurs dans l'affichage dynamique .................................................................. 48
Illustration 71 : L'affichage dynamique des données d'énergie ........................................................................ 49
Illustration 72 : Le code pour faire l'affichage en mode dynamique ................................................................. 49
Illustration 73 : Le tableau "time" pour faire l'animation de la trace ............................................................... 49
Illustration 74 : L'affichage dynamique sur la voie Mathis .............................................................................. 50
Illustration 75 : Le code pour ajouter les deux polylignes dans le mode dynamique ......................................... 50
Illustration 76 : L'affichage des données d'énergie en mode statique. .............................................................. 51

LISTE DES ABRÉVIATIONS
DAS Distributed Acoustic Sensing
SI Signal et Image
HTML HyperText Markup Language
CSV Comma-separated values
JSON JavaScript Object Notation
API Application Programming Interface
CSS Cascading Style Sheets
IA Intelligence Artificielle
URL Uniform Resource Locator

Exemple-Rapport de Stage Developpment

Transféré par

Droits d'auteur :

Formats disponibles

Exemple-Rapport de Stage Developpment

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Exemple-Rapport de Stage Developpment

Transféré par

Droits d'auteur :

Formats disponibles

Département RÉSEAUX ET TÉLÉCOMMUNICATIONS

Développement d’une application web qui visualise les

Rapport de stage rédigé par Ker Chee TUNG

Illustration 1 : Bâtiment Fizeau de Laboratoire Lagrange à Valrose

Observatoire de la Côte d’Azur

Autorise la diffusion en interne Michel GAUTERO

PRÉSENTATION DE RAPPORT DE STAGE

Développement d’une application web qui visualise les

Rapport rédigé par :

Ker Chee TUNG

Étudiante de DUT Réseaux et Télécommunications

Tuteur de stage : Tuteur à l’IUT :

Copies du présent document :

Département Réseaux et Télécommunications : 1

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 2

Ensuite, je voudrais exprimer mes sincères remerciements à tout le personnel de l’équipe

J’adresse également mes remerciements à mon tuteur, M. Michel GAUTERO, maitre de

Enfin, je tiens à remercier toute l’équipe pédagogique et administrative du département

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 3

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 4

L’OCA se contribue dans les activités de recherche en sciences de la Terre et de l’Univers de la

Illustration 2 : Les trois laboratoires de recherches constitués sous OCA

1) Mont Gros où se trouve le siège (site historique de l’Observatoire de la Côte d’Azur)

Les trois domaines principaux de l’OCA sont la :

2) Formation - contribuer à la formation initiale et continue d'étudiants et de l'ensemble des

3) Culture Scientifique - concourir à la diffusion des connaissances, en particulier auprès du

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 5

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 6

Ce laboratoire rassemble des équipes d’astrophysique (planétologie, physique stellaire et solaire,

Les missions et les activités de l’équipe SI sont liées sur :

• Le développement des théories et méthodes en traitement du signal et des données

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 7

André Martijn Yacine Selina

Anthony Ker Chee

Illustration 4 : Organigramme de l’équipe DAS

Illustration 5 : Mon bureau de travail avec un iMac

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 8

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 9

My second mission was to create calibration of positions of sensors on the interface.

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 10

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 11

1.1 Choix des outils et des logiciels pour l’environnement de développement

Illustration 6 : Les quatre outils et logiciels utilisés

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 12

Illustration 7 : Le schéma de répartition des tâches avec les branches

Illustration 8 : La répartition du travail entre Munira et moi

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 13

Illustration 9 : La structure de dossier SequoiaFE

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 14

Illustration 10 : Le logo de librairie Leaflet

Illustration 11 : Le code pour visualiser la carte avec Leaflet

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 15

Illustration 12 : La carte de Nice sur l'application web

Illustration 13 : La carte de Nice en vue satellite

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 16

1.3 Insertion de la trace de fibre optique sur la carte réalisée

KER CHEE TUNG – IUT NICE SOPHIA ANTIPOLIS 17

Illustration 15 : Le code pour lire le fichier GeoJSON importé

Illustration 16 : Les données sous format GeoJSON récupérées