Indexation et recherche d’image par le contenu et par la localisation géographique

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.52 MB, 52 trang )

(1)<div class='page_container' data-page=1>

INSTITUT DE LA FRANCOPHONIE POUR L’INFORMATIQUE

LABORATOIRE INFORMATIQUE, IMAGE ET INTERACTION

UNIVERSITE DE LA ROCHELLE

MEMOIRE DE FIN D’ETUDE

Master d’informatique

Option Intelligence artificielle & multimédia

Sujet : Indexation et recherche d’image par le

contenu et par la localisation géographique

Encadrement :

Jean-Marc OGIER

Alain BOUCHER

NGUYEN Nhu Van

Réalisé par :

LAI Hien Phuong

Promotion 13, IFI

</div>
(2)<div class='page_container' data-page=2>

TABLE DES MATIERES

REMERCIEMENTS ...3

RESUME...4

ABSTRACT ...5

LISTE DES FIGURES...6

LISTE DES TABLEAUX ...7

CHAPITRE 1 – INTRODUCTION ...8

1.1.PROBLEMATIQUE...8

1.2.MOTIVATION...9

1.3.OBJECTIFS...10

1.4.CONTRIBUTION...10

1.5.ENVIRONNEMENT DE STAGE...11

CHAPITRE 2 – ETAT DE L’ART ...12

2.1.INDEXATION MULTIDIMENSIONNELLE...12

2.1.1 Partitionnement des données ...12

2.1.2 Partitionnement de l’espace...17

2.2.TRAVAUX SIMILAIRES...19

2.2.1 SnapToTell [11][12][13][14] ...19

2.2.2 MobiLog [15]...22

CHAPITRE 3 – SR-TREE...24

3.1.PRESENTATION DU SR-TREE...24

3.2.INSERTION DANS LE SR-TREE...26

3.3.SUPPRESSION DANS LE SR-TREE...29

3.4.RECHERCHE DANS LE SR-TREE...29

CHAPITRE 4 – SYSTEME DE RECHERCHE D’INFORMATIONS BASE SUR UNE DOUBLE 
INFORMATION DE CONTENU DES IMAGES ET DE LOCALISATION GEOGRAPHIQUE ...31

4.1.HYPOTHESES...31

4.2.APPROCHE PROPOSEE...32

4.2.1 Structuration des données ...32

4.2.2 Manipulation dans les SR-tree ...36

4.3.IMPLEMENTATION DU SYSTEME...40

4.3.1 Préparation des données...40

4.3.2 Environnement de programmation ...41

4.3.3 Système construit ...41

CHAPITRE 5 – ANALYSE DES RESULTATS...43

5.1.SCENARIO 1 : ATTRIBUTION DES NIVEAUX D’URGENCE...43

5.2.SCENARIO 2 : DETERMINATION DES MONUMENTS PROCHES DU SINISTRE...45

5.3.SCENARIO 3 : DETERMINATION DES SINISTRES PROCHES D’UN MONUMENT...46

5.4.SCENARIO 4 : DETERMINATION DES SINISTRES PROCHES D’UN SINISTRE...47

5.5.SCENARIO 5 : DETERMINATION DES SINISTRES SIMILAIRES A UN AUTRE SINISTRE...48

CHAPITRE 6 – CONCLUSIONS ET PERSPECTIVES...49

</div>
(3)<div class='page_container' data-page=3>

REMERCIEMENTS

Je tiens à remercier tout particulièrement M. Jean-Marc OGIER, mon superviseur
de stage au laboratoire L3I de l’université de La Rochelle, et M. Alain BOUCHER, mon
co-superviseur de stage à l’IFI. Ils ont su orienter mon travail dans les bonnes directions
tout en me laissant une large autonomie. Je les remercie également pour leur gros travail
pour corriger ce rapport de stage.

Mes remerciements s’adressent également à M. NGUYEN Nhu Van qui m’a aidé
dans la configuration l’environnement de programmation. Mon travail bénéficie aussi son
travail de thèse de la recherche d’image par le contenu.

Je remercie aussi M. CHU Thanh Quang, un thésard du laboratoire MSI. Ce travail
est en grande partie dû à ses conseils sur les Systèmes d’Information Géographique (SIG).

Je tiens à remercier également tous les membres du laboratoire L3I qui m’ont
accueilli et ont créé un environnement idéal dans lequel j’ai travaillé pendant six mois de

stage.

Je voudrais aussi adresser mes remerciements à tous les professeurs de l’IFI qui
m’ont donné des connaissances et des expériences efficaces pendant ma scolarité à l’IFI.

</div>
(4)<div class='page_container' data-page=4>

RESUME

</div>
(5)<div class='page_container' data-page=5>

ABSTRACT

</div>
(6)<div class='page_container' data-page=6>

LISTE DES FIGURES

Figure 1 - B-tree ... 13

Figure 2 - R-tree ... 14

Figure 3 - SS-tree... 16

Figure 4 - SR-tree ... 17

Figure 5 - Kd-tree ... 18

Figure 6 - LSD-tree... 19

Figure 7 - Architecture client/serveur du système SnapToTell ... 20

Figure 8 - Localisation hiérarchique des scènes de Singapour... 21

Figure 9 - Screen shots de la composition de blog sur un téléphone portable ... 22

Figure 10 - Exemple de blog du système TraveLog... 23

Figure 11 - Structure SR-tree... 25

Figure 12 - Détermination des régions par l'intersection des rectangles et des sphères ... 25

Figure 13 - Structuration des données par des SR-tree ... 35

Figure 14 - Interface du système ... 41

Figure 15 - Symboles des sinistres ... 42

Figure 16 - Symboles des monuments... 42

Figure 17 - Groupes des situations d’urgence dans la ville... 44

Figure 18 - Groupes des feux dans la ville ... 44

Figure 19 - Résultat des sinistres d'un groupe ... 45

Figure 20 - Résultat des monuments proches d'un feu ... 46

Figure 21 - Résultat des sinistres proches d'un bâtiment... 47

Figure 22 - Résultat des sinistres proches d'un sinistre ... 47

</div>
(7)<div class='page_container' data-page=7>

LISTE DES TABLEAUX

</div>
(8)<div class='page_container' data-page=8>

Chapitre 1 – Introduction

1.1. Problématique

Aujourd’hui, les catastrophes naturelles apparaissent avec une fréquence de plus en
plus élevée à cause du changement du climat global. Plusieurs projets de recherche sont
réalisés afin de développer les outils d’aide à la décision dans des situations de
post-catastrophe naturelle en zone urbaine et de fournir des informations précises en temps réel
au centre de gestion et aux équipes de secours. Les images collectées partout dans une
ville décrivant les sinistres différents sont une source d’information sur laquelle on peut
se baser pour donner des décisions de secours efficaces. A partir de quelques images,
l’opérateur humain peut facilement donner des décisions efficaces et exactes. Mais avec
un très grand nombre d’images (c’est le cas des situations urgences), il nous faut avoir un
système qui traite automatiquement ces images pour aider l’opérateur humain à donner
rapidement des décisions de secours.

Alors, le contexte de ce sujet de stage est le projet IDEA (Images of natural 
Disasters from robot Exploration in urban Area) [1] financé par le programme STC-Asie
(MAE/CNRS/INRIA) et avec comme partenaire le LORIA-QGAR (Nancy, France),
l’université de La Rochelle (France), l’IFI (Hanoi, Vietnam), le VAST-IOIT (Hanoi,
Vietnam) et l’université de Kuala Lumpur (Malaisie). Afin de résoudre le problème
abordé ci-dessus, dans ce projet, on utilise les techniques de vision par ordinateur, de
reconnaissance des formes et de recherche d’informations multimédias sur les images
collectées pour aider à donner des décisions de secours. Ce stage bénéficie aussi le travail
de thèse de NGUYEN Nhu Van, en co-direction entre l’université de La Rochelle, l’IFI et
le LORIA-QGAR.

</div>
(9)<div class='page_container' data-page=9>

pourront avoir une marge d’erreur sur la localisation précise. Mais en effet, il n’y a pas
encore une base d’images pour le projet IDEA, donc, une des tâches pour ce stage est de
construire au fur et à mesure une base d’images des types de sinistres différents pour
tester et trouver une faỗon pour simuler les informations de localisation géographique des
images. Pour les types de linformation gộographique diffộrents, il nous faut les traiter de
faỗons différentes. Par exemple, pour les images ayant une adresse civique, il nous faut

tout d’abord transformer cette adresse en information de type GPS (latitude et longitude)
pour savoir ou se trouve le sinistre sur le plan de la ville ; pour les images qui n’ont pas
les informations géographiques, on peut essayer de trouver s’il y a dans le contenu de
l’image les informations indiquant la position de l’image (le nom de la rue, un monument
célèbre, etc). Pour pouvoir traiter tous les cas différents, c’est un grand travail. Donc, dans
le cadre de ce stage, on suppose que toutes les images ont les informations de localisation
géographique de type GPS (latitude et longitude).

Ce stage a pour but de développer un modèle de recherche d’informations basé sur
une double information de contenu et de localisation géographique des images, de
retrouver les situations d’urgence dans une ville (feu, blessés, bâtiments endommagés,…)
et d’attribuer un niveau d’urgence pour chaque situation en fonction de la proximité
géographique d’événements similaires. En fait, on a deux espaces différents, l’un pour la
représentation du contenu de l’image et l’autre pour la localisation géographique. En
effet, il y a pas mal de travaux concernant la recherche d’images par le contenu, dont le
travail de thèse de NGUYEN Nhu Van. Alors, dans ce stage, on peut bénéficier de la
faỗon de dộcrire le contenu de l’image de son travail. Le problème ici est comment on
peut organiser les informations du contenu de l’image et les informations de localisation
géographique dans deux espaces pour pouvoir trouver les situations d’urgences et pour
leur attribuer un niveau d’urgence. A l’égard de l’attribution d’un niveau d’urgence ici, on
ne compte pas la nature de chaque sinistre représenté dans les images (par exemple, un
grand feu ou un petit feu) car c’est aussi un grand problème. On compte ici la proximité
géographique d’événements similaires, la proximité des sinistres avec des types de
monuments différents (hôpital, maison, grand bâtiment, etc.). L’aspect interactif du
système (retour de pertinence) n’est pas traité dans le cadre de ce stage, l’utilisateur
pourra seulement réaliser quelques actions simples avec le système comme demander à
trouver les sinistres qui sont similaires avec un sinistre dans une image quelconque,
trouver les sinistres qui sont proches d’un hôpital, etc.

1.2. Motivation

</div>
(10)<div class='page_container' data-page=10>

beaucoup de dégâts sérieux pour l’humain. Des coordinations efficaces des équipes de
secours peuvent diminuer considérablement les dégâts surtout les morts. C’est pour cette
raison qu’il est nécessaire d’avoir un bon système d’aide à la décision dans une situation
de post-catastrophe naturelle.

D’ailleurs, il y a actuellement plusieurs travaux sur la recherche d’images par le
contenu mais pas beaucoup de travaux sur la recherche d’image se basant en même temps
sur les informations du contenu de l’image et sur les informations de localisation
géographique. Les travaux existants sont appliqués surtout dans les applications de
tourisme, le cas de l’aide à la décision pour les secours comme dans le projet IDEA reste
une application nouvelle.

1.3. Objectifs

Les objectifs de ce travail de stage sont :

• Construire une base d’images de sinistres différents

• Simuler les informations géographiques pour ces images.

ã Dộterminer une faỗon pour organiser les informations des images dans deux

espaces de contenu visuel et de l’information géographique pour pouvoir
manipuler ensemble ces deux espaces afin de trouver les situations d’urgences et
d’attribuer un niveau durgence pour chaque image.

ã Proposer une faỗon pour dộterminer un niveau d’urgence pour chaque sinistre en se

basant sur la proximité des situations similaires et sur l’importance des monuments

autour de chaque sinistre.

Pour vérifier et valider le modèle, il faut donner des scénarios différents pour
IDEA qui identifient et décrivent des situations où on peut montrer un intérêt de
rechercher des images en combinant localisation et contenu image et faire des tests basés
sur ces scénarios.

1.4. Contribution

</div>
(11)<div class='page_container' data-page=11>

Dans le cadre de ce stage, on a implémenté avec succès la structuration par
partitionnement des données SR-Tree [2] pour organiser les descriptions du contenu
visuel des images et les descripteurs externes d’informations géographiques des images
pour faciliter et accélérer la recherche des images similaires dans l’espace du contenu et le
calcul de la proximité entre des situations dans l’espace de localisation géographique en
évitant des comparaisons exhaustives avec tous les éléments de la base. D’ailleurs, dans la
phase d’attribution d’un niveau d’urgence pour chaque image de sinistre, on considère
non seulement la proximité des situations similaires mais aussi les descriptions
symboliques des monuments à proximité des sinistres (hôpital, maison, bâtiment, école)
qui sont utilisées souvent dans les systèmes d’informations géographiques (SIG).

1.5. Environnement de stage

</div>
(12)<div class='page_container' data-page=12>

Chapitre 2 – Etat de l’art

Comme nous avons vu dans le chapitre 1, le but de ce stage est de développer un
modèle de recherche d’informations basé sur une double information de contenu visuel de
l’image et de localisation géographique pour retrouver des situations d’urgence dans une
ville (feux, blessés, bâtiments endommagés, etc.) et puis d’attribuer un niveau d’urgence
en fonction de la proximité géographique d’événements similaires. Alors, chaque image a
deux descripteurs différents, l’un représentant le contenu visuel de l’image (descripteur

interne) et l’autre représentant l’information de localisation géographique. A l’égard de la
représentation du contenu visuel de l’image, on bénéficie du travail de thèse de NGUYEN
Nhu Van qui représente le contenu visuel de chaque image par un vecteur de
caractéristiques. Et à l’égard de la localisation géographique, chaque image est
représentée par les coordonnées de latitude et de longitude. Il est question maintenant de
manipuler ces deux espaces pour soit retrouver des événements similaires visuellement,
soit trouver des événements qui sont proches géographiquement pour réaliser les objectifs
de ce stage. Pour que le système soit exploitable, le temps de réponse doit être acceptable.
Donc, il est nécessaire d’organiser des données dans les deux espaces pour pouvoir
réduire le temps de réponse en réduisant le nombre de calculs de distance à effectuer.
Dans ce stage, on s’intéresse sur les techniques d’indexation multidimensionnelle qui vont
être présentées dans la première partie de ce chapitre. Dans la deuxième partie, on va voir
comment on combine les informations du contenu de l’image et de localisation
géographique dans quelques applications actuelles.

2.1. Indexation multidimensionnelle

Les techniques principales d’indexations multidimensionnelles visent à regrouper
les descripteurs de base et à les englober dans des cellules faciles à manipuler (hiérarchie)
[3]. Cela nous permet d’éviter de considérer tous les descripteurs dans la base lors d’une
recherche en considérant seulement les groupes ou les paquets les plus pertinents et enfin,
on travaille seulement avec les descripteurs dans les paquets sélectionnés.

Il y a deux grandes catégories de techniques de création de cellules :
partitionnement des données et partitionnement de l’espace.

2.1.1 Partitionnement des données

</div>
(13)<div class='page_container' data-page=13>

a. B-tree : Balanced-tree (Bayer et McCreight, 1972) [3]

C’est un arbre balancé qui nous permet de structurer des données selon l’une des
dimensions. Un nœud qui n’est pas la racine d’un arbre B-tree d’ordre m contient entre
m/2 et m nœuds fils. Toutes les feuilles sont au même niveau et contiennent l’information.
Un nœud quelconque qui a k nœuds fils a k-1 éléments en ordre croissant qui sont les
valeurs de séparation divisant les valeurs de l’axe choisi des nœuds fils.

Figure 1 - B-tree

Pour la recherche, on part de la racine. Cette structure nous permet de vérifier s’il
existe ou non un élément dans la base, mais elle ne convient pas pour trouver les éléments
qui sont proches d’une entrée quelconque parce que chaque nœud interne contient
seulement les valeurs de séparation selon un seul axe.

b. La famille R-tree : Rectangle-tree [3][5][6][7]

</div>
(14)<div class='page_container' data-page=14>

Figure 2 - R-tree 
Un arbre R-tree a les propriétés suivantes [5] :

• Au niveau des feuilles, le rectangle englobant est le rectangle minimum recouvrant

les vecteurs de données appartenant à ce nœud. Chaque nœud feuille contient au

maximum M et au minimum m≤M/2 éléments de données.

• Tous les nœuds, sauf la racine, qui ne sont pas des feuilles ont entre m et M nœuds

fils ; le rectangle englobant de ces nœuds est le rectangle minimum qui englobe les
rectangles englobants des nœuds fils.

• Le nœud racine a au moins deux fils sauf quand il est une feuille. Le rectangle

englobant du nœud racine recouvre tous les vecteurs de données de la base.

• Toutes les feuilles sont au même niveau.

Un rectangle englobant est déterminé par deux points S(s1,s2,…,sn) et T(t1,t2,…,tn) ;
pour chaque élément X(x1,x2,…,xn) appartenant à ce rectangle, on a :

si≤ xi≤ ti avec ∀i ∈ [1,n]

Pour rechercher toutes les données appartenant à un rectangle Q quelconque, on
réalise la recherche à partir du nœud racine, en descendant aux nœuds fils qui ont le
rectangle englobant intersectant le rectangle et ainsi de suite jusqu’à ce qu’on rencontre
les nœuds feuilles. Au niveau des nœuds feuilles, on retourne toutes les données
appartenant au rectangle Q.

</div>
(15)<div class='page_container' data-page=15>

pour trouver la feuille où ajouter le nouvel élément. A chaque nœud, on choisit le nœud
fils avec le rectangle englobant le plus petit. Lorsqu’on trouve une feuille pour ajouter
l’élément, s’il est plein, on doit le diviser en deux feuilles différentes en minimisant la
surface totale des deux nouveaux rectangles englobants (division exhaustive, coût
quadratique ou linéaire [5]). Le rectangle englobant de chaque nœud est créé et mis à jour
au cours de l’insertion des éléments dans l’arbre pour qu’il soit le rectangle le plus petit
possible qui recouvre tous les éléments dans le sous-arbre de ce noeud.

La structure R-tree est dédiée à la recherche par intervalles, elle convient pour
l’indexation des données spatiales. Lors de la recherche, on peut gagner du temps car on
ne doit pas considérer tous les éléments dans la base, on considère seulement les nœuds
fils ayant le rectangle englobant qui intersecte l’intervalle entré. Mais la possibilité
d’intersection entre les rectangles augmente quand le nombre de dimensions est grand.
Dans ce cas, le parcours séquentiel peut être plus efficace.

Les structures R+-tree [6] et R*-tree [7] sont données pour optimiser la recherche
en minimisant le chevauchement des rectangles englobants. La structure R+-tree évite le
recouvrement entres les rectangles en divisant chaque rectangle qui recouvre un autre
rectangle en plus petits rectangles jusqu’à ce qu’il n’y a plus de recouvrement. Cela peut
faire augmenter la hauteur de l’arbre mais on peut gagner du temps en réduisant le
nombre de sous-arbres à visiter. La structure R*-tree minimise le recouvrement entre les
rectangles et minimise aussi le volume des rectangles en appliquant, quand on veut
ajouter un nouveau fils à un nœud plein, le mécanisme de réinsérer quelques nœuds fils
du nœud plein avant de le diviser en deux avec l’espoir de trouver des meilleurs positions
pour les nœuds à réinsérer. R*-tree est la structure ayant le plus de succès dans la famille
R-tree [7][2]. Les expérimentations [7] montrent qu’un SR-tree peut être utilisé
efficacement pour l’organisation des données multidimensionnelles et des données
spatiales.

c. SS-tree : Similarity Search Tree (1996) [3][8]

Le SS-tree [8] est une structure d’indexation de similarité qui regroupe les vecteurs
de caractéristiques suivant la similarité entre eux. La mesure de similarité utilisée ici est la
distance euclidienne dans le cas où les poids de toutes les dimensions dans le vecteur de
caractéristiques sont pareils.

</div>
(16)<div class='page_container' data-page=16>

d’un nœud est le centre de gravité de tous les éléments dans le sous-arbre de ce nœud. Au
niveau des feuilles, la sphère englobante recouvre les éléments appartenant à cette feuille,
le rayon de la sphère englobante est égal à la distance entre le centre et le point le plus
loin. Et au niveau d’un nœud interne, la sphère englobante recouvre les sphères
englobantes de tous les nœuds fils de ce nœud, le rayon de la sphère est toujours supérieur
ou égal à la distance entre le centre et le point le plus loin parmi les points dans le
sous-arbre de ce nœud.

Figure 3 - SS-tree

On utilise aussi le mécanisme de réinsertion d’une partie d’un nœud plein comme
dans le cas du R*-tree afin de minimiser le recouvrement entre les sphères englobantes et
le volume des sphères. Les expérimentations [8] montre que le SS-tree est meilleur que le
R*-tree pour les applications de recherche de similarité avec des données de haute
dimensionalité.

d. SR-tree : Sphere/Rectangle Tree (1997) [3][2]

L’idée du SR-tree (Sphere/Rectangle Tree) est de combiner les deux structures
R*-tree et SS-R*-tree en identifiant la région de chaque nœud par l’intersection du rectangle
englobant et de la sphère englobante. Pour chaque nœud dans l’arbre SR-tree, on
détermine :

• Un rectangle englobant recouvre tous les éléments (vecteurs) dans le sous-arbre de

ce nœud. Ce rectangle est déterminé comme dans le cas du R-tree.

• Une sphère englobante recouvre tous les éléments dans le sous-arbre de ce nœud.

Cette sphère est déterminée comme dans le cas du SS-tree.

</div>
(17)<div class='page_container' data-page=17>

Figure 4 - SR-tree

En combinant le rectangle englobant et la sphère englobante (ou plus précisément
l’hypercube et l’hypersphère dans le contexte de données de grande dimension), on garde
l’avantage du comportement en grande dimension du SS-tree et on peut diminuer le
recouvrement entre les nœuds par rapport aux cas du R*-tree et du SS-tree en créant des
régions de petits volumes et de petits diamètres [2]. Cela accrt la performance des
requêtes des plus proches voisins pour les données de haute dimensionalité [2]. Cela

implique aussi que cette structure est utile pour les applications d’indexation de similarité
des images/vidéos.

e. X-tree (1996) [4]

Le X-tree est une variance de la structure R*-tree. Elle améliore la performance du
R*-tree en utilisant l’algorithme de partitionnement minimisant le recouvrement et le
mécanisme des super-noeuds qui ont plus de nœuds que les nœuds normaux [4][2]. Les
super-noeuds sont utilisés si le recouvrement généré quand on ajoute un nouveau fils dans
un nœud plein est plus petit que celui lorsqu’on divise ce nœud en deux nouveaux nœuds.
Les expérimentations [4][2] montrent que la performance du X-tree pour les requêtes par
point (point query) est beaucoup meilleure que celle du R*-tree.

2.1.2 Partitionnement de l’espace

</div>
(18)<div class='page_container' data-page=18>

a. KD-tree (Bentley, 1979) [3]

Le KD-tree (k-dimensional tree) organise les données dans un espace à k

dimensions. On structure les données sous la forme d’un arbre binaire. A chaque niveau,
on partitionne l’espace en deux sous-espaces successivement selon chaque dimension.

Figure 5 - Kd-tree 
Un arbre KD-tree a des propriétés suivantes :

ã La racine est la boợte englobante de tout l’espace

• Un nœud correspond à un plan séparateur et deux pointeurs pointant vers deux
sous-espaces construits par le plan.

• Une feuille correspond à la liste des objets de la base appartenant à l’espace de ce

nœud.

On peut couper l’espace en deux au milieu par le plan médian, couper à la position
de l’objet médian ou au hasard. Cette structure permet la recherche par intervalles ou par
plus proches voisins. Elle permet d’accélérer le traitement des données
multidimensionnelles. L’avantage de cette structure pour la recherche dépend de la
concentration des données dans l’espace.

b. KDB-tree [9]

</div>
(19)<div class='page_container' data-page=19>

selon cet axe, cela pouvant créer des nœuds vides ou presque vides. Cela implique une
diminution de la performance du KDB-tree dans le cas des requêtes par intervalles ou les
requêtes par plus proches voisins.

c. LSD-tree : Local Split Decision tree [10]

Le LSD-tree (Local Split Decision tree) [10] est une structure de données qui
supporte efficacement l’accès vers les objets géométriques. Comme d’autres structures, le
LSD-tree partitionne l’espace de données récursivement en deux sous-espaces séparés à
une position arbitraire. La position pour diviser est choisit pour atteindre l’optimal local,
c'est-à-dire le choix de la position pour la division dépend seulement du bloc de l’espace
qu’on divise, et non pas des bornes des autres blocs. C’est pour cette raison que l’on
appelle cette structure Local Split Decision tree.

La structure du LSD-tree ressemble à celle du KD-tree. Chaque nœud de l’arbre
enregistre la dimension et la position pour la division.

Figure 6 - LSD-tree

2.2. Travaux similaires

2.2.1 SnapToTell [11][12][13][14]

</div>
(20)<div class='page_container' data-page=20>

(un lac, un monument, un sculpture, etc.) et que vous voulez avoir les informations
concernant ce site. Vous pouvez prendre une photo de ce site utilisant votre téléphone
portable et l’envoyer à un fournisseur de service de SnapToTell. Le fournisseur de service
va vous envoyer ensuite les informations décrivant ce site sous la forme un message
multimédia (MMS) et/ou un message texte.

L’idée de ce système est d’utiliser l’information de localisation géographique du
téléphone portable de l’utilisateur pour déterminer le contexte de l’utilisateur. Mais la
position seule de l’utilisateur ne nous permet pas de déterminer son intention car le
monument qui l’intéresse peut être éloigné de plusieurs centaines de mètres. Alors, après
avoir eu l’information du contexte de l’utilisateur, le système va rechercher dans la base
de données les images les plus proches visuellement de l’image requête pour trouver le
site qui intéresse l’utilisateur. Notez qu’on fait la recherche seulement parmi les images
autour du positionnement de l’utilisateur. La base de données de ce système collecte les
images de tous les sites célèbres d’un pays (ici, Singapour), chaque site correspondant à
plusieurs images prises à plusieurs distances différentes, de plusieurs points de vue
différents.

Figure 7 - Architecture client/serveur du système SnapToTell

</div>
(21)<div class='page_container' data-page=21>

positionnement de l’utilisateur, le serveur recherche dans la base de données l’image la
plus proche visuellement parmi les images autour de la localisation de l’appareil mobile.

A l’égard de la base de données, on construit une base d’images de scènes
différentes de Singapour. Chaque image contient l’information GPS de la scène,

l’information de localisation géographique ici étant localisée hiérarchiquement à trois
niveaux : Singapour est divisé en plusieurs zones, chaque zone contenant plusieurs lieux
et chaque lieu correspondant à quelques scènes. Chaque scène est caractérisée par des
photos prises à plusieurs distances, plusieurs points de vue et plusieurs conditions de
luminosité, elle correspond aussi à une description textuelle et/ou une description audio
qui sont les informations à retourner pour l’utilisateur lors de chaque requête.

Figure 8 - Localisation hiérarchique des scènes de Singapour

</div>
(22)<div class='page_container' data-page=22>

2.2.2 MobiLog [15]

MobiLog (Mobile Blogging automation) [15] est une plateforme qui est proposée

pour automatiser partiellement la saisie de données des blogs écrits à partir d’un
téléphone mobile et le système TraveLog [15] est une application de cette plateforme.
Notez que ce système utilise les résultats du système Snap2Tell abordé dans la partie
précédente.

L’idée de ce système est qu’un utilisateur prend des images d’une scène
intéressante en voyageant et il veut écrire un blog en utilisant son téléphone mobile pour
partager son voyage. Le système va l’aider à ajouter automatiquement les informations
concernant le contexte (l’heure, la location, le climat), les informations personnelles
d’utilisateur (le nom, la date de naissance) et les informations du contenu des images
(description de la scène).

</div>
(23)<div class='page_container' data-page=23>

On peut trouver les informations du contexte en se basant sur le temps de la
création des images, sur la position du téléphone mobile (GPS) et sur l’information du
climat obtenue à partir des serveurs correspondants. Les informations personnelles de
l’utilisateur sont obtenues à partir de son profil. Pour avoir la description de la scène, le
serveur TraveLog envoie les images ajoutées dans le blog par l’utilisateur vers le serveur

Snap2Tell [2.2.1]. A partir des mots-clés dans la description reỗue du serveur Snap2Tell,
le systốme peut chercher les sites web concernés en utilisant les moteurs de recherche
Web et les lister dans le blog. Un autre but de ce système est d’améliorer la qualité des
images dans le blog en utilisant la technique d’égalisation d’histogramme ou en
remplaỗant les images de mauvaise rộsolution par des images de bonne résolution d’une
même scène (différents points de vue, différentes conditions de lumière) trouvées par le
service de Snap2Tell. La figure suivante donne un exemple de blog proposé par le
système TraveLog :

</div>
(24)<div class='page_container' data-page=24>

Chapitre 3 – SR-tree

Comme nous avons expliqué dans le chapitre précédent, la structure de données
SR-tree [2] accrt la performance des reqtes par plus proches voisins pour les données
de haute dimensionalité qui est le cas des données du contenu visuel des images dans
notre projet. D’une part, elle est utile pour les applications d’indexation de similarité des
images/vidéos ; d’autre part, son mécanisme de regroupement des données qui sont
proches par des rectangles englobants et des sphères englobantes correspond bien à la
structuration des données géographiques. C’est pour cette raison que nous proposons la
structuration SR-tree [2] pour structurer en même temps les données géographiques des
images et les données du contenu visuel des images en vue de faciliter et accélérer la
recherche des images similaires dans l’espace du contenu et le calcul de la proximité entre
des événements dans l’espace de localisation géographique. Dans ce chapitre, je vais
présenter la structure SR-tree plus en détails ainsi que les opérations sur le SR-tree
comme la création d’un SR-tree, la recherche des k plus proches voisins utilisant cette
structure, etc.

3.1. Présentation du SR-tree

La structure SR-tree est basée en même temps sur la structure de la famille R-tree
[5][6][7] et celle de tree [8]. Elle regroupe des avantages de la famille R-tree et de

SS-tree en déterminant une région d’un nœud par l’intersection du rectangle englobant
minimal et de la sphère englobante minimale des données dans le sous-arbre de ce nœud.
Pourquoi combiner les hypercubes et les hypersphères ? Dans la stratégie de création du
R-tree, on essaie de minimiser le volume des hyper-rectangles. Mais dans certain cas, un
hypercube peut avoir une plus grande diagonale que celle d’un hypercube ayant un plus
petit volume. Les rectangles de grande diagonale peuvent provoquer plus de
recouvrement entre des nœuds. En créant le SS-tree, on essaie de minimiser le diamètre
des hypersphères tandis que les hypersphères occupent un grand volume pour un petit
diamètre dans le cas de grande dimensionalité. L’intersection du rectangle englobant et de
la sphère englobante permet d’obtenir une région plus petite que celles du R-tree et du
SS-tree. D’ailleurs, dans la stratégie pour minimiser le diamètre, l’intersection donne des
régions de petits volumes pour un petit diamètre, et donc, permet de réduire la
superposition des régions.

Un arbre SR-tree a les propriétés suivantes :

• Les données sont au niveau des feuilles. C'est-à-dire que le rectangle englobant et

</div>
(25)<div class='page_container' data-page=25>

la sphère minimale recouvrant les vecteurs de données appartenant à ce nœud.

Chaque nœud feuille contient au maximum ML et au minimum mL≤ML/2 éléments

de données.

• Tous les nœuds qui ne sont pas les feuilles sauf la racine ont entre mN et MN nœuds
fils ; le rectangle englobant et la sphère englobante de ces nœuds recouvrent
respectivement les rectangles englobants et les sphères englobantes des nœuds fils.

• Le nœud racine a au moins deux fils sauf quand il est une feuille. Le rectangle
englobant et la sphère englobante du nœud racine recouvre tous les vecteurs de

données de la base.

• Toutes les feuilles sont au même niveau.

Figure 11 - Structure SR-tree

Figure 12 - Détermination des régions par l'intersection des rectangles et des sphères 
La structure d’un nœud du SR-tree est comme suit :

struct SRElement {

</div>
(26)<div class='page_container' data-page=26>

Int num_children ;
Int num_point ;
Int height ;

Float radius ;
Float centroid[D] ;
Float s[D] ;

Float t[D] ;
DATA data_ptr ;
}

Avec :

• child_array_ptr est la liste des pointeurs pointant vers les nœuds fils de ce nœud.

• num_children est le nombre des nœuds fils de ce nœud. mN ≤ num_children ≤ MN
avec mN et MN sont les nombres minimal et maximal des nœuds fils de chaque
nœud.

• num_point est le nombre total des éléments (vecteurs) dans le sous-arbre de ce
nœud.

• height est la hauteur de ce nœud.

• D est la dimension des données dans l’arbre.

• La sphère englobante S de ce nœud est déterminée par un rayon radius et un centre

centroid qui est le centre de gravité des vecteurs dans le sous-arbre de ce nœud.

• Le rectangle englobant R de ce nœud est déterminé par deux points s et t. Pour
chaque élément e dans le sous-arbre de ce nœud, on a si≤ei≤ti avec ∀i : 1≤ i ≤D.

• Chaque nœud feuille correspondant à un élément (vecteur) de la base. Si c’est un

nœud feuille, data_ptr est le pointeur qui point vers les données de type DATA
correspondant à cette feuille. Par exemple, dans le cas des images, DATA est un
type de données déterminant les informations correspondant à une image comme le
nom de l’image, les données de localisation géographique, les données du contenu
visuel, le type du sinistre, etc.

La création d’un arbre SR-tree est réalisé en insérant au fur et à mesure les données
dans le SR-tree.

3.2. Insertion dans le SR-tree

</div>
(27)<div class='page_container' data-page=27>

L’algorithme pour insérer un nœud N quelconque de la liste dans SR-tree est comme
suivant :

• S’il existe seulement un nœud racine du SR-tree (structure vide), on créera une
entrée du nœud racine, ajoutera N dans cette entrée et mettra jour le nud racine
de faỗon appropriộe.

ã Sinon, on descend jusqu’à ce qu’on trouve un nouveau père pour le nœud N. Le
sous-arbre à choisir en descendant est celui qui a le centre est plus proche du nœud
N à insérer. Pour chaque nœud traversé en descendant, on doit mettre à jour le
nombre de points w ainsi que le rectangle R et la sphère S de ce nœud. Chaque fois
qu’on trouve le nœud père du N :

• si le père n’est pas plein, on ajoute le nœud N comme un de ses fils

• si le père est plein, on réinsère une part de ses fils (par exemple 30%) dans

le cas que le père n’est pas encore réinséré ; dans le cas inverse, on divise
(spit) ses fils en deux parties pour avoir deux nouveaux pères. Pour diviser,
on choisit la dimension avec la variance sur cette dimension qui est la plus
grande et puis on choisit la position à diviser pour minimiser la somme des
variances de chaque côté de la division. Alors, on a deux nouveaux pères, le
père qui est plus proche du grand-père est gardé, et l’autre père doit être
réinséré.

Le rectangle englobant et la sphère englobante d’un nœud sont créés et mis à jour
au cour de la phase d’insertion des entrées dans larbre SR-tree. La faỗon de mettre jour
les rộgions qui sont à l’intersection du rectangle englobant et de la sphère englobante est
comme suit :

• Notez qu’un rectangle englobant est déterminé par deux points S et T pour que
toutes les coordonnées de S soient inférieures ou égales à toutes les coordonnées

correspondantes d’un point quelconque dans la région et inversement, toutes les
coordonnées de T soient supérieures ou égales à toutes les coordonnées
correspondantes d’un point quelconque dans la région. Donc, pour mettre à jour le
rectangle englobant d’un nœud, il faut simplement mettre à jour les coordonnées de
S et T pour que le nouveau rectangle recouvre les rectangles des nœuds
fils (supposons qu’on a n nœud fils) :

(

)

(

)

</div>
(28)<div class='page_container' data-page=28>

k est l’indice du fils Ck et i est l’indice de la dimension. Ck.si et Ck.ti sont
respectivement la ième coordonnée des points S et T du rectangle englobant du
nœud fils Ck.

• Pour mettre à jour la sphère englobante :

o Le centre de la sphère englobante x(x1, x2, …, xD) est calculé comme suit :

(

i

D

)

w

C

w

C

x

C

x

n
k
k
n
k

k
i
k

i

=

≤

∑

=
=

1 .

*

.

1
1

k est l’indice du fils Ck et i est l’indice de la dimension. Ck.xi est la ième
coordonnée du centre du fils Ck ; Ck.w est le nombre de points dans le
sous-arbre du fils Ck.

o Le rayon de la sphère englobante, r, est calculé comme suit :

(

)

(

)

(

)

(

MAXDIST

x

C

R

)

d

r

C

x

C

x

d

r

k
n
k
r
k
k
n
k
s
r
s

.

,

max

.

max

,

min

1
1
≤
≤
≤
≤

=

+

−

=

Ck.x et Ck.r sont respectivement le centre et le rayon de la sphère englobante du
fils Ck ; Ck.R est le rectangle englobant du fils Ck. La fonction
MAXDIST(p,R) qui calcule la distance maximale entre un point p et un
rectangle R est comme suit :

MAXDIST

(

p

R

)

(

p

q

)

R
q

−

=

∈

max

,

On peut calculer MAXDIST(p,R) comme suit :

(

)











+

>

+

≤

=

−

=

∑

2 ,

1
2
i
i
i
i
i
i
i
i

i
n
i
i
i

t

s

p

si

s

t

s

p

si

t

r

avec

r

p

R

p

MAXDIST

</div>
(29)<div class='page_container' data-page=29>

centre du nœud père et les rectangles englobants de ses fils. Le SS-tree
détermine le rayon r par ds tandis que le SR-tree détermine le rayon r en
choisissant le minimum entre ds et dr. Alors, le rayon du SR-tree peut être plus
petit que celui du SS-tree.

3.3. Suppression dans le SR-tree

La suppression dans le SR-tree est comme celle dans le R-tree [5]. Pour supprimer
un élément E d’un SR-tree, on suit les étapes suivantes :

• A partir du nœud racine, on descend pour trouver le noeud feuille L contenant
l’élément E. En descendant, on vérifie tous les nœuds fils pour que leur région
déterminée par le rectangle englobant et la sphère englobante contienne E.

• Si on trouve le record E dans un feuil L de l’arbre, on supprimera E de ce feuil.

• Après avoir supprimé E, si L contient moins de mL éléments (mL est le nombre
minimal possible d’éléments d’un nœud feuille), on va supprimer L et réinsérera
tous les éléments de L ; sinon on va mettre à jour les régions de tous les nœuds à
partir de L jusqu’au nœud racine.

3.4. Recherche dans le SR-tree

Il y a quelques types de requête qui peuvent être exercés avec la structuration
SR-tree tels que la recherche d’un vecteur dans l’arbre SR-SR-tree, la recherche des k plus
proches voisins d’un point, la recherche de vecteurs de données qui sont dans un rayon de
proximité d’un point quelconque.

La recherche d’un vecteur dans l’arbre SR-tree commence à partir de la racine et
descend à chaque niveau vers les nœuds qui ont une région contenant ce vecteur. La
recherche termine quand on a trouvé le vecteur dans une feuille de l’arbre ou quand il n’y
a plus de nœud à vérifier.

La recherche des k plus proches voisins d’un point quelconque est comme dans
[16]. Il y a les étapes suivantes :

• Tout d’abord, on sélectionne k points quelconques comme k plus proches voisins

initiaux.

• On utilise la distance entre le point entré et le point le plus loin dans k points pour
diriger la recherche vers les nœuds fils qui ont les régions superposées avec
l’intervalle des k points.

</div>
(30)<div class='page_container' data-page=30>

(

)

(

)

(

p

C

R

)

MINDIST

d

r

C

x

C

p

d

k
r
k
k
s
r

s

.

,

.

,

0 max

,

max

=

−

=

Ck.x et Ck.r est le centre et le rayon de la sphère englobante de Ck, Ck.R est le rectangle
englobant du fils Ck. MINDIST(p,R) est la distance minimale entre le point p et le
rectangle R :

(

p

R

)

(

p

q

)

MINDIST

R
q

−

=

∈

min

,

On peut calculer cette distance comme dans [16] :

(

)











>

<

=

−

=

∑

non

si

p

t

p

si

t

s

p

si

s

r

avec

r

p

R

p

MINDIST

i
i
i
i
i
i
i
i
n
i
i
i
1
2

,

La distance MINDIST(p,R) calculée par la formule précédente donne une distance qui est
toujours inférieure ou égale à toutes les distances entre le point P et les points dans le
rectangle R.

Pour chaque fils Ck qui a la distance minimale d entre le point entré et la région de
ce fils qui est supérieur à la distance entre le point p et le point le plus loin parmi les k
points les plus proches, on ne doit pas rechercher plus dans ces fils. Pour les autres fils, on
visite ces fils en utilisant la recherche en profondeur et par ordre de croissant de la
distance minimale d.

</div>
(31)<div class='page_container' data-page=31>

Chapitre 4 – Système de recherche d’informations

basé sur une double information de contenu des

images et de localisation géographique

Comme nous avons abordé, ce travail de stage a pour but de construire un modèle
de recherche d’informations basé sur une double information de contenu des images et de
localisation géographique afin de retrouver des situations urgences dans une ville et de
leur attribuer un niveau d’urgence en fonction de la proximité géographique d’événements
similaires. Ce chapitre va présenter notre approche pour développer un tel système.

4.1. Hypothèses

La recherche d’informations dans ce stage est basée d’une part sur l’information du
contenu visuel des images et d’autre part sur l’information de localisation géographique.
Alors, chaque image est représentée par un descripteur interne du contenu de l’image et
un descripteur externe de localisation géographique. A l’égard du descripteur interne, on
représente le contenu visuel de l’image sous forme d’un vecteur de n dimensions. A
l’égard du descripteur externe, on suppose que toutes les images ont les informations de
localisation géographique de type GPS, c'est-à-dire que chaque image est représentée par
les coordonnées de longitude et de latitude qu’on prend pour cette image. L’information
de localisation géographique des images est simulée par le programme.

Une autre hypothèse est que l’entrée du système est un ensemble d’images qui
arrivent à un moment t. C'est-à-dire qu’on retrouve des situations d’urgence et qu’on leur
attribue un niveau d’urgence en utilisant les images qui sont actuellement valides.

D’ailleurs, l’identification des situations d’urgence concerne la recherche d’images
par le contenu qui est le travail de thèse de NGUYEN Nhu Van dont nous allons
bénéficier. Donc, on ne se concentre pas sur la recherche d’un bon descripteur interne
pour la représentation du contenu visuel de l’image, on utilise les descripteurs internes de

son système (ici, soit l’histobin de couleur, soit un sac de mots visuels). Dans le cadre de
ce stage, on se concentre sur le problème de structurer les images en deux espaces
(contenu visuel et localisation géographique) et de manipuler ces deux espaces pour
retrouver des situations d’urgence et leur attribuer un niveau d’urgence.

</div>
(32)<div class='page_container' data-page=32>

nombre de sinistres différents qui sont proches, le nombre de sinistres de même type qui
sont proches, la nature des monuments (hôpital, maison, école, etc.) à la position du
sinistre ou proches du sinistre, etc. Pour pouvoir considérer tous les aspects qui peuvent
influencer sur l’attribution d’un niveau d’urgence, il nous faut l’aide des experts du
domaine des secours dans des situations de post-catastrophes naturelles (par exemple des
pompiers). D’ailleurs, pour déterminer le niveau d’urgence en se basant sur le contenu de
l’image (par exemple, c’est un grand feu ou un petit feu), c’est aussi un grand travail à
faire. Donc, dans le cadre de ce stage, on suppose que le niveau d’urgence d’une situation
est basé seulement sur la proximité géographique d’événements similaires et sur la nature
des monuments à la position du sinistre ou proches du sinistre.

Pour le système qu’on va construire, on suppose qu’il y a cinq types de sinistres
différents (feu, blessé, bâtiment endommagé, route endommagée et inondation) et que les
niveaux d’urgence de ces cinq types sont pareils. D’ailleurs, dans les Système
d’Informations Géographiques (SIG) actuels, les données d’une ville peuvent se
composer de plusieurs couches, chaque couche étant un fichier shapefile [17] qui contient
un type d’information quelconque comme les maisons, les routes, les lacs, etc. On
suppose aussi qu’il y a un fichier shapefile contenant des objets de type polygone
identifiant des monuments différents dans la ville, chaque monument appartient à un des
quatre types différents (maison, hôpital, grand bâtiment et école).

En effet, plusieurs personnes peuvent prendre des photos d’un même sinistre (par
exemple un feu) et envoyer vers le serveur. Pour simplifier, on suppose qu’une situation
d’urgence est représentée par une seule image reỗue. C'est--dire que deux images
différentes doivent représenter deux sinistres différents.

4.2. Approche proposée

4.2.1 Structuration des données

</div>
(33)<div class='page_container' data-page=33>

sinistre parmi ses k plus proches images. Par exemple, parmi k=30 plus proches images,
si on a 10 images de feux, 5 images de blessés, 6 images de bâtiments endommagés, 4
images des routes endommagées et 5 images d’inondations, alors on dit que l’image
entrée est de type « feu ». Un autre exemple, parmi 30 plus proches images, on a 15
images de feux, 15 images de bâtiments endommagés, alors on dit que l’image d’entrée
est de type « feu » si la première image de feu appart avant la première image de
bâtiment endommagé dans la liste des k plus proches images et vice versa.

Alors, dans notre système, on doit distinguer deux bases d’images :

• Une base d’images d’apprentissage contenant les images qui sont déjà annotées
selon cinq types de sinistres différents.

• Une base d’images actuelles contenant les images que le système reỗoit un
moment t. On doit identifier le type du sinistre correspondant à chaque image dans
cette base et puis lui attribuer un niveau d’urgence.

Il nous faut maintenant structurer les images en deux espaces (l’espace des
descripteurs internes du contenu visuel et l’espace des descripteurs externe de localisation
géographique). La structure SR-tree [2] est choisie pour les deux espaces car elle accrt
la performance des requêtes par plus proches voisins pour les données de haute
dimensionalité (descripteurs internes des images) et elle correspond bien à la structuration
des données géographiques. Cette structure permet de faciliter et accélérer la recherche
des images similaires dans l’espace du contenu et le calcul de la proximité entre des
événements dans l’espace de localisation géographique. On va structurer les données du

système comme suit :

• On caractérise chaque image dans la base d’apprentissage par un vecteur de

caractéristiques (soit l’histobin de couleurs, soit un sac de mots visuels). Puis on
structure tous les descripteurs du contenu visuel des images dans la base
d’apprentissage par un arbre SR-tree en ajoutant au fur et à mesure ces descripteurs
dans l’arbre.

• Pour les images qui arrivent au système à un moment t, on va structurer en deux
espaces par des SR-tree différents :

o Dans l’espace de localisation géographique, chaque image est caractérisée
par un descripteur externe sous forme un point (x,y) représentant la
longitude et la latitude de la position qu’on prend pour cette image. On
utilise un arbre SR-tree pour structurer les descripteurs externes des images.

o Dans l’espace du contenu visuel, chaque image est représentée par un

</div>
(34)<div class='page_container' data-page=34>

cas des images dans la base d’apprentissage. On va structurer les images
dans cet espace par des SR-tree différents, chaque SR-tree correspondant à
un type du sinistre. C'est-à-dire qu’on a cinq SR-tree différents
correspondant à cinq types de sinistres différents (SR-tree du feu, SR-tree
des blessés, SR-tree des bâtiments endommagés, SR-tree des routes
endommagées et SR-tree des inondations). Un SR-tree peut être vide s’il
n’y a aucune image appartenant au type du sinistre correspondant à cet
arbre.

o Alors, pour chaque image reỗue, on doit :

Crộer un élément (ou enregistrement) pour caractériser les données
de cette image (nom de l’image, descripteur externe de localisation
géographique, descripteur interne du contenu visuel, type du sinistre
(non connu), niveau d’urgence (non connu), etc.)

En se basant sur le descripteur externe, on ajoute cette image dans
l’arbre SR-tree de l’espace spatial, la feuille contenant l’information
de localisation géographique de cette image pointant vers son
élément de données.

Utiliser l’algorithme de recherche des k plus proches voisins dans
l’arbre SR-tree de la base des images d’apprentissage pour trouver k
images dans la base d’apprentissage qui sont plus proches
visuellement avec l’image entrée. A partir des k images obtenues, on
détermine le type de situation d’urgence (feu, blessé, bâtiment
endommagé, route endommagée ou inondation) de l’image entrée et
on met à jour l’information de type du sinistre dans l’élément de
cette image. Et en basant sur le descripteur interne, on ajoute cette
image dans l’arbre SR-tree correspondant à son type du sinistre. La
feuille contenant ce descripteur interne pointe vers l’élément de
données de cette image.

</div>
(35)<div class='page_container' data-page=35>

école ou grand bâtiment), le rectangle englobant et la sphère englobante de cette
feuille recouvrant le polygone identifiant le monument.

Alors, on a dans notre système :

• Un SR-tree structurant l’information du contenu visuel des images dans la base
d’apprentissage.

• Un SR-tree des informations de localisation géographique des images reỗues un

moment t.

ã Des SR-tree des informations du contenu visuel des images reỗues un moment t,

dont un SR-tree pour chaque type du sinistre.

• Un SR-tree structurant l’information des monuments dans la ville.

</div>
(36)<div class='page_container' data-page=36>

4.2.2 Manipulation dans les SR-tree

Comme nous l’avons expliqué, l’identification des situation d’urgence est réalisé
en appliquant la recherche des k plus proches images visuellement dans le SR-tree des
images dans la base d’apprentissage. Le problème maintenant est d’attribuer un niveau
d’urgence pour ces situations. Dans le cadre de ce stage, on suppose que le niveau
d’urgence est attribué en fonction de la proximité entre des événements similaires
(événements de même type) et suivant le type des monuments autour des situations
d’urgence.

On définit deux paramètres r1 et r2 :

• r1 est le rayon de proximité entre des situations dans l’espace de localisation
géographique. Deux situations urgences caractérisées par deux images à deux
positions P(x,y) et P’(x’,y’) sont proches si la distance (distance euclidienne) entre
ces deux positions est inférieure ou égale à r1.

• r2 est le rayon de proximité entre une situation et un monument. On dit qu’un
monument (par exemple un hôpital) et une situation situé à la position P(x,y) sont
proches si la sphère du centre P(x,y) et de rayon r2 intersecte la région déterminant

le monument (dans l’arbre SR-tree des monuments, la région d’un monument est
l’intersection entre le rectangle englobant et la sphère englobante du polygone
caractérisant le monument).

Lors d’une catastrophe naturelle, il peut y avoir plusieurs images qui sont envoyées
vers le serveur, il est utile de grouper les situations similaires en groupe en fonction de
leur proximité dans l’espace géographique et d’afficher sur l’écran des groupes de
situations d’urgence.

On va déterminer un groupe de proximité des situations similaires comme suit :

• A l’égard du contenu visuel, toutes les situations dans un groupe doivent être de
même type du sinistre.

• A l’égard de la localisation géographique, on regroupe des images représentant des

situations de même type comme suit : si A et B sont proches dans le rayon r1, B et

C sont proches dans le rayon r1 ; alors, A, B et C appartiennent à un même groupe

de proximité.

</div>
(37)<div class='page_container' data-page=37>

• Au niveau du sinistre, pour chaque image représentant un sinistre quelconque, on
attribue un niveau d’urgence correspondant au type du sinistre de cette image. Pour
savoir quel est le niveau d’urgence approprié à chaque type du sinistre, il nous faut
consulter des experts dans le domaine du secours. Dans le cadre de ce stage, on
attribut un niveau d’urgence 1 pour tous les types de sinistres.

• Après avoir déterminé le type du sinistre correspondant à une image, on réalise la

recherche dans l’arbre SR-tree de l’information des monuments pour trouver le
monument où le sinistre a lieu et trouver les monuments qui sont proches dans un
rayon r2 par rapport de la position du sinistre. Le sinistre a lieu à un monument A si
et seulement si la position de l’image caractérisant le sinistre se situe dans la région
du monument A déterminée par l’intersection du rectangle englobant et de la
sphère englobante du polygone déterminant le monument A. Un monument B est
proche du sinistre situé à la position (x,y) si et seulement si la région du monument
B intersecte la sphère de centre (x,y) et de rayon r2. Pour rechercher ces
monuments, on commence à partir de la racine de l’arbre SR-tree de l’information
des monuments dans la ville et on descend vers les nœuds fils ayant la région
intersectant la sphère de rayon r2 et centrée à la position de l’image. Selon le type
de monuments situé à la position du sinistre ou proches du sinistre, on va mettre à
jour le niveau d’urgence de l’image comme suit :

o Pour chaque type de monument, on attribue un paramètre α déterminant le

nombre à ajouter dans le niveau d’urgence de l’image quand le sinistre a
lieu à la position du monument correspondant. Par exemple, si le sinistre a
lieu dans une maison, on va ajouter dans le niveau d’urgence du sinistre un

nombre α correspondant à une maison (par exemple 1).

o Pour chaque type de monument, on attribue aussi un paramètre β

déterminant le nombre à ajouter dans le niveau d’urgence de l’image quand
le sinistre a lieu à une position proche du monument correspondant. Par
exemple, si la position du sinistre est proche d’une maison et d’un hôpital,
on va ajouter successivement dans le niveau d’urgence du sinistre un
nombre β correspondant à une maison et un nombre β correspondant à un
hôpital.

</div>
(38)<div class='page_container' data-page=38>

Type du monument αααα ββββ

Maison 1 0.25

Hôpital 9 1.25

Grand bâtiment 7 1

Ecole 7 1

Table 1 - Niveaux d'urgence correspondant à chaque type de monument

• Maintenant, on va regrouper les images similaires qui sont proches

géographiquement dans un rayon r1 dans des groupes de proximité que nous avons
déjà déterminés ci-dessus. Puis, un niveau d’urgence va être attribué à chaque
groupe de proximité ; le niveau d’urgence d’un groupe est la somme totale des
niveaux d’urgence de tous les sinistres dans le groupe. Pour les images quon
reỗoit un moment t, on va les ajouter au fur et à mesure en même temps dans
l’arbre SR-tree géographique et dans un des arbres SR-tree du contenu visuel
correspondant au type de sinistre des images. On va aussi regrouper les images qui
sont proches géographiquement au cour de l’insertion des images comme suit :

o Chaque image se voit attribuée un nombre entier identifiant le numéro de
groupe de cette image.

o Pour une image entrée I, on réalise la recherche dans l’arbre SR-tree de
l’information géographique des images qui sont proches dans un rayon r1.
On commence la recherche à partir de la racine de l’arbre et on descend vers

les nœuds fils ayant la région intersectant la sphère centrée à la position de
l’image et de rayon r1. Au niveau des feuilles, on va retourner toutes les
images qui sont proches dans le rayon r1 par rapport à l’image d’entrée.
Notez qu’au niveau des feuilles, on pointe vers l’élément des images dans
ces feuilles ; alors, on peut savoir le type de sinistre de toutes les images qui
sont proches géographiquement de l’image entrée.

S’il n’y a pas d’autres situations similaires parmi les images proches

géographiquement, on attribue une nouvelle étiquette (un nouveau
nombre entier) pour cette nouvelle image, c'est-à-dire qu’on ajoute
un nouveau groupe de proximité contenant seulement l’image qu’on
vient d’ajouter.

S’il y a quelques autres situations similaires parmi les images

</div>
(39)<div class='page_container' data-page=39>

S’il y a quelques autres situations similaires qui sont proches de
l’image d’entrée dans l’espace géographique et qui ont des étiquettes
différentes, c'est-à-dire que ces situations appartiennent à des groupes
de proximité différentes (par exemple groupes 1, 2, 3) et que la
nouvelle image joue le rôle d’un élément intermédiaire qui permet de
fusionner ces groupes de proximité en un seul groupe. Alors on
regroupe la nouvelle image et les éléments de tous ces trois groupes
(1, 2 et 3) en un seul groupe de proximité.

Le niveau d’urgence d’un groupe est la somme totale des niveaux d’urgence des
éléments dans le groupe. Alors, un groupe ayant seulement un feu dans un hôpital peut
avoir un niveau d’urgence plus élevé que celui ayant trois maisons en feu. On va afficher
sur l’écran les groupes de proximité différents pour que l’utilisateur puisse avoir une vue
globale sur les sinistres dans la ville, chaque groupe étant représenté par un symbole

représentant le type du sinistre de ce groupe, la taille du symbole dépendant du niveau
d’urgence du groupe (plus le symbole est gros, plus le niveau d’urgence est élevé).

Il y a quelques autres manipulations qu’on peut appliquer sur les SR-tree de notre
système pour donner des informations utiles à l’utilisateur comme suit :

• Notez que pour chaque groupe, on a une liste des éléments qui pointent vers les
éléments des images appartenant à ce groupe. Alors, si l’utilisateur veut voir en
détails chaque groupe, il nous faut seulement afficher les images dans la liste
correspondant à ce groupe, la taille de l’image dépendant du niveau d’urgence de
chaque image.

• On peut aussi afficher les monuments qui sont proches d’un sinistre quelconque en

recherchant dans l’arbre SR-tree des monuments tous les monuments autour de la
position du sinistre selon la méthode qu’on a déjà expliqué précédemment.

• Pour trouver les sinistres qui sont proches dans un rayon r d’un monument

quelconque, on réalise la recherche dans l’arbre SR-tree de l’information
géographique à partir de la racine de l’arbre, puis descend vers les nœuds fils ayant
la région qui intersecte la sphère centrée à la position du monument. Au niveau des
feuilles, on retourne les images ayant la distance depuis le centre du monument
inférieure ou égale au rayon r.

</div>
(40)<div class='page_container' data-page=40>

• Enfin, on peut voir que pour chaque type de situation d’urgence, par exemple
« feu », il y a plusieurs sous-types comme le feu dans des bâtiments, le feu dans la
forêt, … Si l’utilisateur veut se concentrer surtout sur les images de feu dans des
bâtiments par exemple, il peut cliquer sur un image de feu d’un bâtiment
quelconque affichées sur l’écran, le programme va utiliser la recherche de k-plus

proches voisins dans le SR-tree du type « feu » et afficher les k images les plus
similaires à l’image de feu du bâtiment que l’utilisateur a choisi. L’organisation
des données du contenu visuel des images dans les arbres SR-tree différents
correspondant aux différents types de sinistres nous permet d’éviter de faire la
recherche dans toute la base d’images.

4.3. Implémentation du système

4.3.1 Préparation des données

Au début de ce stage, on n’a pas encore une base d’images réelles des situations
d’urgence différentes, alors une tâche importante de ce travail de stage est de construire la
base d’images du projet IDEA [1] avec les images des sinistres réels. En combinant les
images sur les tremblements de terre dans quelques pays en Asie et les images trouvées
sur le site avec la licence « Creative commons », on a déjà
construit une base d’images de cinq types de sinistres différents (feu, blessé, bâtiment
endommagé, route endommagée et inondation). Pour chaque type de sinistre, les images
sont divisées en deux parties, une partie est annotée et ajoutée dans la base
d’apprentissage, une autre partie appartient à la base des images de test identifiant les
images que le systốme reỗoit un moment t. La table suivante donne le nombre d’images
correspondant à chaque type du sinistre :

Type du sinistre Base d’apprentissage Base de test Total

Feu 200 100 300

Blessé 200 100 300

Bâtiment endommagé 200 150 350

Route endommagée 200 100 300

Inondation 200 100 300

Table 2 - Base d'images des sinistres

</div>
(41)<div class='page_container' data-page=41>

le logiciel libre OpenJump ( pour préparer les données
SIG.

4.3.2 Environnement de programmation

Le système est construit dans l’environnement suivant :

• Système d’exploitation : Ubuntu 8.04

• Langage de programmation : C++

• Outil de programmation : QT Creator

Ce travail de stage bénéficie du code source du travail de thèse de NGUYEN Nhu
Van concernant la création des descripteurs internes du contenu visuel des images
(histobin de couleur, sac de mots visuels). D’ailleurs, on utilise aussi la librairie
« Shapefile C Library V1.2 » ( pour pouvoir lire les données
des monuments dans un fichier shapefile et les autres fichiers concernés.

4.3.3 Système construit

L’interface du programme est comme suit :

Figure 14 - Interface du système

</div>
(42)<div class='page_container' data-page=42>

ã Le bouton ô Apprendre ằ permet d’extraire le vecteur du contenu visuel des
images dans la base d’images d’apprentissage fournie par l’utilisateur, ces
descripteurs internes du contenu visuel vont être enregistrés dans des fichiers texte.
Alors, la phase d’apprentissage pour une base quelconque doit être réalisée
seulement une fois.

ã Le bouton ô Init ằ permet de structurer les descripteurs internes des images dans la
base d’apprentissage dans un SR-tree et de structurer les données des monuments
d’un fichier shapefile dans un autre SR-tree.

• Le bouton « Open » permet de donner des images actuelles qui sont les images
arrivant au système à un moment t. Le système va déterminer le type de sinistre
correspondant à chaque image et structurer ces images dans deux espaces de
localisation géographique et du contenu visuel par un SR-tree de l’information
géographique et cinq SR-tree du contenu visuel.

ã Le bouton ô Search » permet de rechercher et afficher les groupes de proximité
des sinistres similaires correspondant aux types du sinistre qu’on veut (on peut
afficher les groupes de tous les types ou seulement les groupes du type feu).

Le système nous permet aussi de trouver les monuments qui sont proches d’un
sinistre quelconque, les sinistres qui sont proches d’un monument comme un hôpital, les
sinistres autour d’un autre sinistre, etc. On utilise les symboles suivants pour identifier les
types de sinistres et les types de monument différents :

Figure 15 - Symboles des sinistres

</div>
(43)<div class='page_container' data-page=43>

Chapitre 5 – Analyse des résultats

Car le but de ce stage est de montrer ce que l'on peut faire en combinant
localisation et contenu images dans un système d’aide à la décision dans une situation de
post-catastrophe naturelle en zone urbaine. Alors, afin d’évaluer les résultats du système,
on fait des test basés sur des scénarios décrivant des situations où on peut montrer un
intérêt de rechercher des images en combinant localisation et contenu image. Dans ce
chapitre, on va évaluer les résultats en basant sur des scénarios différents et donner des
commentaires sur les points forts et les points faibles de notre système pour chaque
scénario.

5.1. Scénario 1 : attribution des niveaux d’urgence

</div>
(44)<div class='page_container' data-page=44>

Figure 17 - Groupes des situations d’urgence dans la ville

</div>
(45)<div class='page_container' data-page=45>

On peut voir que l’utilisateur peut observer les sinistres de tous les types ou
seulement les sinistres d’un ou deux types auxquels il s’intéresse. Chaque symbole dans
les résultats représente un groupe de sinistres similaires qui sont proches
géographiquement. La taille des symboles représente le niveau d’urgence correspondant à
chaque groupe.

L’utilisateur peut observer en détail des sinistres appartenant à un groupe
quelconque en cliquant sur le symbole correspondant à ce groupe, la taille des images
augmente selon le niveau d’urgence des images ce qui nous permet de comparer le niveau
d’urgence de chaque sinistre. Cela nous permet de donner des décisions de secours
raisonnables :

Figure 19 - Résultat des sinistres d'un groupe

Le point faible dans la phase d’attribution d’un niveau d’urgence est qu’on ne se
base pas encore sur le contenu de l’image pour distinguer le niveau d’urgence des
sinistres de même type (par exemple, on ne peut pas déterminer qu’un feu est grand ou

petit). D’ailleurs, les paramètres qu’on utilise pour déterminer le niveau d’urgence sont
les paramètres qu’on propose, ils sont peut-être inexacts. Il nous faut consulter des experts
pour conntre les vrais paramètres.

5.2. Scénario 2 : détermination des monuments proches du sinistre

</div>
(46)<div class='page_container' data-page=46>

Figure 20 - Résultat des monuments proches d'un feu

La limite de ce système est qu’on donne l’information des sinistres et des
monuments sous forme de coordonnées GPS qui ne donnent pas l’adresse exacte pour
l’utilisateur. On peut améliorer le système en ajoutant les informations sur l’adresse
civique des monuments dans les données SIG de notre système. Cela nous permettrait de
donner l’adresse exacte d’un monument où il y a actuellement un sinistre pour qu’on
puisse prendre des décisions plus rapidement.

5.3. Scénario 3 : détermination des sinistres proches d’un monument

</div>
(47)<div class='page_container' data-page=47>

Figure 21 - Résultat des sinistres proches d'un bâtiment

5.4. Scénario 4 : détermination des sinistres proches d’un sinistre

Dans ce scénario, on veut déterminer tous les sinistres qui sont proches
géographiquement dans un rayon autour d’un sinistre quelconque. L’idée est de donner à
l’utilisateur des informations sur les sinistres différents qui sont à proximité d’un sinistre
quelconque. Cela nous permet de coordonner les ộquipes de secours de faỗon appropriộe
pour traiter non seulement le sinistre d’entrée mais aussi les autres sinistres qui sont
proches si possible. Par exemple, si on reỗoit linformation quil y a plusieurs blessés à
proximité d’un hôpital en feu, on peut augmenter les médecins dans l’équipe des
pompiers envoyée vers l’hôpital pour aider non seulement les blessés de l’hôpital mais
aussi les autres blessés qui sont proches. En connaissant les sinistres autour d’un sinistre

quelconque, on peut modifier la décision. Par exemple, on va envoyer des pompiers vers
un hôpital endommagé par avion à la place de voitures si on constate que toutes les routes
vers cet hôpital sont bloquées.

</div>
(48)<div class='page_container' data-page=48>

5.5. Scénario 5 : détermination des sinistres similaires à un autre

sinistre

On peut voir que pour chaque type de situation d’urgence, par exemple « bâtiment
endommagé », il y a plusieurs sous-types comme l’état de dommages d’une maison, d’un
bâtiment, … Après un tremblement de terre, si l’utilisateur veut se concentrer surtout sur
les images des grands bâtiments endommagés plutôt que sur les images des maisons ou
des petits bâtiments endommagés, il peut cliquer sur une image d’un grand bâtiment
endommagé affichée sur l’écran. Le programme alors va utiliser la recherche des k-plus
proches voisins (k précisé par l’utilisateur) dans l’arbre SR-tree du type « bâtiment
endommagé » et afficher les k images les plus similaires à l’image d’entrée en espérant
que les résultats sont surtout des images de grands bâtiments endommagés. Les résultats
dans la figure suivante sont assez bons :

</div>
(49)<div class='page_container' data-page=49>

Chapitre 6 – Conclusions et perspectives

Ce travail de stage présente une approche pour le développement d’un modèle de
recherche d’informations basé sur une double information de contenu des images et de
localisation géographique. Le système construit implémente l’approche proposée qui
structure les images en même temps dans deux espaces de localisation géographique et du
contenu visuel par des arbres SR-tree [2]. La structuration SR-tree est choisie pour les
raisons suivantes : d’une part, elle est utile pour les applications d’indexation de similarité
des images/vidéos ; d’autre part, son mécanisme de regroupement des données qui sont
proches par des rectangles englobants et des sphères englobantes correspond bien à la
structuration des données géographiques. Cette approche nous permet de combiner
l’information de localisation et du contenu des images pour retrouver des situations

d’urgence dans une ville et leur attribuer un niveau d’urgence en fonction de la proximité
géographique d’événements similaires.

D’ailleurs, on propose aussi l’utilisation de la structure SR-tree pour structurer des
différents monuments (maison, grand bâtiment, hôpital, école) dans la ville. Ces
monuments sont enregistrés dans un fichier shapefile, un type de fichier utilisé dans les
systèmes SIG (Système d’Informations Géographiques) pour les données géographiques.
La forme de type polygone des monuments correspond bien à la structuration par des
SR-tree. Cette extension dans l’approche proposée nous permet d’attribuer un niveau
d’urgence non seulement en fonction de la proximité géographique d’événements
similaires, mais aussi en fonction de la nature des monuments autour de la position d’un
sinistre. Par exemple, un feu dans un hôpital est plus urgent que des feux dans quelques
maisons.

</div>
(50)<div class='page_container' data-page=50>

Cependant, il existe encore des limites dans le système construit. Premièrement, on
traite seulement l’information géographique des images sous forme de données GPS. Il
existe d’autres types de localisation géographique à traiter comme l’adresse civique.
Deuxièmement, le système ne traite pas encore les images qui n’ont pas cette localisation.
Troisièmement, la reconnaissance des situations d’urgence n’est pas toujours exacte car
actuellement, il n’y a pas encore une méthode parfaite pour la recherche d’images par le
contenu. Finalement, le niveau d’urgence est attribué seulement en fonction de la
proximité géographique des situations similaires et de la nature des monuments autour du
sinistre tandis qu’il existe plusieurs autres paramètres qui peuvent influencer ce niveau
d’urgence.

Il existe des travaux à faire pour que le système puisse devenir un bon outil d’aide
à la décision dans une situation de post-catastrophe naturelle :

• On peut consulter les experts pour déterminer tous les paramètres qui peuvent
influencer l’attribution d’un niveau d’urgence pour les sinistres et pour construire

une base d’apprentissage identifiant le niveau d’urgence correspondant aux valeurs
différentes de ces paramètres. Dans ce cas, on peut utiliser n’importe quelle
méthode d’apprentissage afin de déterminer un niveau d’urgence approprié à
chaque situation. Notez que l’état d’un sinistre (par exemple, un grand feu ou un
petit feu) est aussi un paramètre important ; mais pour déterminer ce paramètre, il
reste un grand travail à faire.

• Si on peut trouver de bons descripteurs internes du contenu visuel des images, on

pourra améliorer la recherche des situations d’urgence.

• Il serait possible d’utiliser une base de données contenant des références entre des

</div>
(51)<div class='page_container' data-page=51>

REFERENCES

[1] Site web du projet de recherche IDEA, March 20, 2009.
[2] Noriko Katayama, Shin’ichi Satoh, “The SR-tree : An index structure for
High-Dimentional Nearest Neighbor Queries”, In Proceedings of the ACM SIGMOD
International Conference on Management of Data, pages 369-380, Tucson, Arizon USA,
1997.

[3] Jean-Marc OGIER, “Partie 3 : Techniques de Clustering et d’indexation
multidimensionnelles », cours Indexation Multimedia, université de La Rochelle.

[4] Stefan Berchtold, Daniel A.Keim, Hans-Peter Kriegel, “The X-tree: An index
structure for High-Dimensional Data”, In Proceedings of the 22nd International
Conference on Very Large Databases, pages 28–39, 1996

[5] Automn Guttman, « R-tree : A dynamic index structure for spatial searching », In
Proceedings of the ACM SIGMOD International Conference on Management of Data,

pages 47-57, Boston, MA, June 1984.

[6] Timos Sellis, Nick Roussopoulos et Christos Faloutsos, « The R+-tree : a dynamic
index for multi-dimensional objects », In proceedings of the 16th International
Conference on Very Large databases, page 507-518, 1987.

[7] Norbert Beckmann, Hans-Peter Kriegel, Ralf Schneider, Bernhard Seeger, « The
R*-tree : An efficient and Robust Access Method for Points and Rectangles », In proceeding
of the ACM SIGMOD International Conference on Management of Data, page 322-331,
1990.

[8] David A.White, Ramesh Jain, “Similarity indexing with the SS-tree”, In proceeding of

the 12th International Conference on Data Engineering, page 516-523, 1996.

[9] John T. Robinson. “The k-d-b-tree: A search structure for large multidimensional
dynamic indexes”. In Proceedings of the ACM SIGMOD International Conference on
Management Data, pages 10–18, 1981.

[10] Andreas Henrich, Hans-Werner Six, Peter Widmayer, “The LSD tree: spatial access
to multidimensional point and non point objects”, In Proceedings of the 15th International
Conference on Very large data bases, pages 45-53, Amsterdam, The Netherlands, July
1989.

[11] Jean-Pierre Chevallet, Joo-Hwee Lim, “SnapToTell – Accès ubiquitaire à de

l’information multi-média à partir d’un telephone portable”, 2e Conférence en Recherche

d’Informations et Applications, pages 245-260, Grenoble, France, Mars 2005.

</div>
(52)<div class='page_container' data-page=52>

[13] Jean-Pierre Chevallet, Joo-Hwee Lim, Mun-Kew Leong, “Object Identification and
Retrieval from Efficient Image Matching: SnapToTell with the STOIC Dataset”,
Information Processing and Management, vol. 43, pages 515-530, 2007.

[14] Jean-Pierre Chevallet, Joo-Hwee Lim, Ramnath Vasuda, “SnapToTell: A Singapore
image test bed for ubiquitous information access from camera”, In Proceedings of the
ECIR Conference, page 530-532, Santiago de Compostela, Spain, 2005.

[15] Pujianto Cemerlang, Joo-Hwee Lim, Yilun You, Jun Zhang et Jean-Pierre Chevallet,
« Towards automatic mobile blogging », In Proceedings of IEEE International
Conference on Multimedia and Expo, pages 2033-2036, 2006.

[16] Nick Roussopoulos, Stephen Kelley and Frédéric Vincent, “Nearest Neighbor
Queries”, In Proceedings of the ACM SIGMOD International Conference on
Management of Data, pages 71-79, San Jose, CA, 1995.

</div>

Indexation et recherche d’image par le contenu et par la localisation géographique

<b>INSTITUT DE LA FRANCOPHONIE POUR L’INFORMATIQUE </b>

<b>LABORATOIRE INFORMATIQUE, IMAGE ET INTERACTION </b>

<b>UNIVERSITE DE LA ROCHELLE</b>

<b>MEMOIRE DE FIN D’ETUDE </b>

<b>Master d’informatique </b>

<b>Option Intelligence artificielle & multimédia </b>

<b>Sujet : Indexation et recherche d’image par le </b>

<b>contenu et par la localisation géographique</b>

<b>Encadrement : </b>

Jean-Marc OGIER

Alain BOUCHER

NGUYEN Nhu Van

<b>Réalisé par : </b>

LAI Hien Phuong

Promotion 13, IFI

<b>TABLE DES MATIERES </b>

<b>REMERCIEMENTS </b>

<b>RESUME </b>

<b>ABSTRACT </b>

<b>LISTE DES FIGURES </b>

<b>LISTE DES TABLEAUX </b>

<b>Chapitre 1 – Introduction </b>

<i><b>1.1. Problématique </b></i>

<i><b>1.2. Motivation </b></i>

<i><b>1.3. Objectifs </b></i>

<i><b>1.4. Contribution </b></i>

<i><b>1.5. Environnement de stage </b></i>

<b>Chapitre 2 – Etat de l’art </b>

<i><b>2.1. Indexation multidimensionnelle </b></i>

<i><b>2.2. Travaux similaires </b></i>

<b>Chapitre 3 – SR-tree </b>

<i><b>3.1. Présentation du SR-tree </b></i>

<i><b>3.2. Insertion dans le SR-tree </b></i>

(

)

(

)

(

<i>i</i>

<i>D</i>

)

<i>w</i>

<i>C</i>

<i>w</i>

<i>C</i>

<i>x</i>

<i>C</i>

<i>x</i>

=

≤

≤

∑

∑

1

.

.

*

.

(

)

(

)

(

)

(

<i>MAXDIST</i>

<i>x</i>

<i>C</i>

<i>R</i>

)

<i>d</i>

<i>r</i>

<i>C</i>

<i>x</i>

<i>C</i>

<i>x</i>

<i>d</i>

<i>d</i>

<i>d</i>