andrianomenjanaharyDinaHM_ESPA_MAST2_17.pdf

UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE
********************
Mention : INFORMATION GEOGRAPHIQUE ET
AMENAGEMENT DU TERRITOIRE
*******************
Parcours : Géomètre Topographe
Mémoire de fin d’études en vue de l’obtention du
Grade Master II Titre Ingénieur en Géomètre Topographe
Présenté par : ANDRIANOMENJANAHARY Dina Henintsoa Mahasambatra
Date de Soutenance : 03 Aout 2017
Promotion 2016

UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE
********************
MENTION INFORMATION GEOGRAPHIQUE ET
AMENAGEMENT DU TERRITOIRE
*******************
Parcours : Géomètre Topographe
Mémoire de fin d’études en vue de l’obtention du Grade Master II Titre Ingénieur en
Géomètre Topographe
Présenté par : ANDRIANOMENJANAHARY Dina Henintsoa Mahasambatra
Président de jury : Monsieur RABARIMANANA Mamy, Responsable de la
Mention IGAT, Professeur, Enseignant chercheur à l’ESPA
Directeurs de mémoire: Monsieur RABEMALAZAMANANA, Enseignant à l’ESPA
Madame RABEHERIMANANA Lyliane, Maître de conférences,
Enseignant chercheur à l’ESPA
Examinateurs : Monsieur RABETSIAHINY, Maître de conférences, Enseignant
chercheur à l’ESPA
Monsieur RAZAFINDRAKOTOHARY Tiana , Enseignant à
l’ESPA

i
REMERCIEMENTS
Tout d’abord je tiens à remercier DIEU Tout Puissant parce que ce travail de mémoire n’aurait
pas été possible sans Lui. Mes plus vifs et sincères remerciements s’adressent aussi à :
Monsieur ANDRIANAHARISON Yvon, Professeur titulaire à l’ESPA, Directeur de
l’Ecole Supérieure Polytechnique d’Antananarivo, qui m’a autorisé à présenter ce présent
mémoire ;
Monsieur RABARIMANANA MAMY, Professeur et Responsable de la mention
Information Géographique et de l’Aménagement de Territoire, qui nous a permis d’effectuer
notre formation et ce mémoire de fin d’études ;
Madame RABEHERIMANANA Lyliane, Maître de conférences, Enseignant chercheur
à l’ESPA, encadreuse pédagogique de ce mémoire, qui n’a cessé de me prodiguer des conseils
précieux et m’a consacré une grande partie de son temps ;
Monsieur RABEMALAZAMANANA, encadreur professionnel de ce mémoire qui n'a
pas ménagé son effort pour ses conseils techniques et ses encouragements ;
Monsieur RABETSIAHINY, Maître de conférences, Enseignant chercheur à
l’ESPA, qui a accepté d’examiner ce travail malgré leurs nombreuses occupations ;
Monsieur RAZAFINDRAKOTOHARY Tiana, Enseignant à l’ESPA, qui a aussi accepté
d’examiner ce travail malgré leurs nombreuses occupations ;
Tous les Enseignants et Personnel de l’ESPA plus particulièrement ceux de la mention
IGAT pour leur contribution à notre formation ;
Mes chers parents pour leurs grands soutiens, et à toute ma famille ;
Mes collègues de GEOTOPO M2 promotion 2016, ainsi qu’à tous les étudiants de la
mention IGAT et à tous mes Amis, Grand Merci !

ii
SOMMAIRE
REMERCIEMENTS ..................................................................................................................................... i
LISTE DES TABLEAUX ........................................................................................................................... iv
LISTE DES FIGURES................................................................................................................................. v
LISTE DES ACRONYMES......................................................................................................................... v
LISTES DES ANNEXES............................................................................................................................ ix
INTRODUCTION........................................................................................................................................ 1
PARTIE 1 : GENERALITES....................................................................................................................... 2
Chapitre 1 : PRESENTATION DU THEME.......................................................................................... 3
1.1 Contexte et justification........................................................................................................... 3
1.2 Problematique.......................................................................................................................... 4
1.3 Objectifs .................................................................................................................................. 5
1.4 Resultats attendus.................................................................................................................... 5
Chapitre 2 : QUELQUES NOTIONS DE BASES.................................................................................. 6
2.1 NOTION DE BASE DE DONNEES ...................................................................................... 6
2.2 NOTION DE SIG.................................................................................................................... 8
2.3 NOTION DE WEBMAPPING.............................................................................................. 13
Partie 2 : MODELISATION DE L’APPLICATION ................................................................................. 22
Chapitre 3 : ANALYSE ET FORMALISATIONS DES BEOINS....................................................... 23
3.1 Identification des acteurs....................................................................................................... 23
3.2 Identification des cas d’utilisation......................................................................................... 24
3.3 Diagramme des cas d’utilisation ........................................................................................... 24
3.4 Scénarii des principaux cas d’utilisation ............................................................................... 25
3.5 Quelques digrammes de séquences ....................................................................................... 29
Chapitre 4 : ETUDE CONCEPTUELLE .............................................................................................. 34
4.1 Méthode utilisée pour la conception des bases de données................................................... 34
4.2 Mise en œuvre de la méthode choisie.................................................................................... 34
Chapitre 5: ETUDE TECHNIQUE ....................................................................................................... 40
5.1 Choix des logiciels ................................................................................................................ 40
5.2 Langages utilisés ................................................................................................................... 44
Partie 3 : MISE EN ŒUVRE DE LA PLATE FORME............................................................................. 46

iii
Chapitre 6 : CREATION DE LA STRUCTURE DE LA BASE DE DONNEES ET
CONFIGURATION DU SERVEUR CARTOGRAPHIQUE............................................................... 47
6.1 Collecte des données ............................................................................................................. 47
6.2 Installation et configuration de PostgreSQL et de sa cartouche spatiale PostGis ................. 47
6.3 Création de la structure de la base de données...................................................................... 47
6.4 Configuration du serveur cartographique : geoserver ........................................................... 49
Chapitre 7 : LE DEVELOPPEMENT DE L’INTERFACE CARTOGRAPHIQUE WEB................... 52
7.1. Utilisation de l'API OpenLayers, Ext et GeoExt................................................................... 52
7.2. Mise en place de l’application web de routage...................................................................... 55
Chapitre 8 : PRESENTATION DE L’APPLICATION ........................................................................ 57
8.1 Présentation de l’interface cartographique ............................................................................ 57
8.2 Présentation de l’interface des gestionnaires et des administrateurs..................................... 62
CONCLUSION .......................................................................................................................................... 67
REFERENCES........................................................................................................................................... 65
WEBOGRAPHIE : .................................................................................................................................... 66
ANNEXES ................................................................................................................................... 67

iv
LISTE DES TABLEAUX
Tableau 2. 1 : Scénario du cas d’utilisation « S’authentifier » ................................................ 26
Tableau 2.2:Scénario du cas d’utilisation « Naviguer »........................................................... 26
Tableau 2.3:Scénario du cas d’utilisation « Rechercher » ....................................................... 27
Tableau 2.4 : Scénario du cas d’utilisation « Mètre à jour les données »................................ 28
Tableau 2.5 : Scénario du cas d’utilisation « calculer itinéraire » ........................................... 28
Tableau 2.5 : Scénario du cas d’utilisation « Administrer ».................................................... 29
Tableau 2.7:Extrait du dictionnaire des données ..................................................................... 35
Tableau 2.8 : Comparaison entre Mapserver et Geoserver ...................................................... 41
Tableau 2.9:comparaison entre Openlayers et Leaflet............................................................. 42

v
LISTE DES FIGURES
Figure 1.1: Les composants d’un SIG........................................................................................ 9
Figure 1.2 : Les données géographiques.................................................................................. 11
Figure 1.3 : L’architecture d'une application web.................................................................... 15
Figure 1. 4 : Architecture d'une application de webmapping................................................... 17
Figure 1.5: L’opération de WMS ............................................................................................. 18
Figure 1.6 : L’application de WFS........................................................................................... 20
Figure 2.7: Diagramme de cas d'utilisation.............................................................................. 25
Figure 2.8: Diagramme de séquences du cas d'utilisation : Rechercher .................................. 30
Figure 2. 9: Diagramme de séquences du cas d'utilisation : Calculer itinéraire....................... 31
Figure 2.10: Diagramme de séquences du cas d'utilisation : Authentifier............................... 32
Figure 2.11: Diagramme de séquences du cas d'utilisation : Mettre à jour les données .......... 33
Figure 2.12 : Le modèle conceptuel de donnée........................................................................ 36
Figure 2.13: Modèle logique des données................................................................................ 37
Figure 2.14 : Modèle physique des données ............................................................................ 38
Figure 2.15 : Extrait du script de la base de données............................................................... 39
Figure 3.16 : Fenêtre SQL de Pg Admin.................................................................................. 48
Figure 3.17 : Différents types d’entrepôts en lien avec la source des données spatiales. ........ 50
Figure3. 18: Édition des Systèmes de Référence de Coordonnées dans Geoserver................. 51
Figure 3.19 : Chargement d’OpenLayers dans une page web.................................................. 52
Figure 3.20 : Création d’un visualiseur OpenLayers :............................................................. 53
Figure 3. 21 : Création des couches secondaires...................................................................... 54
Figure 3.22 : Intégration d’EXT JS dans une page HTML...................................................... 54
Figure 3.23 : intégration de Geoext dans une page HTML...................................................... 55
Figure 3.24 : Importation des fichiers OSM dans Postgres Sql ............................................... 56
Figure 3.25 : Page d’accueil..................................................................................................... 57
Figure 3.26 : Interface cartographique ..................................................................................... 58
Figure 3.27 : Le Gridpanel ....................................................................................................... 59
Figure 3.28 : Formulaire de sélection....................................................................................... 60
Figure 3.29:Formulaire de recherche par mot clé .................................................................... 60
Figure 3.30: Aller à .................................................................................................................. 61
Figure 3.31 : calcul de routage................................................................................................. 61
Figure 3.32: Affichage des données attributaires dans pop-up ................................................ 62

vi
Figure 3.33 : Authentification .................................................................................................. 62
Figure 3.34 : Inscription à la plate-forme................................................................................. 63
Figure.3. 35: interface des gestionnaires.................................................................................. 63
Figure 3.36 : Boutons permettant de faire la mise des données............................................... 64
Figure 3. 37 : Formulaire d’insertion et de modification ........................................................ 64
Figure 3. 38 : Enregistrement d’une parcelle .......................................................................... 65
Figure 3. 39 : Formulaire de contact ........................................................................................ 65
Figure 3.40 : Gestion des membres.......................................................................................... 66
Figure 3.41 : Supprimer un gestionnaire.................................................................................. 66
Figure A.41 : Assistant d'installation de PostgreSQL.............................................................. 68
Figure A.42: Répertoire de destination de PostgreSQL........................................................... 68
Figure A.43: Mot de passe du super-utilisateur ....................................................................... 69
Figure A.44: Port de connexion à PostgreSQL........................................................................ 69
Figure A.45::'Locale' par défaut............................................................................................... 70
Figure A.46: Fin de l'installation.............................................................................................. 70
Figure A.47: Script De La Base De Donnees........................................................................... 73
Figure A.48: Création d’un nouvel espace de travail............................................................... 74
Figure A.49: Les différents types d’entrepôts en lien avec la source des données spatiales. .. 75
Figure A.50: Création d’un entrepôt en lien avec une base de données PostgreSQL.............. 76
Figure A.51: Création d’un entrepôt en lien avec des données rasters. ................................... 77
Figure A.52: Édition des Systèmes de Référence de Coordonnées ......................................... 78
Figure A.53:Visualisation de la version de pg routing ............................................................ 79
Figure A.54: Visualisation des données OSM dans Pgadmin.................................................. 80

vii
LISTE DES ACRONYMES
SINGLES SIGNIFICATIONS
API Application Programming Interface
ASP Application Service Provider
BD Base de Donné
CGI Common Gateway Interface
CSS Cascading Style Sheets
FTP File Transfer Protocol
GIF Graphics Interchange Format
GML Geography Markup Language
HTML Hyper Text Markup Manguage
HTTTP HyperText Transfer Protocol
IIS Internet Information Services
JPG Joint Photographic Group
JSON JavaScript Object Notation
MCD Modèle Conceptuel de Données
MLD Modèle Logique de Données
MPD Modèle Physique de Données
OGC Open Geospatial Consortium
PHP Hypertext Preprocessor
SIG Système d’Information Géographique
SGBDRO Systèmes de Gestion de Base de Données Relationnel et Objet
SLD Styled Layer Descriptor
SQL Structured Query Langage
SVG Scalable Vector Graphics
TCP/IP Transmission Control Protocol/Internet Protocol
URL Uniform Resource Locator
W3C World Wide Web Consortium
WCS Web Coverage Service

viii
SINGLES SIGNIFICATIONS
WFS Web Feature Service
WMS Web Map Service
WPS Web Process Service
WWW World Wide Web
XML eXtensible Markup Language

ix
LISTES DES ANNEXES
Annexe 1: Procedure d'installation de PostgresSQL................................................................ 68
Annexe 2 : Script de La Base de Donnees ............................................................................... 71
Annexe 3 : Publication des donnees dans Geoserver............................................................... 74
Annexe 4 : Importations des Fichiers Osm dans Postgres SQL............................................... 79

1
INTRODUCTION
La ville d’Antananarivo fait face actuellement à des problèmes d’extension et de
développement urbain. La population dans la ville d’Antananarivo ne cesse de s’accroître à
cause de l’exode rural. De plus, la ville d’Antananarivo reçoit d’innombrables visiteurs venant
des pays étrangers. La ville s’étend vers les zones périphériques, les activités économiques sont
florissantes, les commerces et les services se créent de jour en jour.
En effet, les emplacements des équipements sociaux ou des infrastructures socio-économiques
sont difficiles à trouver. Le problème d’orientation et de repérage se pose alors car le public ne
connaisse plus la ville à travers ses lieux qui ont un intérêt. La Connaissance de son espace de
vie dans les détails, s'avère donc essentielle.
Le système d’information géographique (SIG) pourrait contribuer à la résolution de ce
problème à l’aide des outils d’information localisée et des outils de cartographies dont elle
dispose. L’internet est aussi un véritable outil qui permet de diffuser et de communiquer des
informations géographiques provenant de ce système. L’association entre le SIG et l’internet
appelé le webmapping ou diffusion de cartes via le réseau internet, est un domaine en pleine
expansion grâce au développement des solutions open source. Avant l’apparition du
webmapping, la cartographie était réservée à quelques entreprises et instituts. Elle nécessitait
du matériel et des logiciels extrêmement chers et complexes ainsi que des cartographes et des
géomatiques compétant. A présent, générer, mettre en forme et mettre en ligne une carte sur
internet est accessible et quasiment gratuite pour tous. A l’aide de cet outil SIG et Internet, il
s'agira dans ce mémoire intitulé « Mise en place d’une application webmapping de
géolocalisation des points d’intérêt de la ville d’Antananarivo » de construire et de mettre
en ligne une carte interactive et dynamique de la ville d’Antananarivo. Cette application se veut
être un outil d'aide, un guide pour tout citoyen qui souhaite visiter la ville d’Antananarivo et se
déplacer sans difficultés.
Pour mieux appréhender ce sujet, trois grandes parties seront détaillées. La première partie
consiste à expliquer les généralités. La deuxième partie traitera les modélisations de
l’application .La troisième partie sera consacrée à la mise en œuvre de la plateforme.

3
Chapitre 1 : PRESENTATION DU THEME
Pour débuter les diverses études de la conception de ce projet, il faut tout d’abord expliquer la
situation actuelle de la ville d’Antananarivo et d’expliquer les avantages majeures de la mise
en œuvre de ce projet .Pour y parvenir, on va essayer de faire une analyse sur les problèmes qui
se posent, de citer les objectifs à atteindre et d’envisager des résultats.
1.1 CONTEXTE ET JUSTIFICATION
1.1.1 Contexte
La ville d’Antananarivo, située dans les hautes terres centrales de Madagascar, culmine à 1 300
m d’altitude. Elle est localisée entre 18°55’ de latitude sud et 47°32’ de longitude. Sa superficie
est de 86,4 km2. Elle dispose d’un climat tropical caractérisé par des hivers frais et très
secs et des étés doux et pluvieux. Administrativement, la ville est chef-lieu de la région
Analamanga, du district d’Antananarivo-Renivohitra et de la commune urbaine
d’Antananarivo. Etant la plus vaste et la plus importante en termes de densité de la population,
la Commune urbaine d’Antananarivo est divisée en six arrondissements pour une meilleure
administration de la ville. Antananarivo est le cœur de Madagascar, c’est la première ville et
capitale du pays, Antananarivo est également son centre économique. Tana est une ville qu’il
ne faut surtout pas manquer durant votre séjour tant elle possède un attrait touristique fabuleux,
qui ne se découvre pas toujours aux premiers abords. Elle possède en effet un riche héritage
historique dont certaines allées sont des témoins comme par exemple : l’avenue de
l’indépendance, le palais de la reine à Manjakamiadana, etc.
La ville abrite pratiquement tous les jours de grandes rencontres régionales ou sous régional.
Les patrimoines historiques favorisent la venue de nombreux visiteurs dans la ville. Pour ce
faire, la ville dispose de nombreuses infrastructures hôtelières, d'hébergement et de restauration.
En plus, Au plan sanitaire, la ville dispose de nombreuses infrastructures publiques et privées
de santé. La ville d’Antananarivo dispose aussi de nombreux points d’intérêts. Et sur le plan
éducatif, La ville d’Antananarivo compte de nombreuses universités (publiques et privées), de
nombreuses grandes écoles et de nombreux lycées et collèges. C’est la raison pour laquelle les
habitants dans les autres régions viennent à Antananarivo par diverses raisons.

4
1.1.2 Justification
Le taux de croissance de la population urbaine de 4,6% dépasse largement le taux national qui
est de 2,9 % selon l ’INSTAT en 2014. Par conséquent et à ce rythme, l’effectif de la population
devra doubler d’ici 15 à 20 ans. L’accroissement démographique à Madagascar est tel que les
grandes villes risquent d’être surpeuplées d’ici quelques années. La forte concentration
populaire dans les villes provient de la centralisation des nombreux secteurs d’activité qui
entraine l’exode rurale.
Le problème majeur qui justifie notre projet est la difficulté de trouver l’emplacement exacte
des infrastructures urbaines surtout pour les visiteurs et pour les touristes .Il est difficile de
connaitre la ville à cause des étroitement des bâtiments .Les avantages majeurs de la mise en
place de ce projet permet de connaitre la position géographique des points d’intérêts et d’obtenir
des informations concernant ces points d’intérêts .il est aussi possible grâce à ce projet de
faciliter la navigation dans la ville et faire une recherche des points d’intérêts que l’on veut
connaitre.
Ce sont toutes ces raisons qui nous motivent à mettre en place notre solution surtout
qu’actuellement aucune autre n’existe véritablement à Antananarivo. Les potentielles cibles
utilisatrices (futur clients) du système sont tous les habitats de la ville d’Antananarivo ainsi des
visiteurs venants des autres régions de la grande Ile ou même des étrangers.
1.2 PROBLEMATIQUE
La ville d’Antananarivo fait face actuellement à des problèmes d’extension et de
développement urbain. La population s'accroit au fil des années, de nouveaux habitants s'y
installent et la ville reçoit de nombreux visiteurs venus de divers horizons. Cette augmentation
de la population entraine une forte augmentation de la demande en termes des équipements
urbains. La connaissance de la ville à travers ses lieux qui ont un intérêt pour le grand public
devient alors problème majeure qu’on doit résoudre avant de sortir. En effet il n'est pas rare de
voir, les visiteurs et même les habitants demander l'emplacement d'un lieu. Il apparait donc une
forte demande de géolocalisation de ces lieux d'intérêt.
On peut dire alors que la connaissance du milieu dans lequel on vit permet de faire le choix
pour un meilleur choix possible et permet de mieux s'orienter et facilite notre quotidien. On
n'aura pas besoin de se renseigner auprès d'une personne ; de s'égarer au quotidien, ou de perdre
son temps et même de gaspiller son carburant.

5
La connaissance du milieu qu’on doit visiter favorise le choix pour une meilleure destination
et rassure le pouvoir de passer des moments agréables pour les visiteurs ou touristes. Rester
chez soi, dans son bureau ou partout ailleurs et pouvoir localiser un restaurant, un hôtel, une
administration afin de voir ce qu'on y offre comme service s'avère très intéressant. C'est à ces
préoccupations que nous voulons apporter des réponses.
La solution que nous mettons en place évite la perte du temps et le gaspillage des carburants
parce que la connaissance de la ville permet de déplacer dans une plus courte duré en prenant
le plus chemin possible. Cette solution permettra certainement à aider les habitants dans leurs
déplacements dans la ville d’Antananarivo.
1.3 OBJECTIFS
L’objectif de cette étude est de mettre en place une interface cartographique en ligne qui donne
au public les informations nécessaires pour se positionner et pour prendre des décisions d’ordre
économiques. La mise en place de ce site n’est possible qu’après avoir analyser les besoins
fonctionnels et techniques de la plate-forme à mettre en place et étudier les solutions techniques
et définir les contraintes. La mise en place de cette site nécessite aussi au préalable le
recensement de tous les points d’intérêts qui sont localisés dans la zone d’étude et la mise en
place de la base de donné avec référence géographique qui y corresponds afin de répondre aux
besoins des utilisateurs .Les points d’intérêts à recenser sont les bâtiment à caractère
administratifs et commerciales comme les ministères ,les infrastructures sanitaires (pharmacie,
dispensaire…), et les établissements scolaires (lycées, universités, grandes écoles) et les autres
infrastructures comme les restaurants ,les hôtels ,les stations de services, les garages, les
marchés…
1.4 RESULTATS ATTENDUS
Après avoir terminé toutes les études et tous les travaux nécessaires ,L’étude devrait aboutir à la
mise en place des bases de données géolocalisées des points d’intérêts de la ville
d’Antananarivo et à la réalisation d’une interface webmapping de géolocalisation des points
d’intérêts pour les utilisateurs et une interface d’administrations des données pour effectuer la
mise à jour des données . L’étude devrait aboutir aussi à la mise en ligne de la plate-forme afin que
tous utilisateurs puissent naviguer sur la carte, d’imprimer directement la carte, faire une interrogation
sur les données, de faire un calcul d’itinéraire et de distance ou de surface, et de faire une recherche à
l’aide d’un moteur de recherche contenus dans l’interface cartographique. Cette interface
cartographique doit mette à la disposition des utilisateurs, des outils qui font sens au regard d'un
besoin précis.

6
Chapitre 2 : QUELQUES NOTIONS DE BASES
Dans ce chapitre, on va faire un rappel sur les éléments nécessaires à la réalisation de ce
projet .Comme notre projet concerne l’élaboration d’une application webmapping, il est
important de connaitre quelques notions de base de données, de SIG et de webmapping.
2.1 NOTION DE BASE DE DONNEES
2.1.1. Définition
Une base de données est une collection de données organisées et reliées entre elles de telle sorte
que l'on puisse accéder à une quelconque d'entre elles par l'intermédiaire d'un programme
informatique. Les données doivent être exhaustives (la base contient toutes les informations
requises pour le service que l'on en attend), non redondantes (la même information n'est
présente qu'une seule fois). Une base de données est donc une entité logiquement cohérente,
représentant des éléments abstraits ou concrets du monde réel et qui véhicule une certaine
sémantique permettant sa gestion
2.1.2. Système de gestion de base de données (SGBD)
Un système de gestion de base de données est un ensemble de programme qui permet la
gestion et l’accès à une base de données.
2.1.2.1 Principes de fonctionnement
La gestion et l'accès à une base de données sont assurés par un ensemble de programmes qui
constituent le Système de gestion de base de données (SGBD). Un SGBD doit permettre l'ajout,
la modification et la recherche de données. Un système de gestion de bases de données héberge
généralement plusieurs bases de données, qui sont destinées à des logiciels ou des thématiques
différentes. Actuellement, la plupart des SGBD fonctionnent selon un mode client/serveur. Le
serveur (sous-entendu la machine qui stocke les données) reçoit des requêtes de plusieurs clients
et ceci de manière concurrente. Le serveur analyse la requête, la traite et retourne le résultat au
client.
2.1.2.2 Objectifs
Des objectifs principaux ont été fixés aux SGBD dès l'origine de ceux-ci, et ce, afin de résoudre
les problèmes causés par la démarche classique. Ces objectifs sont l’ indépendance physique
(La façon dont les données sont définies doit être indépendante des structures de stockage
utilisées), l’indépendance logique (Un même ensemble de données peut être vu différemment

7
par des utilisateurs différents), l’accès aux données (L'accès aux données se fait par
l'intermédiaire d'un Langage de Manipulation de Données ), l’administration centralisée des
données(Toutes les données doivent être centralisées dans un réservoir unique commun à toutes
les applications),le non-redondance des données(Afin d'éviter les problèmes lors des mises à
jour, chaque donnée ne doit être présente qu'une seule fois dans la base), la sécurité des
données (Les données doivent pouvoir être protégées contre les accès non autorisés.),
Résistance aux pannes, le partage des données (Il s'agit de permettre à plusieurs utilisateurs
d'accéder aux mêmes données au même moment de manière transparente), la Cohérence des
données(Les données sont soumises à un certain nombre de contraintes d'intégrité qui
définissent un état cohérent de la base)
2.1.2.3 Niveaux de description des données
Pour atteindre certains de ces objectifs, trois niveaux de description des données ont été définis
par la norme ANSI/SPARC.
Le niveau externe correspond à la perception de tout ou partie de la base par un
groupe donné d’utilisateurs, indépendamment des autres. On appelle cette description le schéma
externe ou vue. Il peut exister plusieurs schémas externes représentant différents vues sur la
base de données avec des possibilités de recouvrement. Le niveau externe assure l’analyse et
l’interprétation des requêtes en primitives de plus bas niveau et se charge également de convertir
éventuellement les données brutes, issues de la réponse à la requête, dans un format souhaité
par l’utilisateur.
Le niveau conceptuel décrit la structure de toutes les données de la base, leurs
propriétés (i.e. les relations qui existent entre elles : leur sémantique inhérente), sans se soucier
de l’implémentation physique ni de la façon dont chaque groupe de travail voudra s’en servir.
Dans le cas des SGBD relationnels, il s’agit d’une vision tabulaire où la sémantique de
l’information est exprimée en utilisant les concepts de relation, attributs et de contraintes
d’intégrité. On appelle cette description le schéma conceptuel.
Le niveau interne ou physique s’appuie sur un système de gestion de fichiers pour
définir la politique de stockage ainsi que le placement des données. Le niveau physique est donc
responsable du choix de l’organisation physique des fichiers ainsi que de l’utilisation de telle ou
telle méthode d'accès en fonction de la requête. On appelle cette description le schéma interne.

8
2.2 NOTION DE SIG
2.2.1 Définition
Un S.I.G (Un Système d'Information Géographique) est à la fois un outil de gestion de l'espace (gestion
de bases de données pour la saisie, le stockage, l'interrogation, l'analyse et l'affichage de données
localisées) et un outil d'aide à la décision. Un S.I.G est l'ensemble des structures, des méthodes, des outils
et des données constituées pour rendre compte des phénomènes localisés dans un espace spécifique et
faciliter les décisions à prendre sur cet espace.
2.2.1 Historique
Les S.I.G sont apparus suite à l’informatisation de la production cartographique qui avait commencé à la
fin des années 60. Cette informatisation a donné lieu à l’avènement d’une nouvelle technologie,
dénommée géomatique. Progressivement, les données cartographiques nécessaires à la géomatique ont
dû, pour être pleinement exploitables, s’organiser en bases de données. Ainsi, l’exploitation combinée
de plusieurs bases de données a conduit à la notion de système informatique capable d’en assurer la
synthèse, la gestion et l’archivage. Ce n’est que progressivement, au cours des années 80, que la notion
de Système d’Information Géographique s’est imposé comme l’objectif général de la géomatique.
2.2.2 Les domaines d'application des S.I.G
Si l’on essaie de caractériser les questions auxquelles un S.I.G est censé pouvoir répondre, on est vite
confronté à la multiplicité des domaines d’application possibles. Le SIG s’applique principalement à
l’aménagement du territoire (Schémas de Cohérence Territoriale (SCOT), Plan Locaux d’Urbanisme,
choix de tracés routiers, autoroutiers ou ferroviaires, études d’impacts…), à la gestion urbaine (gestion
de la voirie, des réseaux de distribution, des espaces verts, du patrimoine, de la sécurité, simulation
d’insertion de projets architecturaux….). Le SIG s’applique aussi à circulation et conduite
automobile (choix d’itinéraires, suivi de flottes de véhicules, aide à la conduite assistée par ordinateur),
à l’agriculture (génie rural, gestion des ressources en eau, suivi et prévision des récoltes, gestion des
forêts, aide à la mise en œuvre de la Politique Agricole Commune) et surtout à la protection de
l’environnement (définition des zones sensibles, suivi des évolutions, alerte aux pollutions, protection
des paysages.
2.2.3 Les composants d'un S.I.G
D’après la figure 1.1 ci-dessous, un Système d'Information Géographique est constitué de 5 composants
majeurs :

9
Figure 1.1: Les composants d’un SIG
2.2.3.1 Matériel
Il s'agit d'une composante indispensable à un S.I.G et l'élément fondamental de cette composante reste
l'ordinateur. Le S.I.G fonctionnent aujourd'hui sur une gamme très diversifiée d’ordinateurs : des micro-
ordinateurs (PC ou Mac) aux stations de travail sous Unix et des serveurs de données aux ordinateurs de
bureaux connectés en réseau ou utilisés de façon autonome.
Reliés à l'ordinateur, de multiples périphériques permettent d'assurer diverses fonctions et deviennent de
plus en plus indispensables :
Le matériel d'acquisition des données : scanner, table à digitaliser...
Le matériel de stockage des données : disques durs, CD Rom, disquettes, DVD...
Le matériel de visualisation des données : écrans traditionnels, écrans plats, portables...
Le matériel d'impression des données : imprimantes, traceurs.
2.2.3.2 Le logiciel
Le logiciel est une composante essentielle d'un S.I.G mais partir du postulat qu'un S.I.G n'est constitué
que d'un logiciel du fait de sa commercialisation est faux. Les logiciels S.I.G offrent une panoplie
d'outils et de fonctionnalités qui permettent de stocker, d'analyser et d'afficher des données
géographiques. Les logiciels S.I.G possède un outil d’Acquisition (les outils pour saisir, acquérir et
manipuler des données), d’archivage (les outils de gestion, de stockage et d'extraction des données),
d’analyse (les outils de requête, de transformation et d'analyse des données) Et d’affichage (les outils
de visualisation, d'affichage et de présentation des données)

10
2.2.3.3 Les données
Ce sont certainement les composantes les plus importantes d'un S.I.G. Les données géographiques et
les données tabulaires associées peuvent soit être constituées en interne, soit acquise auprès de
producteurs de données. Dans un SIG, deux types de données sont manipulés : les données attributaires
(ou descriptives) et les données géographiques.
Les données descriptives sont des données alphanumériques (quantitatives ou qualitatives)
associées à un objet ou une localisation géographique, soit pour décrire un objet géographique, soit pour
localiser des informations. Elle est souvent de nature : démographique (recensement de la population),
administrative (numéro officiel de la commune, …), économique (nombre de salariés, types
d’entreprises), sociale (nombre de places en crèche, …), ou commerciale (adresse des commerces). Elle
permet de mettre en évidence la répartition spatiale d'un objet en répondant aux questions : Où ? Où est
cet objet, Où ce phénomène se trouve-t-il ? Où se trouvent tous les objets d'un même type ? Ainsi que
les phénomènes présents sur un territoire donné : Quoi ? Que trouve-t-on à cet endroit ?
Les données géographiques sont les objets qu'on peut localiser à partir de leurs coordonnées
géographiques. Nous avons deux modes de représentation de ces objets géographiques : le mode raster
et le mode vecteur
Le mode vecteur est un mode de représentation géométrique sous forme de points, de
lignes et de polygones. Dans ce mode, les informations sont regroupées sous la forme de coordonnées
X, Y. Ainsi, les objets de type « point » sont représentés par les coordonnées X, Y ; les objets linéaires
(routes, fleuves, ...) sont représentés par une succession de coordonnées X, Y et les objets polygonaux
(les territoires,) par une succession de coordonnées X, Y délimitant une surface fermée. Le mode de
représentation vecteur a pour avantage de donner une représentation très conforme à la réalité, de
calculer avec précision la localisation et les dimensions des objets, d'individualiser les objets en leur
attachant des attributs.
Le mode raster correspond à une division régulière de l'espace sous forme de cellules ou
mailles généralement carrées appelées pixels, qui définissent la précision minimale de la structure. Ce
mode de représentation s'applique aux traitements d'images (satellitaires, photos aériennes). il a pour
avantage de faciliter le croisement des données et se prête bien à certains types de traitements
numériques (convolutions, filtres,) et d'analyse.

11
La figure 1.2 ci-dessous représente les données géographiques utilisées dans le SIG qui sont le mode
raster et le mode vecteur en partant du monde réel.
Figure 1.2 : Les données géographiques
2.2.3.4 Utilisateurs (personnes)
Un S.I.G étant avant tout un outil, ce sont ses utilisateurs (et le personnel qui entretient et gère le
système) qui lui permettent d'exister et de donner toute l'efficacité dont il peut être porteur. La
composante humaine d'un S.I.G est constituée des techniciens et ingénieurs chargés de la conception,
de l'entretien et de la gestion du S.I.G, des techniciens utilisant quotidiennement le S.I.G dans leur
travail et les décideurs utilisant le S.I.G comme moyen d'aide à la décision. Cependant, avec le
développement des S.I.G sur Internet, le nombre d'utilisateurs potentiels ou réels de S.I.G augmente
chaque jour. Comme tous les utilisateurs de systèmes d'information géographique ne sont pas forcément
des spécialistes, un tel système propose une série de boîtes à outils que l’utilisateur assemble pour
réaliser son projet. N’importe qui peut, un jour ou l’autre, être amené à utiliser un SIG.
2.2.1 Les principales fonctions d'un S.I.G
Le SIG est un terme général qui se réfère à un certain nombre de technologies, de processus et de
méthodes. Un système d'information est un ensemble d'informations organisées. Aussi, dans un S.I.G,

12
on trouve toujours les 4 grandes fonctionnalités permettant d'organiser, de représenter et de gérer
l'information géographique. Ce sont le :
Fonction d'ACQUISITION des données géographiques,
Fonction d'ARCHIVAGE ou de gestion des données,
Fonction d'ANALYSE (spatiale) ou d'interrogation des données,
Fonction d'AFFICHAGE (représentation spatiale) ou de visualisation des données.
2.2.2 Les systèmes de coordonnées
Les systèmes de coordonnées, également appelés projections cartographiques, sont des désignations
arbitraires pour les données spatiales. La projection cartographique est un ensemble de techniques
géodésiques permettant de représenter la surface de la Terre dans son ensemble ou en partie sur la surface
plane d'une carte. Leur objectif est de fournir une base commune pour la communication au sujet d'un
endroit particulier ou d'une zone particulière sur la surface de la Terre. La question la plus importante lors
de l'utili5sation des systèmes de coordonnées est de savoir quelle est la projection et de disposer
d'informations correctes sur le système de coordonnées associé à un jeu de données. Il existe deux types
de systèmes de coordonnées : géographiques et projetées.
Un système de coordonnées géographiques fait appel à une surface sphérique en trois
dimensions pour définir des emplacements sur la Terre. Il comprend une unité angulaire de mesure, un
méridien principal et un datum (basé sur un ellipsoïde). Dans un système de coordonnées géographiques,
un point est référencé par sa longitude et sa latitude. La longitude et la latitude correspondent aux angles
mesurés depuis le centre de la Terre vers un point de surface. Les angles sont souvent mesurés en degrés
(ou en grades). L’illustration suivante projette le monde sous forme d'un globe avec des valeurs de
longitude et de latitude.
Un système de coordonnées projetées se définit sur une surface plane, à deux dimensions.
Contrairement à un système de coordonnées géographiques, un système de coordonnées projetées possède
des longueurs, des angles et des surfaces constants dans les deux dimensions. Un système de coordonnées
projetées est toujours basé sur un système de coordonnées géographiques, lui-même basé sur une sphère
ou un ellipsoïde. Dans un système de coordonnées projetées, des emplacements sont identifiés par des
coordonnées x, y sur une grille, dont l'origine est située au centre de cette grille. Chaque position possède
deux valeurs qui la situent par rapport à cet emplacement central. L'une précise sa position horizontale et
l'autre, sa position verticale.

13
2.3 NOTION DE WEBMAPPING
2.3.1. Définition du Webmapping
Le terme « Webmapping » qui est une partie du domaine de compétences des Systèmes d’Informations
Géographiques (SIG), peut se définir par cartographie en ligne. Un système d’information géographique
est un système d’information permettant d’organiser et de présenter des données spatialement référencées
qui permet de produire de plans et de cartes géographiques. Ses usages couvrent les activités géomatiques
qui sont un ensemble des outils et méthodes permettant de représenter, d’analyser et d’intégrer des
données géographiques et de traitement et de diffusion de l’information géographique. Le Webmapping
qui est fait partie du domaine de compétences, des systèmes d’informations géographiques, permet
d’intégrer et la visualiser de cartes géo-référencées sur internet depuis un navigateur web.
L'accès à l'information doit être dynamique ce qui signifie que ce qui s'affiche doit être le résultat d'un
traitement déclenché à la demande de l'utilisateur. Les technologies utilisées sont avant tout celles du web
: architecture client-serveur, dans laquelle le client est un navigateur capable d'interpréter du code HTML,
le serveur est à la fois une machine qui archive des documents et des programmes susceptibles de les
générer à la demande et un programme permettant le dialogue avec le client. Le Protocole http est utilisé
pour les échanges entre le client et le serveur.
Le Webmapping permet aux utilisateurs d’utiliser des cartes en ligne et de les intégrer à des sites. Pour
une meilleure interopérabilité de ces informations, les services de Webmapping doivent se soumettre aux
différentes normes imposées par l’Open Geospatial Consortium (OGC) qui est une organisation
internationale qui développe et promeut des standards, afin d’assurer l’interopérabilité des contenus, des
services et des échanges dans les domaines de la géomatique et de l’information géographique
2.3.2. Fonctionnalités
Le Webmapping permet l’affichage de cartes sur internet. Mais il offre également un large panel de
fonctionnalités liées à la cartographie en ligne. Une application de webmapping permet au minimum
de cartographier à la demande des données géographiques (choix des couches, choix de l'emprise
géographique), d’afficher la carte dans un navigateur. Elle permet aussi le plus souvent d'imprimer la
carte, d’effectuer des mesures sur la carte, d’interroger les données cartographiées afin d'accéder à leur
sémantique, d’afficher cette sémantique dans un navigateur, d’effectuer des recherches portant sur la
sémantique ou la géométrie des données cartographiées, d’afficher les résultats de ces recherches dans un
navigateur et de localiser sur le fond de carte une adresse postale ou communale

14
Elle permet parfois de saisir de l'information et ainsi d'alimenter la base de données stockée sur le serveur
et d'effectuer des traitements complexes (calcul d'itinéraire).Dans tous les cas, elle ne met à disposition
que des outils qui font sens au regard d'un besoin précis et doit couvrir l'ensemble des besoins potentiels.
Il existe différente type de carte comme des plans ou satellite qu’on peut utiliser, en y intégrant plusieurs
vues possibles superposables comme le relief, les routes ou encore les noms de villes. A ceci s’ajoutent
des options réalisables en temps réel sur la carte comme le zoom ou le déplacement.
Il est possible d’ajouter des marqueurs sur une carte, c’est-à-dire qu’il est possible d’indiquer un
emplacement précis sur une carte, à l’aide de ses coordonnées, comme un lieu ou un bâtiment.
Il est également possible de calculer et visualiser un itinéraire sur une carte en ligne comme sur les sites
Mappy et ViaMichelin par exemple. Ceci est une autre fonctionnalité du Webmapping.
Toutes ces fonctionnalités que le Webmapping offre, sont réalisables grâce à différents outils configurés
dans une architecture de type client/serveur
2.3.3. L'architecture d'une application web
Le web est l’ensemble des machines communiquant en réseau à l'aide d'un langage commun. Parmi ces
machines, on distingue celles qui proposent des ressources, les serveurs, et celles qui les utilisent, les
clients. Les ressources peuvent être par exemple des documents hypertexte, des images, des fichiers XML
ou encore des programmes (PHP, Java, ASP.NET, Python, Perl, ...) chargés de les générer à la demande.
Quand un client accède à une ressource, c’est généralement pour consulter un document. Parfois, le client
utilise aussi le web pour modifier des données stockées sur le serveur. Dans ce cas, il accède
nécessairement à une ressource de type programme.
Pour atteindre une ressource, le client doit utiliser le protocole de communication
HTTP (HyperText Transfer Protocol) qui est un protocole de communication entre client et serveur
permettant d'accéder à des ressources distantes. Le protocole de communication http définit une
sémantique très simple (GET, POST, PUT et deux ou trois autres commandes) permettant de formuler
des requêtes qui sont interprétées côté serveur par un programme spécifique : le serveur web. Les requêtes
sont acheminées en mode texte par le réseau. Sur le web, une ressource est identifiée par son URL
(Uniform Resource Locator) qui est une chaîne de caractères normalisée destinée à être utilisée par tout
client web pour atteindre une ressource. Lorsque le client souhaite atteindre une ressource distante, il
émet donc une requête http mentionnant l'url de la ressource ; la requête comporte aussi dans certains cas
une liste de paramètres que la ressource devra exploiter.

15
Au niveau des serveurs, en plus du serveur web, nous pouvons avoir un serveur de données qui
va héberger le Système de Gestion de Base de Données (SGBD). Et pour y accéder, on utilise
le langage universel d'interrogation des bases de données : SQL. La figure 1.3 ci-dessous
représente l'architecture d'une application web.
Figure 1.3 : L’architecture d'une application web
2.3.4. Architecture d’un système de Webmapping
L’architecture d’un système de Webmapping est généralement de type client/serveur. Ce
système repose principalement sur les quatre composantes suivantes : le Client, le Serveur
cartographique, le Serveur web et le Serveur de données
2.3.4.1. Client
Le client, dans le domaine du Webmapping, permet l'interrogation des serveurs
cartographiques. Les clients utilisent un certain nombre d’outils développés à base de
différentes bibliothèques (JavaScript, Java…) Open Source ou non, tournés vers la
cartographie. Il existe différents clients qui permettent à l’utilisateur de visualiser des cartes
géo-référencées depuis une page web .il existe des catégories de client tel que les navigateurs
internet comme le Mozilla Firefox, opéra Muni, Google chrome et les applications
cartographiques comme Google maps, Bing Map, OpenLayers...
2.3.4.2. Serveur cartographique
Un serveur cartographique est un serveur spécifique qui permet la réalisation de cartes géo-
référencées. Il crée des images de cartes à l’aide de données spécifiques, stockées sur les
serveurs de base de données mis à leur disposition. Ces images de cartes sont envoyées aux
clients intéressés.

16
Il existe deux types de serveurs cartographiques qui sont les serveurs cartographiques libres et
Les serveurs cartographiques semi-libres. Les serveurs cartographiques libres où le code source
est à disposition du grand public, ce qui permet d’héberger et d’administrer son propre serveur
cartographique chez soi comme GeoServer ou MapServer. Les serveurs cartographiques semi-
libres qui ne permettent que d’être requêtés comme Google Map Server ou encore Bing Map
Server.
2.3.4.3. Serveur web
Le serveur web est un programme chargé de traiter les requêtes HTTP adressées par les clients.
Le serveur web décode les requêtes et retourne les résultats demandés. Le serveur web intègre
généralement des modules permettant d'exécuter un langage serveur comme PHP pour générer
des pages web dynamiques. Le serveur Web utilise d'autres logiciels qui fonctionnent en
collaboration avec le serveur HTTP comme le serveur de base de données afin de générer
dynamiquement une carte en réponse à une requête préparée par une interface utilisateur.
2.3.4.4. Serveur de données
Les serveurs de données utilisés pour faire de la cartographie en ligne ne sont autres que des
Systèmes de Gestion de Base de Données Relationnel et Objet (SGBDRO) améliorés qui
introduisent des extensions de données spatiales. Les serveurs de données expriment toutes les
informations concernant la localisation et la forme de particularités géographiques, ainsi que
les rapports entre elles - en suivant les spécifications de l’Open Geospacial Consortium (OGC)
afin de permettre le stockage des données utilisées par les serveurs cartographiques. Il existe un
certain nombre de serveurs de base de données capables de stocker ce type de données
spécifiques comme, par exemple, PostGIS qui est une extension du système de base de données
PostgresSQL.
2.3.5. Fonctionnement
Le serveur cartographique est le guichet automatique auquel l’utilisateur fait appel pour afficher
des cartes sur son poste informatique. Par le protocole de communication Internet, TCP/IP, des
ordinateurs branchés en réseau peuvent échanger de l’information via un navigateur Web ou
transférer des fichiers grâce au protocole FTP. L’architecture est de type client/serveur, c'est-à-
dire qu’un ordinateur dit serveur répond aux requêtes d’une série d’ordinateurs dits clients.
L’utilisateur, à partir de son terminal effectue des requêtes pour demander l’affichage d’une

17
carte spécifique ; le serveur cartographique interprète cette requête et renvoie la carte sous la
forme d’une image matricielle (png, jpg…) ou vectorielle (svg, swf,…).
Le moteur cartographique peut être contrôlé par des langages de script tels que PHP, javascript,
Python ou Perl qui lui permettent de générer dynamiquement une carte en réponse à une requête
préparée par une interface utilisateur. Le serveur cartographique peut chercher l'information
nécessaire à la réalisation de la carte dans ses propres ressources, mais aussi sur des serveurs
de données distants. La diffusion de l’information en ligne requiert une installation côté serveur
avec des logiciels tels qu’Apache (projet Open Source) ou IIS (Internet Information Services,
de Microsoft) qui tournent en tâche de fond et donnent accès aux serveurs de cartes à l’Intranet
et à l’Internet. Ces logiciels serveurs voient souvent leurs fonctions étendues par des
interpréteurs de scripts comme PHP ou ASP. Le serveur cartographique s’appuie sur ces
éléments pour recevoir des requêtes et renvoyer des images et des données. Côté client, un
navigateur web suffit, accompagné éventuellement par un viewer (visionneuse en français),
pour afficher la carte.
Les données peuvent être gérées par des logiciels spécifiques, les SGBDR, tels PostgreSQL, MySQL,
Oracle, entre autres, qui peuvent être installés directement sur le serveur contenant le serveur
cartographique ou sur un autre serveur, distant. Qu'importe le lieu, l'important est de pouvoir consulter
et éditer des données à distance. PostgreSQL et son extension spatiale PostGIS est le logiciel de SGBD
le plus utilisé dans le domaine du logiciel libre. La figure 1.3 ci-dessous représente l'architecture
d'une application web.
Figure 1. 4 : Architecture d'une application de webmapping

18
2.3.6. Les Services web Geospatiaux
L'Open Geospatial Consortium Inc(OGC), ou OGC est une organisation internationale à but
non lucratif fondée en 1994 pour répondre aux problèmes d'interopérabilité des systèmes
d'information géographique (SIG). Elle est également connue sous ses anciens noms : Open
GIS Project et Open GIS Consortium.
Afin de garantir l'interopérabilité des données et des traitements entre les différentes solutions
SIG, l'OGC a élaboré plusieurs protocoles d'échanges de données géographiques compatibles
avec les protocoles standards de services. Et ces standards OGC sont : WMS, WFS, WCS,
CSW.
2.3.6.1 WMS
Web Map Service ou WMS est un protocole de communication standard qui permet d'obtenir
des cartes de données géoréférencées à partir de différents serveurs de données. Cela permet de
mettre en place un réseau de serveurs cartographiques à partir desquels des clients peuvent
construire des cartes interactives. Le WMS est décrit dans des spécifications maintenues par
l'Open Geospatial Consortium.Le protocole WMS (Web Map Service) permet à un client
d'obtenir une carte créée à la demande par un serveur à l'aide d'une url normalisée
Le WMS est une service web de carte accessible par une url normalisée. D’après la figure 1.5
ci-dessous, l'OGC définit trois opérations disponibles dans un service WMS : GetCapabilities
, GetMap, GetFeatureInfo
Figure 1.5: L’opération de WMS
La requête GetCapabilities permet d’obtenir les capacités du serveur en renseignant les
métadonnées du service à savoir, les caractéristiques (service) : titre, description, personne
contact,etc.et les capacités (capabilities) : couches,styles (indiquent les noms des styles

19
applicables sur ces couches), le format (e.g. png,kml), l’ emprise (l’emprise géographique de la
couche complète et son système de référence spatial) et la projection.
La requête GetMap est un ensemble de paramètres permettant au serveur de construire une
carte. Il s’agit entre autres, de l’information que l’utilisateur souhaite voir sur la carte (une ou
plusieurs couches), les styles de représentation de ces couches, le lieu qui doit être représenté
(une emprise), le système de coordonnées géographiques ou le système de coordonnées
projetées qui doit être utilisé (le système de coordonnées de référence, ou CRS), le format de
sortie désiré (choisi dans la liste des formats publiés par l’opération GetCapabilities), la taille
de la sortie (largeur et hauteur), la couleur et la transparence de l’arrière-plan. Le résultat d’une
telle requête est une carte (le plus souvent une image consultable dans un simple navigateur
web). Cette opération correspond ainsi à une fonctionnalité de visualisation.
L’opération GetFeatureInfo correspond à une fonctionnalité d’interrogation. Il s’agit d’une
opération très attendue d’une application de Webmapping ; elle concerne la possibilité d’obtenir
des informations sur les objets géographiques représentés sur la carte produite. Pour cela, il faut
fournir dans la requête GetFeatureInfo un ensemble de paramètres permettant au serveur de
construire un résultat. La requête exprime des valeurs de paramètres correspondant à un clic
d’interrogation à une position x et y sur la carte produite. L’opération GetFeatureInfo peut
produire un résultat sous forme de tableau HTML ou un résultat XML.
2.3.6.2 WMS – C
La solution de mise en cache côté serveur pour accélérer le traitement des requêtes de
cartographie image dynamique ont été reprises sous forme d'une norme OGC : WMS Tile
cartographie des données proposées et à les tuiler en imagettes de taille réduite. Au final
l'ensemble constitue une pyramide d'images à n niveaux, chaque niveau contenant des tuiles
(souvent de 256 pixels par 256 pixels). Le WMS-C est un service web de carte caché accessible
par une url normalisée. Nécessite de calculer une pyramide d'images multi résolutions côté
serveur. Un serveur WMS doit répondre à 3 requêtes types : GetCapabilities, GetMap,
GetFeatureInfo.
Pour obtenir une carte à la demande, comme précédemment le client va envoyer une requête
getMap au serveur WMS. Il suffit d'ajout le paramètre TILED = true et surtout de demander les
données dans une emprise géographique correspondant exactement à celle d'une dalle
(éventuellement de plusieurs).

20
2.3.6.3 WFS
Web Feature Service ou WFS est un protocole décrit dans des spécifications maintenues par
l'Open Geospatial Consortium. Le service WFS permet, au moyen d'une URL formatée,
d'interroger des serveurs cartographiques afin de manipuler des objets géographiques (lignes,
points, polygones...), contrairement au Web Map Service ou WMS qui permet la production de
cartes géoréférencées à partir de serveurs géographiques. Le protocole WFS (Web Feature
Service) permet à un client d'obtenir des entités géographiques vecteurs (géométrie et
sémantique) non cartographiées au moyen d'une simple url normalisée. D’après la figure 1.6,
la spécification WFS définit 5 opérations pour envoyer des requêtes au serveur et obtenir des
informations :
Figure 1.6 : L’application de WFS
La requête GetCapabilities permet de connaître les capacités du serveur et La requête
DescribeFeatureType permet d'accéder à la structure (i.e. les champs) d'une couche proposée
par le service. La requête GetFeature permet quant à elle d'obtenir sous forme d'un flux GML
des entités géographiques ou de livrer des objets (géométrie et/ou attributs) en GML
(Geography Markup Language). La requête LockFeature permet de bloquer des objets lors
d'une transaction. La requête Transaction permet de modifier l'objet (création, mise à jour,
effacer).
2.3.6.4 WCS
Le Web Coverage Service Interface Standard (WCS) de l'Open Geospatial Consortium est un
standard fournissant une interface permettant de télécharger des données de type couverture
(MNT, orthoimages ...) Le protocole WCS (Web Coverage Service) permet à un client
d'accéder à des données géographiques de type grilles, c'est-à-dire à des données qui varient de

21
manière continue dans l'espace géographique. Il peut s'agir par exemple de modèles numériques
de terrain, de données climatiques ou encore socio- économiques. Il ne faut pas confondre ces
données avec celles obtenues sous forme d'image par le protocole WMS. Ce qu'on obtient en
réponse ce n'est pas une image RVB mais bien une grille portant la sémantique des données.
Un serveur WCS doit répondre aux requêtes de GetCapabilities qui renvoie une description du
service, de DescribeCoverage qui renvoie une description complète pour chaque
couverture et de GetCoverage qui renvoie une couverture dans différents formats
2.3.6.5 WPS
Le protocole WPS (Web Process Service) permet à un client d'exécuter un géotraitement, c'est-
à-dire un calcul de nature géographique, distant. C’est une Service de géotraitement permettant
d'exécuter un calcul géographique paramétré (entrée-sortie) distant en invoquant un web
service. Un serveur WPS doit répondre aux requêtes GetCapabilities,DescribeProcess et
Execute .Le traitement en question peut être très simple (calculer la zone des 100m autour d'un
point) ou très complexe (simuler la propagation d'un feu de forêt à partir des conditions initiales
de lieu et de vents). Le protocole existe mais son utilisation reste encore confidentielle.
2.3.7. Les formats de données vectorielles sur le web
Les formats de données vectorielles le plus utilisé sur le web sont les formats GML (Geography
Markup Language), KML (Keyhole Markup Language), GeoJSON (Geographical JavaScript
Object Notation).
Le format GML définit la structure des données géographiques (nature, géométrie, système de
projection et données associées) et représente graphiquement les cartes définie à l’aide d’une
feuille de style XSL. Les données sont véhiculées sous format XML entre le serveur et le client.
Le KML est un langage basé sur le XML, et destiné à la gestion des données géospatiales dans
les logiciels comme Google Earth et Google Maps.
Le format GeoJSON est un format ouvert pour coder les objets géographiques. A la différence
de GML, GeoJSON n’est pas développé par un organisme de normalisation/standardisation
mais par un groupe de développeur sur Internet. Il est Supporté par beaucoup de logiciels et
frameworrk : Openlayers, Leaflet, GeoServer.

22
Partie 2 :
MODELISATION DE
L’APPLICATION

23
Chapitre 3 : ANALYSE ET FORMALISATIONS DES BEOINS
Pour mieux cerner les fonctionnalités du système à mettre en place, il faut d’abord
identifier les différents utilisateurs et leurs interactions avec le système. Il faut aussi identifier
les différentes fonctions que les utilisateurs peuvent accéder. La réalisation du diagramme de
cas d’utilisation permet de montrer les relations qui existent entre les acteurs et les
fonctionnalités du système. La réalisation des diagrammes de séquences permet de représenter
la collaboration entre les acteurs, le système et les objets du point de vue temporelle.
Il faut aussi faire les scénarii des principaux cas d’utilisation pour faire des prévisions des cas
d’utilisation selon certaines hypothèses et contraintes.
3.1 Identification des acteurs
Un acteur est un utilisateur humain, un dispositif matériel ou un système qui interagit
directement avec le système étudié. Il représente un rôle joué par une entité externe au système
donc peut consulter ou modifier directement l'état du système. Il émet ou reçoit des messages
qui sont porteurs de données. Pour mieux cerner les fonctionnalités du système à mettre en
place, il faut d’abord identifier les différents utilisateurs et leurs interactions avec le système.
Les principaux utilisateurs sont les internautes qui sont les bénéficiaires finaux des résultats.
En plus de ces utilisateurs, il faut des gestionnaires de contenu chargé de mettre à jour les
données et il faut aussi un administrateur chargé de controler les mises à jour effectué par le
gestionnaire.
La fonction du premier groupe d’utilisateurs se limite à la consultation des données et à la
localisation des points d’intérêts. Il s'agit du large public ; et est composé d'habitants de la
commune de la ville d’Antananarivo, des visiteurs et touristes ;
Le deuxième groupe, en plus des besoins de consultation, doit pouvoir proposer l'inscription de
points d'intérêt et fait les mises à jour des points d'intérêt dont il est le propriétaire ; Nous les
appelons des gestionnaires de données.
En plus de ces deux types d’utilisateurs, il est nécessaire d'avoir un responsable chargé de la
configuration de la plateforme technique et de l’administration de la base de données. C’est
l’administrateur système. Il a accès à toutes les fonctionnalités. Il valide les contenus et les
mises à jour proposés par les abonnés

24
3.2 Identification des cas d’utilisation
Un cas d’utilisation représente un ensemble de séquences d'actions réalisées par le système et
qui produit un résultat observable intéressant pour un acteur particulier. Un cas d'utilisation
modélise un service rendu par le système. Il exprime les interactions acteurs/système et apporte
une valeur ajoutée « notable » à l'acteur concerné. Il permet décrire ce que le futur système
devra faire, sans spécifier comment il le fera. L'ensemble des cas d'utilisation doit décrire
exhaustivement les exigences fonctionnelles du système. Les cas d'utilisation sont en fonction
des différents acteurs :
Pour les utilisateurs, il s’agit des fonctions standards sur les données géographiques, à savoir :
La navigation (affichage, déplacement, zoom de la carte), La recherche d’information, La
localisation d’un objet sur la carte, La consultation des informations liées à un point d’intérêt,
La recherche d’un point d’intérêt, Le calcul des itinéraires et l’inscription
Pour les gestionnaires de données, en plus des fonctions standards qu’ils auront en tant
qu’utilisateurs du domaine public, pourront également mener les actions comme
l’authentification : en effet, l’utilisation des fonctions d’édition doit être limitée pour éviter les
incohérences de données. Les gestionnaires peuvent en effet ajouter, éditer ou supprimer des
points d’intérêts.
L’administrateur système doit assurer la gestion des utilisateurs. C’est lui qui crée les autres
gestionnaires et leur octroie des droits. Leurs fonctions principales sont la validation les données
d'inscription d'un abonné, L’administration la plate-forme. L’administrateur a aussi le droit
d’ajouter ou supprimer des gestionnaires.
3.3 Diagramme des cas d’utilisation
Le diagramme de cas d’utilisation est une expression du comportement du système (actions et
réactions), selon le point de vue de l’utilisateur. Il décrit le système et les relations entre le
système et l’environnement. Le diagramme de cas d’utilisation permet de délimiter les
frontières du système, d’impliquer les utilisateurs dès les premiers stades du développement. Il
constitue un moyen d’exprimer les besoins d’un système et une base pour les tests fonctionnels.
Le diagramme de cas d'utilisation se compose d'acteurs et des cas d'utilisation. Les traits entre
les cas d'utilisation et les acteurs représentent les interactions.

25
La figure 2.7 ci-dessous représente le diagramme des cas d'utilisation qui constitue une aide à la
spécification des différentes fonctionnalités du système selon les catégories d'utilisateurs envisagés
Figure 2.7: Diagramme de cas d'utilisation
D’après le diagramme de cas d’utilisation ci-dessus ,les acteurs ,les gestionnaires et un
administrateur .Un utilisateurs peut consulter un point d’intérêts, calculer itinéraires ,trouver
des points d’intérêts et les consulter .Un utilisateur peut devenir un gestionnaire s’inscrivant sur
la plateforme .Un gestionnaire peut proposer des modifications qu’il faut apporter à la base de
données et un Administrateur est à son tour charger de valider les modifications proposées par
le gestionnaire et de charger d’ajouter des nouveaux gestionnaires .
3.4 Scénarii des principaux cas d’utilisation
S’authentifier Le tableau 2.1 ci-dessous représente une prévision du cas d’utilisation
« S’authentifier » selon certaines contraintes et hypothèses.

26
Tableau 2. 1 : Scénario du cas d’utilisation « S’authentifier »
Nom du cas S’authentifier
Acteurs Les gestionnaires
Pré conditions Accès à Internet
Actions L’utilisateur saisie son nom d’utilisateur et
son mot de passe et clique sur le bouton «
Valider ». Le système ouvre une nouvelle
fenêtre destinée seulement au gestionnaire.
Post conditions L’utilisateur est authentifié et peut proposer
des points d’intérêt à introduire dans la base
de donné
3.4.1 Naviguer dans la carte
Le tableau 2.2 ci-dessous représente une prévision du cas d’utilisation « Naviguer » en
tenant comptes certaines contraintes et hypothèses.
Tableau 2.2:Scénario du cas d’utilisation « Naviguer »
Nom du cas Naviguer dans la carte
Acteurs Tous les Utilisateurs
Actions L’utilisateur tape le lien du site dans un navigateur internet. Le
système affiche le site avec les outils de navigation.
Déplacement : l’utilisateur clique sur une des flèches (hauts, bas,
gauche, droite) et le système déplace la carte dans le sens de la
flèche.
Post conditions Après le déplacement ou le zoom, la localisation de la carte
change
Zoom+ : l’utilisateur clique sur le bouton plus (+) et le
système fait zoom avant sur la carte à partir du point central
de la partie de carte affichée.
Zoom- : l’utilisateur clique sur le bouton moins (-) et le
système fait zoom arrière sur la carte à partir du point central
de la partie de carte affichée.

27
3.4.2 Rechercher des points d’intérêt
Le tableau 2.3 ci-dessous représente une prévision du cas d’utilisation «Rechercher » en
tenant comptes certaines contraintes et hypothèses comme l’accès internet. Les acteurs de ce
type de cas d’utilisation sont tous les utilisateurs.
Tableau 2.3:Scénario du cas d’utilisation « Rechercher »
Nom du cas Rechercher des informations
Actions L’utilisateur tape le lien du site dans un navigateur internet. Le système
affiche le site avec le formulaire de recherche d’information. Les
critères géographiques :
- par arrondissement
- par fokontany.
-par catégorie
Les critères type d’information :
- Type des points d’intérêts
L’utilisateur choisit les critères de recherche d’informations et clique
sur le bouton « afficher sur la carte ». Le système affiche le résultat
centré sur la carte et les données attributaires sous forme de tableau en
bas de la carte.
Post conditions Le détail sur une donnée est affiché dans une fenêtre. Si le résultat est
vide, alors la zone d’affichage des résultats reste vide
3.4.3 Mise à jour des points d’intérêts
Le tableau 2.4 ci-dessous représente une prévision du cas d’utilisation « Mettre à jour les
données » selon certaines contraintes et hypothèses. Une des principales contraintes est la
possibilité d’avoir un accès à internet.

28
Tableau 2.4 : Scénario du cas d’utilisation « Mètre à jour les données »
Nom du cas Mettre à jour les données
Acteurs Gestionnaire de données
Pré conditions Accès à Internet et authentification terminé
Actions L’utilisateur tape le lien du site dans un
navigateur internet. Le système affiche le
formulaire d’authentification. L’utilisateur
s’authentifie. Le système affiche une
nouvelle fenêtre destinée au gestionnaire
avec les fonctions suivantes :
 Ajouter des points d’intérêts
 Modifier des points d’intérêts
 Supprimer point d’intérêts,
Le gestionnaire va choisir l’une des actions
à faire. Chaque action choisit ouvre une
nouvelle page qui répond à l’action
correspondant.
Post conditions La base de données reste cohérente
3.4.4 Calculer itinéraire
Le tableau 2.5 ci-dessous représente une anticipation du cas d’utilisation « Calculer
itinéraire» en tenant comptes certaines contraintes et hypothèses.
Tableau 2.5 : Scénario du cas d’utilisation « calculer itinéraire »
Nom du cas Calculer itinéraire
Actions L’utilisateur clique un point de départ et un
point d’arriver. Le système récupère les
coordonnées des points cliqués et calcule
automatiquement le chemin le plus court et
affiche le résultat sur la carte

29
3.4.1 Gérer les membres
Le tableau 2.2 ci-dessous représente une prévision du cas d’utilisation « Administrer» en
tenant comptes certaines contraintes et hypothèses. L’acteur de ce type de cas d’utilisation est
l’administrateur du système.
Tableau 2.6 : Scénario du cas d’utilisation « Administrer »
Nom du cas Administrer
Acteurs Administrateur
Action L’administrateur doit connecter en tant
qu’administrateur.
Post conditions L’administrateur peut consulter la liste de
toutes les gestionnaires inscrits sur la
plateforme. L’administrateur peut aussi
ajouter modifier ou supprimer des
gestionnaires en cliquant sur le bouton qui
correspond à chaque action souhaité .Il peut
aussi envoyer des emails à tous les
gestionnaires.
3.5 Quelques digrammes de séquences
Nous complétons la description des cas d'utilisation identifiés par les diagrammes de séquences.
Les diagrammes de séquences permettent de représenter la collaboration entre les acteurs, le
système et les objets du point de vue temporelle. Il permet de représenter des échanges entre les
différents objets et acteurs du système en fonction du temps. Dans son élaboration, on met en
exergue la chronologie de l'envoie des messages. Nous présentons les diagrammes de séquences
de quelques cas d'utilisation
3.5.1 « Rechercher »
La figure 2.8 ci-dessous représente le diagramme de séquence su cas d’utilisation « rechercher »

30
Figure 2.8: Diagramme de séquences du cas d'utilisation : Rechercher
Ce diagramme de séquence explique la description du cas d’utilisation « rechercher un point
d’intérêt ». Ce diagramme explique les échanges entres les internautes qui sont les acteurs, les
clients (les navigateurs web et les applications cartographiques), les serveurs web et les serveurs
des données. L’internaute peut effectuer des recherches et communique au client à l’aide des
listes déroulantes multicritères que le client possède. A son tour, le client va communiquer avec
le serveur web par l’intermédiaire d’une interprétation des éléments que l’internaute veut
rechercher. Le serveur web va connecter à la base de données que le serveur de données
possède. Le serveur web exécute une requête SQL en fonction des éléments fournis par
l’internaute et transmet le résultat de la requête au serveur web qui interprète ce dernier. Les
clients qui sont composé par des navigateurs et les applications cartographiques affichent le
résultat de la requête par l’interprétation réponses que le serveur de web à envoyer. Les
utilisateurs peuvent alors consulter les résultats de la recherche que les clients affichent. Cette
opération peut se répéter plusieurs fois que les internautes désirent.

31
3.5.2 Calculer itinéraire
La figure 2.9 ci-dessous représente le diagramme de séquence su cas d’utilisation « Calculer
itinéraire »
Figure 2. 9: Diagramme de séquences du cas d'utilisation : Calculer itinéraire
Ce diagramme de séquence explique la description du cas d’utilisation « calculer itinéraires ».
Ce diagramme explique aussi les échanges existant entres les utilisateurs, les clients, et les
serveurs cartographiques. Les utilisateurs émettent un message au les clients (navigateurs,
operateurs cartographique) après avoir cliqué sur un point de départ et un point d’arriver qui
déclenche la procédure de calcul d’itinéraires. Les clients envoient les coordonnées des deux
points cliqués par l’internaute au serveur cartographique et attendent une réponse. Le serveur
cartographique effectue une requête à l’aide des algorithmes de routages qui sont déjà
configurés dans le serveur. Cette requête ou calcul d’itinéraire se base essentiellement sur les
coordonnées des deux points cliqués sur la carte. Après avoir terminé le calcul d’itinéraire, le
serveur de données transmet la réponse au client qui à son tour affiche le résultat avec des
marques qui indiquent la position du point de départ et du point d’arriver. Cette opération peut
se répéter dès que les utilisateurs cliquent à nouveaux sur deux points distincts.

32
3.5.3 S’Authentifier
La figure 2.10 ci-dessous représente le diagramme de séquence su cas d’utilisation
« Authentifier »
Figure 2.10: Diagramme de séquences du cas d'utilisation : Authentifier
Ce diagramme représente des échanges entre les l’internaute, le client et le serveur de données
dans le cas d’utilisation « authentifier. L 'internaute se communique avec le client par le
remplissage des formulaires d’inscription et des formulaires d’authentification que les clients
possedent.la relation entre les clients et les serveurs de données résident dans le fait que les
clients envoi les informations que l’internaute a saisies au serveur de données qui est capable
de vérifier l’exactitude de ces informations. C’est le serveur de données qui contrôle les
identifiants des internautes afin de s’authentifier. Si les identifiants que l’internaute ne
correspond pas à l’information dans base de données, alors l’authentification est refusée.

33
3.5.4 Mettre à jour les données
La figure 2.11 ci-dessous représente le diagramme de séquence su cas d’utilisation « Mise
à jour des données »
Figure 2.11: Diagramme de séquences du cas d'utilisation : Mettre à jour les données
Ce diagramme explique les échanges entres les objets (client, serveur de données,
administrateur) et les acteurs (internaute) dans le cas d’utilisation « mise à jour des données.
Après avoir authentifié, l’internaute se communique avec le client par le choix des actions à
faire afin de faire une mise à jour des données. Le client se communique avec le serveur des
données par une requête qui affiche les listes des données qu’on peut mettre à jour. L’internaute
va choisir à l’aide de cette liste les données qu’il modifier ou supprimer ou même ajouter une
nouvelle donnée et effectue ensuite la mise à jour. Cette mise à jour des données est contrôlée
par l’administrateur. Chaque modification ou suppression, ou ajout des nouvelles données
requiert toujours une autorisation venant du gestionnaire.

34
Chapitre 4 : ETUDE CONCEPTUELLE
Ce chapitre consiste à mettre en place et à préciser la démarche et les concepts nécessaires
qu’on va utiliser pour construire une base de données cohérente dans notre projet. L'étude
conceptuelle nous permet d'établir un schéma conceptuel des données de traitement lesquelles,
constituent une base de référence stable indépendante de tout matériel ou logiciel de
base. L'étude conceptuelle est aussi un processus qui consiste à définir des principes de gestion,
aboutissant à des modèles conceptuels de données et de traitements. L'étude conceptuelle se
définit généralement comme une étude de premier niveau et d'évaluation préliminaire d'un
projet. L'étude conceptuelle a pour but de développer les caractéristiques essentielles de la
solution à émerger, de grossir la solution retenue lors de l'étude d'opportunité et de décrire les
principes des solutions indépendamment de moyens utilisés.
4.1 Méthode utilisée pour la conception des bases de données
Nous avons utilisé la méthode MERISE pour cette partie. La méthode MERISE est donc une
méthode d'analyse et de conception des systèmes d’informations basée sur le principe de la
séparation des données et des traitements. Elle possède un certain nombre de modèles qui sont
répartis sur 3 niveaux : Le niveau conceptuel, Le niveau logique et Le niveau physique
Le niveau conceptuel correspond à la définition des finalités de l'application en expliquant sa
raison d'être. Ce niveau traduit les objectifs et les contraintes qui pèsent sur l'Application.
Le niveau organisationnel permet de définir l'organisation qu'il est souhaitable de mettre en
place pour atteindre les objectifs visés. Le modèle logique représente un choix du logiciel pour
le système d'information
Le niveau physique qui reflète un choix du matériel pour le système d'information
4.2 Mise en œuvre de la méthode choisie
Pour mettre en œuvre cette méthode, les différents niveaux suivants sont à parcourir : tout
d’abord, la création du dictionnaire des données ; ensuite, l’élaboration du Modèle Conceptuel
de Données (MCD) ; puis, le Modèle Logique de Données (MLD) ; et enfin, le modèle physique
des données.

35
4.2.1 Création du dictionnaire de données
Un dictionnaire des données est une collection de métadonnées ou de données de référence
nécessaire à la conception d'une base de données relationnelle. Il revêt une importance
stratégique particulière, car il est le vocabulaire commun de l'organisation. Il décrit des données
aussi importantes que les clients, les nomenclatures de produits et de services, les annuaires,
etc. C'est donc le référentiel principal de l'entreprise, sur lequel s'appuient les décisions de celle-
ci. Il est souvent représenté par un tableau à quatre colonnes contenant le nom, le code et le
type de donnée ainsi que des commentaires.
Pour recueillir les informations nécessaires à la réalisation du projet, des séances d’entretiens
ont été faites. Ensemble, ces informations forment le dictionnaire des données. Le tableau
Tableau 2.7 suivant représente un extrait du dictionnaire des données de ce projet :
Tableau 2.8:Extrait du dictionnaire des données
Champs retenus Types de données Commentaires
Id_commune Serial Code géographique de la commune
Nom_commune Caractère (50) Toponymie de la commune
Id_loca Serial Code géographique de la localité.
Nom_loca Caractère (50) Nom des localités.
Id_membre Serial Identifiant du membre
Email Caractère (50) Email du membre
Nom Caractère (50) Nom du membre qui veut être inscrit
Nom_point_int Caractère (50) Nom du point d’intérêts
Id_point_int Numérique Identifiant du point d’intérêts
Type_point_int Caractère (20) Type du point d’intérêts public ou privé
4.2.2 Le modèle conceptuel des données
Le modèle conceptuel de données (MCD) a pour but d'écrire de façon formelle les données qui
seront utilisées par le système d'information. Il s'agit donc d'une représentation des données,
facilement compréhensible, permettant de décrire le système d'information à l'aide d’entités.

36
La figure 2.12 suivante représente un extrait du modèle conceptuel de donnée du projet.
Figure 2.12 : Le modèle conceptuel de donnée
Le MCD ci-dessus est une illustration simplifiée du MCD réalisé pour le prototype de
l’application. Il montre les relations existant entre l’ensemble des données. Un lieu d’intérêt
peut être formé par l’une des points suivants : Hôtel, restaurant, pharmacie, universités, école,
lycée, banque, station de service, garage, sanitaire … Un secteur possède une ou plusieurs
points d’intérêts. Un arrondissement possède plusieurs secteurs et un arrondissement est
possédé par une commune. Parallèlement, un lieu d’intérêt est contrôlé par une ou plusieurs
gestionnaires qui sont à son tour contrôlé par un administrateur.

37
4.2.3 Conception du modèle logique des données
La modélisation logique des données est une représentation des données, issues de la
modélisation conceptuelle des données. Il permet de déterminer les clés étrangères et les
requêtes. Il consiste donc en deux étapes : supprimer les relations complexes pour les
transformer en table à part entière d'une part, et de trouver les clés étrangères d’autre part. La
clé étrangère est formée d’un ou plusieurs attributs permettant de relier la clé primaire d’une
table. La figure 2.13 suivante représente un extrait du modèle logique de donnée du projet.
Figure 2.13: Modèle logique des données

38
4.2.4 Modèle Physique des Données
Cette étape consiste à implémenter le modèle dans le SGBD, c'est-à-dire le traduire dans un
langage de définition de données. Le langage généralement utilisé pour ce type d'opération est
le SQL, et plus spécialement le langage de définition de données du SQL. Le modèle physique
de données, MPD, est une représentation de l’organisation des données tenant compte d’un
système de gestion des données retenu, la plupart du temps un SGBDR sous forme de tables
comportant des colonnes (ou champs).la structure en tables et colonnes du modèle relationnel
est conservée, mais on va y ajouter les types de données de chacune des colonnes. Ces types de
données vont varier pourront être différent d’un SGBD à un autre. Les clefs primaires sont
soulignées. Elles matérialisent les contraintes d’intégrité d’identité des tables, que le SGBDR
devra contrôler. Les clefs étrangères sont représentées graphiquement par une flèche orientée,
de la table qui contient la colonne clef étrangère vers la table qu’elle référence. La figure 2.14
suivante représente un extrait du modèle physique de donnée du projet.
Figure 2.14 : Modèle physique des données

39
4.2.5 Génération d'un script de base de données
On peut générer une base de données directement à partir d'un modèle physique de données, ou
bien générer un script de base de données qu’on peut exécuter dans l’environnement de SGBD.
Les paramètres de génération disponibles dépendent du SGBD cible sélectionné. Analyse SI
(Logiciel libre) peut générer des scripts SQL sophistiqués sous la forme de fichiers ou pour une
exécution immédiate via une connexion directe à une base de données. On peut également
sélectionner ouvrir le script dans un éditeur afin de le parcourir et de l'éditer avant son
exécution. La génération de la base de données au format SQL standard donne le code de la
figure 2.15 suivante:
/*==============================================================*/
/* Table: HOTEL */
/*==============================================================*/
create table HOTEL (
NOM_HOTEL VARCHAR(50) not null,
NOM_SECTEUR VARCHAR not null,
ID_HOTEL NUMERIC(20) null,
NOMBRE_D_ETOILE NUMERIC null,
NOMBRE_DE_CHAMBRE NUMERIC null,
ADRESSE_GEST VARCHAR(50) null,
ATTRIBUTE_59 CHAR(10) null,
ATTRIBUTE_60 CHAR(10) null
primary key (ID_HOTEL)
);
-- ============================================================
-- Index : HOTEL_PK
-- ============================================================
create unique index HOTEL_PK HOTEL (ID_HOTEL);
/*==============================================================*/
/* Table: MARCHE */
/*==============================================================*/
create table MARCHE (
NOM_MARCHE VARCHAR(20) not null,
NOM_SECTEUR VARCHAR not null,
ID_MARCHE NUMERIC(10) null,
TYPE_MARCHE VARCHAR(20) null,
ADRESSE_MARCHE VARCHAR(50) null
primary key (ID_MARCHE)
);
- ============================================================
-- Table : RESTAURANT
-- ============================================================
create table RESTAURANT
(
ID_RESTO INTEGER not null,
NOM_RESTO CHAR(32) not null,
ADRESSE_RESTO VARCHAR(25) ,
CONTACT_RESTO VARCHAR(100) ,
SPECIALITE VARCHAR(100)
primary key (ID_RESTO )
);
Figure 2.15 : Extrait du script de la base de données

40
Chapitre 5: ETUDE TECHNIQUE
Dans ce chapitre, on va faire des comparaisons entres les logiciels libres et faire une analyse
sur les langages afin d’assurer le meilleur fonctionnement du système.
5.1 Choix des logiciels
Pour la réalisation de l’interface webmapping, nous avons choisi les solutions OpenSource. Ils
permettent une indépendance non seulement vis-à-vis des logiciels car utilisant des formats et
des protocoles ouverts mais aussi des fournisseurs par la disponibilité du code source. La
disponibilité du code source permet à des milliers de développeurs de le vérifier en permanence,
améliorant ainsi la fiabilité et la sécurité de ces logiciels.
5.1.1. Serveur cartographique
Parmi les logiciels OpenSource Mapserver et GeoServer sont les plus utilisés comme serveurs
cartographiques.
5.1.1.1. Geoserver
GeoServer est un serveur web qui permet de servir des cartes et des données depuis une variété
de formats, des clients standards web ou bureautique jusqu’aux programmes SIG avancés. Cela
signifie que vous pouvez stocker vos données spatiales dans presque n’importe lequel de vos
formats préférés mais aussi que vos utilisateurs n’ont pas besoin de savoir exactement ce que
sont des données SIG. Au niveau le plus basique, tout ce dont ils ont besoin est un navigateur
web pour voir les cartes comme vous voulez.
GeoServer est l’implémentation de référence de l’Open Geospatial Consortium (OGC) pour les
standards Web Feature Service (WFS) et Web Coverage Service (WCS), ainsi qu’un serveur
haute performance certifié conforme au Web Map Service (WMS). GeoServer forme un des
composants essentiels du web géospatial. La donnée est servie comme des images simples et
rapides en utilisant le protocole WMS. Les données vecteurs complètes peuvent être envoyées
au client en utilisant le protocole WFS. Les valeurs des données raster peuvent être renvoyées
à un client en utilisant le protocole WCS. GeoServer supporte la majorité des projections de la
base de données EPSG et peut reprojeter les données dans n’importe laquelle d’entre elles à la
demande pour permettre aux clients avec un support limité pour la reprojection de basculer cette
charge au serveur.

41
5.1.1.2. Mapserver
MapServer est un programme CGI qui s’exécute donc sur un serveur web. En quelques mots,
son rôle consiste à piocher dans des bases de données et autres ressources afin de générer des
images de type matriciel, qui seront transmises à un client par l’intermédiaire d’un serveur web
C'est le serveur de carte historique utilisé par les premières applications de webmapping. Il a
d'abord servi à produire des cartes à la demande au format image. Il a ensuite évolué pour
permettre également la publication de services web conformes aux normes OGC.
Le serveur est utilisable sous deux formes dont le première forme est une application CGI
(Common Gateway Interface) exécutable à distance par le biais d'une url et la deuxième
forme est une API MapScript utilisable dans plusieurs environnements de développement
serveur (PHP, Perl, Python, Java,).Son rôle principal est de produire des cartes dynamiques à partir
de données stockées dans différents formats (shapefiles, tables Mapinfo, tables de SGBD spatial).
Chaque service de carte utilise un fichier texte, dit mapfile, décrivant le contenu.
5.1.1.3. Comparaison entre Mapserver et Geoserver
Le tableau 2.8 suivant montre les comparaisons entre Mapserver et Geoserver afin de choisir un serveur
cartographique qui est le plus adapté au systeme.
Tableau 2.9 : Comparaison entre Mapserver et Geoserver
Points forts Points faible
MapServer -Grande richesse fonctionnelle
-Grande maturité
-Forte communauté
-nombreuses fonctionnalités
-forte nécessité de développement
- installation difficile
-Pas d’interface d’administration
GeoServer -Grande richesse fonctionnelle
-Grande maturité
-Forte communauté
- Pas d’interface d’administration
-Facilité d’utilisation à travers une
interface graphique
-Environnement de développement Java

42
Les deux serveurs cartographiques s’équivalent par les possibilités qu’ils offrent dans la
publication des données spatiales sur Internet. Mais Geoserver est plus facile à utiliser à travers
une interface graphique C’est pourquoi notre choix s’est porté sur Geoserver comme serveur
cartographique.
5.1.2. Client cartographique
Les applications clientes sont des bibliothèques JavaScript qui permettent de gérer le chargement
des couches produites par le serveur cartographique (WFS, WFST, WMS, KML),et d’ afficher
les données d’une base de données géo spatiales (PostGis) ou de simples couches (SHP).Le client
cartographique gère également l’envoi des données aux serveurs et les interactions HOMME
MACHINE (Zoom sur une couche, déplacement, mesure de longueur). Le choix du client
cartographique est d’autant plus important qu’il représente le lien entre l’utilisateur et le serveur.
Il existe de nos jours plusieurs applications clientes. Nous avons décidé d’analyser les principales
d’entre elles afin de sélectionner la plus adaptée à nos besoins.
Le tableau 2.9 suivant montre les comparaisons entre OpenLayers et Leaflet permettant de choisir un
client cartographique le plus adapté au besoin.
Tableau 2.10:comparaison entre Openlayers et Leaflet
Points forts Points faibles
Leaflet - Bonne documentation
- Présentation graphique
harmonieuse
- Légèreté
Absence de possibilité de filtrage
par
les attributs
OpenLayers -Bonne documentation
- Présentation graphique
harmonieuse
- Beaucoup de fonctionnalités
- Grande popularité
Bibliothèque lourde
Pour la réalisation de cette étude, on va utiliser OpenLayers version 3 qui est un logiciel libre,
publié sous licence BSD. Il constitue une bibliothèque de fonctions JavaScript assurant un noyau
de fonctionnalités orienté vers la mise en place d'applications clientes Web cartographiques
fluides. OpenLayers permet d'afficher des fonds cartographiques tuilés ainsi que des marqueurs

43
provenant d'une grande variété de sources de données. Une partie de cette bibliothèque permet
aussi de gérer l'ergonomie proposée à l'utilisateur, mais ce n'est pas directement son rôle.
5.1.3. Serveur de données : PostgreSQL/Postgis
Pour la réalisation de ce projet, nous avons choisi PostgreSQL/Postgis comme serveur de
données. PostgreSQL est un puissant système de gestion de données relationnel à objets
(SGBDRO). Il a été publié sous la licence de style BSD et est donc un logiciel libre. Comme
avec beaucoup de logiciels libres, PostgreSQL n’est pas contrôlé par une société unique mais
par une communauté de développeurs et de sociétés qui le développe. Ce SGBDRO utilise des
types de données modernes, dit composés ou enrichis suivant les terminologies utilisées dans
le vocable informatique usuel. Ceci signifie que PostgreSQL peut stocker plus de types de
données que les types simples traditionnels entiers, caractères, etc. L'utilisateur peut créer des
types, des fonctions, utiliser l'héritage de type, etc. PostgreSQL est plus avancé que ses
concurrents dans la conformité aux standards. Il fonctionne sur diverses plates-formes
matérielles et sous différents systèmes d'exploitation.
PostGIS confère au système de gestion de base de données PostgreSQL le statut de base de
données spatiale en ajoutant les trois supports suivants : les types de données spatiales, les index
et les fonctions. Étant donné qu’il est basé sur PostgreSQL, PostGIS bénéficie automatiquement
des capacités orientées “entreprise” ainsi que le respect des standards de cette
implémentation.De nombreuses applications professionnelles sont construites sur PostgreSQL
qui reste le système de gestion de bases de données relationnelles le plus accompli dans le
domaine du libre.
5.1.4. Serveur web : Apache
Nous avons choisi Apache HTTP Server, comme serveur web qui est un logiciel permettant à
des clients d'accéder à des pages web.
Le logiciel libre Apache HTTP Server (Apache) est un serveur HTTP créé et maintenu au sein
de la fondation Apache. C'est le serveur HTTP le plus populaire du World Wide Web. Il est
distribué selon les termes de la licence Apache. Il s'agit d'une application fonctionnant à la base
sur les systèmes d'exploitation de type Unix, mais il a désormais été porté sur de nombreux
systèmes, dont Microsoft Windows. Apache est conçu pour prendre en charge de nombreux
modules lui donnant des fonctionnalités supplémentaires : interprétation du langage Perl, PHP,

andrianomenjanaharyDinaHM_ESPA_MAST2_17.pdf

andrianomenjanaharyDinaHM_ESPA_MAST2_17.pdf

Recommandé

Recommandé

Contenu connexe

Similaire à andrianomenjanaharyDinaHM_ESPA_MAST2_17.pdf

Similaire à andrianomenjanaharyDinaHM_ESPA_MAST2_17.pdf (20)

Dernier

Dernier (20)

andrianomenjanaharyDinaHM_ESPA_MAST2_17.pdf