Rapport du stage « Stage Ingénieur »

Année universitaire 2011/2012

Filière Sciences de l’Information Géographique (SIG)

Réalisé par : Encadré par :

Faiçal OUDBIB Mr. Mohamed ECHTIOUI

Mr. Jaouad Ibn TATTOU

 Sommaire
Listes des figures ..................................................................................................................................... 3
Remerciements ................................................................................................................................... 5
Introduction générale.......................................................................................................................... 6
Chapitre I : ............................................................................................................................................... 7
1. Présentation de l’organisme ........................................................................................................... 8
1.1. Présentation générale : ........................................................................................................... 8
1.2. Chiffres clés ............................................................................................................................. 8
Chapitre II : ............................................................................................................................................ 10
2. Identification du besoin :............................................................................................................... 11
2.1. Réunions préparatoires : ....................................................................................................... 11
3. Les ressources :.............................................................................................................................. 13
3.1. les fichiers : ............................................................................................................................ 13
3.2. les logiciels : ........................................................................................................................... 14
Chapitre III : ........................................................................................................................................... 15
4. Etude fonctionnelle : ..................................................................................................................... 17
4.1. Description détaillée des cas d’utilisation : ........................................................................... 18
5. Etude technique : .......................................................................................................................... 22
Chapitre IV : ........................................................................................................................................... 23
6. Analyse du fichier « PLM TFZ_pfi » : ............................................................................................. 24
7. Digitalisation d’un fichier polygone à la base de « PLM TFZ_pfi » : .............................................. 32
Chapitre V : ............................................................................................................................................ 34
8. Les outils choisis : .......................................................................................................................... 35
9. Préparation des outils ................................................................................................................... 38
10. La programmation de notre application : ................................................................................. 44
Annexes ................................................................................................................................................. 54
Première étape : installation d’OpenGeo Suite .................................................................................... 55
Deuxième étape : déploiement de l’application. .................................................................................. 63
Recommandations :............................................................................................................................... 66

2
 Listes des figures

Fig 1 : Sociétés installées par année

Fig 2 : Investissements par année en DH

Fig 3 : Emplois prévus

Fig 4 : Cas d’utilisations

Fig 5: diagramme de séquence du cas d’utilisation « Consulter les attributs d’un lot »

Fig 6: diagramme de séquence du cas d’utilisation « Editer les attributs d’un lot»

Fig 7: diagramme de séquence du cas d’utilisation « Requête»

Fig 8 : diagramme de séquence du cas d’utilisation « création d’un nouveau lot»

Fig 9 : architecture de l’application

Fig 10 : architecture de l’application

Fig 11 : plan masse de la TFZ

Fig 12 : plan masse de la TFZ

Fig 13 : Icône de PostGIS

Fig 14 : Icône de GeoServer

Fig 15 : Icône d’OpenLayers

Fig 16 : Icône de GeoExt

Fig 17 : interface de démarrage d’OpenGeo

Fig 18 : l’uploader de fichier « .shp » de PostGIS

Fig 19 : l’interface de PostGres

Fig 20 : Exemple d’une table de PostGis

Fig 21 : page d’administration de GeoServer

3
Fig 22 : ajout d’une nouvelle ressouce sur GeoServer

Fig 23 : connecter GeoServer à PostGis

Fig 24 : système de projection et emprises sous GeoServer

Fig 25 : visualisation de la ressource sous GeoServer

Fig 26 : console pour la commande create

Fig 27 : console pour la commande debug

Fig 28 : fond openstreetmap de notre application

Fig 29 : commande de debuggage

Fig 30 : couche « foncier » de la TFZ

Fig 31 : les dépendances requises pour notre fichier .js

Fig 32 : ajout d’outils dans notre application

Fig 33 : pop-up avec information sur le lot

Fig 34 : tableau d’affichage des lots et modules de requête

Fig 35 : consultation d’informations d’un lot.

Fig 36 : exemple d’édition d’un lot.

Fig 37 : exemple de requête rendant « Etat_viabi = ‘Oui’ », donc lots viabilisés.

Fig 38 : exemple de requête avec lot viabilisé appartenant à la tranche 2.

4
 Remerciements

Je remercie Mr Jaouad IBN TATTOU, Directeur à la Direction du Patrimoine Foncier à Tanger

Med et qui me fit preuve de la plus grande gentillesse et disponibilité malgré l’occupation et les
contraintes de travail.

Je remercie Mr Mohammed ECHTIOUI, Directeur de la Direction Système d’Information à la

TFZ (Tanger Free Zone), pour son aide et son orientation.

Je remercie Mlle Imane AGZENNAY, Directrice du Service Commercial à la TFZ, pour ses
explications, sa convivialité.

Je remercie mon père, Mr Mohammed OUDBIB, pour sa révision de ce document et ses

corrections et suggestions.

5
 Introduction générale

L’Agence Spéciale Tanger Méditerranée (TMSA) est chargée de l’aménagement, du

développement et de la gestion du complexe portuaire Tanger Med et de la plateforme industrielle
qui lui est adossée.

Tanger Free Zone (TFZ) – qui fait partie du groupe TMSA- accompagne l’exploitation du
complexe portuaire Tanger Med à travers la mise en service des zones d’activités tertiaires et
logistiques de l’enceinte du complexe portuaire. Il devrait en résulter le développement d’un arrière-
pays du port, une concentration d’industries, une favorisation de la création d’emploi et la gestion
d’immobilier servant pour l’installation des investisseurs. Un grand tout donc, dédié à la promotion
de l’activité tertiaire et industrielle à travers un pôle dénommé Grande Plateforme Industrielle (GPI).

Face à l’énormité de la surface couverte par la TFZ, un SIG se devait de voir le jour pour une meilleure
gestion des zones d’activités dans leur aspect procédural et géographique ainsi que pour
l’établissement d’un SI qui organise et diffuse les flux d’information en interne et externe.

Dans mon Stage Ingénieur, ma tâche – pour ne pas parler de tâches- était la prise de connaissance
avec l’environnement professionnel dans lequel je devais m’intégrer, comprendre les attributions de
la direction de système d’information, me rapprocher des contraintes organisationnelles,
fonctionnelles, financières et techniques qui y sont liés. Dans ce stage, j’ai aussi essayé de mettre en
œuvre la méthodologie d’un ingénieur SIG qui évolue en quatre étapes clés :

 Appréciation du contexte général,

 Etude préliminaire,
 Analyse et conception,
 Réalisation.

6
 Chapitre I :

« Contexte général du Stage »

Dans ce chapitre, il s’agit de présenter l’organisme d’accueil et de mettre le stage dans son cadre
général en termes d’objectifs, d’avantages, de ressources et de planification.

7
 1. Présentation de l’organisme
1.1. Présentation générale :

Créée en 1999, la Zone Franche d’Exportation de Tanger, est le plus important pôle
d'activités de la région. Ingénierie informatique, industries automobile et aéronautique,
menuiserie aluminium, textile, mécanique, formation, ... 475 entreprises de toutes
tailles issues d’investissements étrangers en provenance de l’Union Européenne, Etats-
Unis d’Amériques ; le Maghreb et le Moyen-Orient y concentrent une trentaine
d'activités différentes. Par ailleurs, la Zone Franche de Tanger, gérée par la société TFZ,
qui fait partie du groupe TMSA, offre des avantages fiscaux très attractifs.
Si la vocation industrielle de ce pôle est nettement marquée, Tanger Free Zone « TFZ »
s'est toujours refusée en revanche à la venue d'industries polluantes. Au côté de
sociétés installées depuis sa création, la zone industrielle accueille régulièrement de
nouvelles entreprises attirées par sa dynamique, son positionnement et les
opportunités qu’elle offre.

Autour de la TFZ, qui est développée sur une superficie de 500 hectares, c’est toute une
zone d’environ 60 Ha qui sera dédiée à l’automobile, la Tanger Auto motive City qui est
en cours de réalisation et qui accompagnera le développement de l’usine Renault à
Mellousa. Un pôle qui viendra compléter le réseau de zones franches et industrielles de
la région et qui comprend les deux zones logistiques portuaires de Tanger-Med. Toutes
sont à moins de 30 minutes du Port Tanger Med, plate-forme vers l’Europe située sur la
rive sud du détroit de Gibraltar.

1.2. Chiffres clés

Tanger Free Zone ce sont :

 500ha
 10 ans d’activité
 475 entreprises installées au 31/12/2009
 47 000 emplois directs créés en l’espace de 10 ans
 6 milliards MAD d’investissements réalisés

8
 Fig 1 : Sociétés installées par année

Fig 2 : Investissements par année en DH

Fig 3 : Emplois prévus

9
 Chapitre II :

« Etude préliminaire et perspective d’actions »

Dans ce chapitre, il s’agit de présenter l’identification d’un(s) besoin(s), les ressources déployées
ainsi que la nature de l’action entreprise pour répondre au(x) besoin(s).

10
 2. Identification du besoin :
2.1. Réunions préparatoires :

Réunion 1 :

Après réunion avec Mr Jaouad Ibn Tattou, Directeur du Patrimoine Foncier à TMSA, et
ce le 19/07/2012, la nature de mon action commença à prendre forme.

Lors de cette entrevue de trois heures, Mr le Directeur du Patrimoine foncier avait eu

l’amabilité de me retracer un historique du projet Tanger Med, avec les aspirations
sociaux-économiques conjuguées à la démarche financière, managériale et foncière.

C’est dans cette progression historique que les besoins de mon intervention venaient
se faire naturels. Sans avoir à citer tous les détails, le projet manifeste un large besoin
d’accès à des systèmes d’informations qui peuvent bénéficier d’être géographiques. De
tels systèmes accueilleraient des couches d’informations relevant notamment du
foncier et de l’assiette foncières, des statuts parcellaires. La gestion des ventes et
concessions des territoires s’en ressentirait positivement.

En gros, on se baserait sur plusieurs documents et fichiers pour ressortir une

« intelligence géographique » de la gestion territoriale –avec, ultimement, des
répercussions managériales- . Ces documents s’énuméreraient –non exhaustivement-
comme suit :

 Plan de masse de la zone.

 Limites de la zone sous-douane (zone franche, TFZ pour mon stage).
 Tableau Excel qui renseigne sur :
- L’état d’avancement de la commercialisation.
- L’état d’avancement de la viabilité des lots.
- Les dates de réception.
- Les tranches/Phases.
 Limites et tranches.
 Statut des terrains commercialisés.
 Sociétés installées avec leurs types d’activités et nombre d’emplois directes.
 Scan des contrats.
 Image satellitaires.

Cette masse d’informations devrait être traitée, synthétisée :

11
 - Les plans de masse : à exporter vers les formats ESRI les fichiers Microstation, tenir
en compte les altérations susceptibles, les corrections géométriques ; bref : veiller
sur la justesse technique de cette exportation.
- Les statuts des lots et informations relatives : comprendre la chaîne de progression
qu’un lot doit passer avant d’être commercialisable et commercialisée, gérer la post-
commercialisation. Résumons : une gestion de l’assiette foncière sur plusieurs
niveaux, distinguer les parcelles ou lots :
a/ non viabilisés,
b/ stock,
c/ lots commercialisés,
d/ zone sous douane.
(à compléter et préciser. Recourir à un langage ou méthode de conception pour
schématiser et comprendre).

Réunion 2 :

Rencontre, le 20/07/2012, avec Mlle Imane AGZENNAY, responsable commerciale de TFZ. Cette
rencontre –suggérée par Mr. Jaoud Ibn Tattou – avait pour but l’introduction aux divers aspects de
commercialisation des lots, ceci serait une étape vers l’extraction des statuts de ces lots.

Il s’est avéré que, en premier lieu, un client doit s’adresser à la TFZ et déclarer son activité et ses
besoins (en surface notamment). Les besoins peuvent par suite trouver satisfaction en deux formes :

- Achat,
- Location.

La grande majorité des clients recourent à des achats, qui forment ainsi une partie importante des
transactions agissant sur le patrimoine foncier.

Cette procédure d’Achat se déroule comme suit :

 1 : Suggestion d’un lot.

 2 : Le client adopte ou rejette, il doit choisir un lot.
 3 : Vente directe ou, sinon, compromis de vente.
 4 : Dans le cas de vente directe la TFZ prépare les documents suivants :
- Plans parcellaires de topo.
- Dossier technique cadastral.
- Contrat de vente.

Jusqu’à présent, cette chaîne est manuelle et archivée dans des fichiers Excel. Il s’agit donc aussi,
possiblement, de faire accompagner sa gestion d’un outil d’aide cartographique tout en permettant
la modification et actualisation.

Quant aux attributs qui étaient jugés importants de la part de Mlle la Responsable, il serait ceux du :

 Nom de la société,

12
  Activité de la société,
 Num lot,
 Surface du lot.

Réunion 3 :

Le lundi 23/07/2012, Mr Jouad Ibn Tattou me communique les quelques fichiers nécessaires pour
engager mes actions stagiaires. Ces fichiers seront détaillés dans la partie « Ressources ».

Conclusion : les doublets besoin/actions :

A ce point, un premier besoin était identifié est qui consiste en :

Besoin Actions
Calcul du solde foncier - Exporter en format ESRI les
fichiers DWG,
- Isoler chaque lot en un
polygone,
- Avoir soin de passer en attributs
le numéro du lot, son titre (si
existant)
Reconnaître Solution webmapping avec outils de requêtage
cartographiquement/attributairement les lots et de sélection.
appartenant à des catégories (valorisé,
commercialisé, etc.)
Faire émerger une statistique du patrimoine
foncier

3. Les ressources :
3.1. les fichiers :

Nom du fichier Son extension Son contenu

historique foncier TFZ Dwg
Plan masse TFZ V02 Bak
Plan masse TFZ V02 Dwg Plan de masse non actualisé (toutefois
plus actualisé que le plan masse
TFZ.dwg).
Plan masse TFZ Dwg Plan masse non actualisé.
PLM TFZ_pfi Dwg Plan de masse le plus actuel.
Mentionne les ilots et lots, des titres
fonciers, des routes, etc.
Situation des lots de TFZ Xls Mentionne :
- Bâtiment,
- Ilot,

13
 - Lot,
- Superficie,
- Zone,
- Nature,
- Date de démarrage
des travaux.
Situation du stock _ lots au Pdf Se référer au .dwg correspondant.
23_05_2012
Situation du stock_ lots au Dwg Plan de situation du stock au
23_05_2012 23/05/2012. Comporte les clôtures :
- définitive,
- provisoire,
- projetée.
Stock TFZ_tranche 3 au 31 Pdf Plan de situation des lots viabilisés en
12 2012 stock au 31/12/2011

3.2. les logiciels :

- ArcGIS Desktop.
- Autodesk.
- La suite OpenGeo.

14
 Chapitre III :

« La conception »
Dans ce chapitre, il s’agit de présenter les étapes de la réalisation de l’application.

15
Pour se faire, nous allons d’abord analyser le tableau Excel « Situation des lots de TFZ », prenons
l’exemple d’un enregistrement :

Superficie en
Ilot Lot Etat viabilisation
m²

110 2 2 196 Aménagés en cours de réception

Date de
Date de réception Vendu Date du contrat l'enregistrement
du contrat
non

Lots
Société Zone Tranche Phase
construits

Société 1 Logistique 3 Phase II Zone B

Cet exemple montre que chaque enregistrement comporte les colonnes suivantes :

- Ilot,
- Lot,
- Superficie en m2,
- Etat viabilisation,
- Date de réception,
- Vendu,
- Date du contrat,
- Date de l’enregistrement du contrat,
- Société,
- Zone,
- Tranche,
- Phase,
- Lots construits.

16
 4. Etude fonctionnelle :

L’application connaît un seul acteur qu’on « nommera » utilisateur. Indépendamment de la direction

à laquelle appartient cet utilisateur, du moment qu’il peut accéder à l’application il est capable de
bénéficier des cas d’utilisations suivant :

Fig 4 : Cas d’utilisations

17
 4.1. Description détaillée des cas d’utilisation :
Cas d’utilisation : Consulter les attributs d’un lot

Description : ce cas d’utilisation permet aux utilisateurs de l’intranet d’accéder aux valeurs
attributaires d’un sélectionné.

But : donner un accès instantané aux valeurs attributaires sans avoir à parcourir un fichier Excel.

Diagramme de séquence :

Fig 5: diagramme de séquence du cas d’utilisation « Consulter les attributs d’un lot »

18
Cas d’utilisation : Editer les attributs d’un lot

Description : l’application se base sur un « Shapefile » préparé au cours du stage, ce fichier n’est
toutefois pas final et des éditions (modifications) doivent être permis aux utilisateurs.

But : actualiser les attributs suite à de nouveaux contrats, aménagements, etc.

Diagramme de séquence :

Fig 6: diagramme de séquence du cas d’utilisation « Editer les attributs d’un lot»

19
Cas d’utilisation : Requête

Description : Réaliser des requêtes par positions (coordonnées) ou des requêtes conditionnelles ( en
attribuant des valeurs aux attributs tout en les combinant à des conditions « AND », « Or », etc.)

But : interroger par position ou par attributs.

Diagramme de séquence :

Fig 7: diagramme de séquence du cas d’utilisation « Requête»

20
Cas d’utilisation : Création d’un nouveau lot

Description : ajouter un nouveau lot à ceux déjà préexistants en lui affectant des valeurs
attributaires.

But : rester en phase avec les nouveautés qui s’ajoutent aux soldes fonciers.

Diagramme de séquence :

Fig 8 : diagramme de séquence du cas d’utilisation « création d’un nouveau lot»

21
 5. Etude technique :
L’architecture logique étant la manière dont les composants logiques de la solution sont
organisés et intégrés, celle utilisée ici est l’architecture 3-tiers qui est une architecture client-
serveur dans laquelle la présentation, le traitement des données et l’accès aux données sont des
processus séparés. Elle est modélisée et présentée comme un empilement de trois couches où
chacune propose un ensemble de service rendus. Les services d’une couche ne sont mis à
disposition que de la couche supérieure.

Fig 9 : architecture de l’application

En pratique, cela se traduit par :

Fig 10 : architecture de l’application

22
 Chapitre IV :

« La préparation des données »

Dans ce chapitre, il s’agit de présenter la préparation des données géographiques.

23
 6. Analyse du fichier « PLM TFZ_pfi » :

Ce fichier .dwg donne le plan de masse de la TFZ dans sa dernière mise à jour. Notre objectif
est de l’analyser pour savoir l’exporter tout en conservant l’information importante.
En l’ouvrant sur ArcView, on obtient l’affichage suivant :

Fig 11 : plan masse de la TFZ

Ce fichier est le fond de notre projet, aussi faut-il prêter une grande attention à sa synthèse
et traitement.
D’une autre part, le fichier « plan masse TFZ . dwg » présente une clarté qui convient plus à
nos objectifs avec le seul inconvénient d’être non actualisé.

24
 Fig 12 : plan masse de la TFZ

L’objectif est donc de simuler ce dernier fichier en opérant sur « le PLM TFZ_pfi .dwg ».

Pour ce faire, nous observons le fichier « plan masse TFZ . dwg » pour noter le suivant :

- Les polylines représentent les bornes des ilôts et lots.

- Les multipatch semblent être des corrections des polylines.
- Les annotations contiennent ce qui doit être intégré en tant qu’attribut dans le futur
fichier .shp.

On peut donc se dispenser des multipatchs et des annotations, au moins temporairement. On se

dispense en plus des Points. Ils restent donc :

- Les polylines,
- Les polygones.

Une première démarche intuitive serait donc de se focaliser sur les polylines et polygones du fichier
« le PLM TFZ_pfi .dwg ».

Le problème qui se pose maintenant est de savoir si ces deux composantes se complètent –au sens
où la représentation de la TFZ souffrirait des imprécisions si l’on rejette l’une des deux composantes.

Pour faire on réalise une comparaison visuelle en changeant adoptant des couleurs différentes et des
largeurs de lignes différentes :

- Les polygones du fichier « le PLM TFZ_pfi .dwg ».:

25
 - Les polylines du fichier « le PLM TFZ_pfi .dwg ».:

A première vue, ils semblent que les polylines présentent plus fidèlement notre zone. Passons à la
comparaison :

26
Dans cet exercice de comparaison, il s’agit de suivre les lignes rouges de l’œil et de voir si oui ou non
elles sont superposées aux vertes. Dans le cas du positif on se dispenserait des polygones et il suffira
de garder les polylines, autrement, il faut combiner.

Résultat : ce qui est représenté par les polygones est inclus dans ce qui est représenté par les
polylines. Gardons donc uniquement les polylines.

La transformation vers le .shp :

Option 1 :

Avant d’effectuer la transformation, il s’agit de savoir que sont les objets qui rentrent sous la
catégorie polyline de notre fichier .dwg.

On consulte la table attributaire de la couche polyline du .dwg, l’attribut layer révèle les contenus
suivant :

27
Ces objets sont les « Sources Types », les « Destination Types » sont les sorties, quant au « Data
Flow » il indique les types inclues dans le « Sources Types » et comment ils seront transformés.

Pour avoir une bonne transformation, il faut qu’on sache exactement que sont les types
géométriques manifestés par le « Source Type ». On doit donc consulter les attributs des polylines de
notre .dwg.

28
Les types géométriques sont ceux mentionnées dans les valeurs dans cette fenêtre de sélection
attributaire.

Tout ce qui est donc :

- Arc,
- Circle,
- Ellipse,
- Insert,
- Line,
- Polyline,

Doit être transférer dans des objets polygone.

Option 2 :

On export la partie polyline du .dwg en .shp et ce en passant par :

29
Après quoi on obtient un fichier .shp de polyline qu’il faut nettoyer et transformer en polygones. Ces
polygones seront objets d’une procédure de nettoyage et d’agrégation pour aboutir sur une
représentation aussi fidèle et complète que possible du patrimoine foncier de la TFZ.

Ce travail est largement manuel et dépend de l’acuité de l’observation. Il faut employer beaucoup de
temps à relater ce qui manque ou excède le fichier .dwg et veiller à le compléter.

Les problèmes rencontrés :

L’export et polygonation, deux processus automatisés, ne sont pas veillant au sens où parfois les
résultats sont améliorables.

Résultat :

Problème Exemple Description Causes Effets

Polygone Les La cause Sous-
incomplet. diverses devrait être évaluation
transforma le de la surface
tions dédoubleme
passent par nt des lignes
des vertex dans les
qui ne fichiers .dwg
trace pas
fidèlement
les limites
de l’ilot ou
du lot.

30
Polygone a Les limites Assimilation Ce problème
vec du des lignes de cause une
excédants. polygone trotoires ou surévaluatio
inclus celle chemin pour n de la
des ilots limite du lot. surface du
initiaux. polygone.

Limites
décalées.

31
Autant de cas qui, en pratique, requiert trop de corrections. Le temps réservé à ces corrections peut
être utilisé plus intelligemment : digitaliser les lots, à la main.

7. Digitalisation d’un fichier polygone à la base de « PLM

TFZ_pfi » :
Cette étape –laborieuse certes- a le mérite de donner des résultats impeccables en termes de
représentation et respect des surfaces.

32
33
 Chapitre V :

« La réalisation de l’application »
Dans ce chapitre, il s’agit de présenter les étapes de la réalisation de l’application.

34
 8. Les outils choisis :
PostgreSQL et Postgis :

Fig 13 : Icône de PostGIS

PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO). C'est un
outil libre disponible selon les termes d'une licence de type BSD.

Ce système est concurrent d'autres systèmes de gestion de base de données, qu'ils soient libres
(comme MySQL et Firebird), ou propriétaires (comme Oracle, Sybase, DB2, Informix et Microsoft SQL
Server). Comme les projets libres Apache et Linux, PostgreSQL n'est pas contrôlé par une seule
entreprise, mais est fondé sur une communauté mondiale de développeurs et d'entreprises.

PostGIS ajoute le support d'objets géographique à la base de données PostgreSQL. En effet, PostGIS
"spatialise" le serveur PostgreSQL, ce qui permet de l'utiliser comme une base de données SIG.

La version que nous avions utilisé est la version 9.0 avec Postgis 1.5.

Geoserver :

35
 Fig 14 : Icône de GeoServer

GeoServer est un serveur informatique open source écrit en Java qui permet aux utilisateurs de
partager et modifier des données géographiques. Conçu pour l'interopérabilité, il publie les données
de toutes les sources principales de données spatiales qui utilisent des normes ouvertes. GeoServer a
évolué pour devenir une méthode simple de connexion d'informations existantes à des globes
virtuels tels que Google Earth et NASA World Wind, ainsi que pour les cartes à base de services web
tels que OpenLayers, Google Maps et Bing Maps. GeoServer fonctionne en tant qu'implémentation
de référence pour la mise en œuvre du standard du Web Feature Service de l'Open Geospatial
Consortium ; il implémente aussi le Web Map Service.

GeoServer fonctionne comme un nœud dans une infrastructure de données spatiales libre et
ouverte. Tout comme le serveur HTTP Apache offre une solution de serveur web libre pour publier
du HTML, GeoServer vise à faire de même pour les données géospatiales.

GeoServer lit de nombreux de formats de données, y compris :

PostGIS

Oracle Spatial

ArcSDE

DB2

MySQL

Shapefiles

GeoTIFF

GTOPO30

ECW, MrSID

JPEG 2000

Grâce à des protocoles standards qu'il produit KML, GML, Shapefile, GeoRSS, PDF, GeoJSON, JPEG,
GIF, SVG, PNG et plus. En outre, on peut modifier les données via le SMA profil transactionnelle
(WFS-T). GeoServer OpenLayers comprend un client intégré pour la prévisualisation des couches de
données.

36
GeoServer supporte en outre la publication efficace des données géo-spatiales de Google Earth grâce
à l'utilisation de liaisons réseau, utilisation des fichiers KML. Les fonctionnalités avancées de Google
Earth de sortie comprennent les modèles de mesure des pop-ups, des visualisations de temps et de
la hauteur, et "super-overlays".

GeoServer s'appuie sur GeoTools, une bibliothèque d'outils en Java pour manipuler le SIG (système
d'information géographique).

OpenLayers :

Fig 15 : Icône d’OpenLayers

OpenLayers 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 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.

Il est, par exemple, utilisé pour l'affichage des cartes par le navigateur Web dans le projet
OpenStreetMap.

GeoEXT :

Fig 16 : Icône de GeoExt

GeoExt rassemble le savoir-faire géo-spatial d’OpenLayers avec l’interface utilisateur savvy

d’ExtJS pour aider à créer de puissantes applications SIG desktop ou sur le Web avec JavaScript.

37
OpenGeo :

Cette suite rassemble dans un environnement convivial les outils indispensables pour le
développement du web-mapping. Disponible en version d’essai (30 jours) et en version
communauté, nous avion opté pour la version communauté pour rester dans l’open-source.

Fig 17 : interface de démarrage d’OpenGeo

Un outil de toute importance est le « Client SDK » qui sert au développement d’une application web-
mapping et d’y ajouter des fonctionnalités et widgets. Déployant des classes basées sur OpenLayers
et Ext, elle s’avère un passage précieux pour s’introduire à la programmation en cartographie web.

9. Préparation des outils

Après installation de PostgreSQL, on upload le fichier shapefile préparé et ce comme suit :

 On ouvre l’outil « Postgis and DBF loader ».

38
 Fig 18 : l’uploader de fichier « .shp » de PostGIS

Il faut spécifier les paramètres de la connexion du serveur de la base de données ainsi que la saisie
du bon SRID qui correspond au nord du Maroc (système de projection) et qui est dans ce cas 26191.

 Nous consultons la base de données pour voir la table des données ajoutées :

39
 Fig 19 : l’interface de PostGres

On ouvre la table « foncier » en une version simplifiée :

Fig 20 : Exemple d’une table de PostGis

Ce schéma simplifié nous permettra de découvrir.

40
Ce qui nous intéresse c’est l’ajout de ce shapefile à notre serveur cartographique qui est Geoserver :

Fig 21 : page d’administration de GeoServer

En cliquant sur entrepôt, on obtient :

Fig 22 : ajout d’une nouvelle ressouce sur GeoServer

C’est là qu’on clique sur PostGis, on crée ensuite une connexion avec la base de données à travers
cette interface :

41
 Fig 23 : connecter GeoServer à PostGis

Bientôt, l’interface nous demande de choisir une table à publier sur le serveur, notre choix se fait sur
« Foncier » biensûr.

On clique sur publier sous la colonne action, à ce stade, on doit prendre soin de remplir correctement
quelques champs :

42
 Fig 24 : système de projection et emprises sous GeoServer

Le SRC natif et des données doit être 26191 qui correspond à ESPG : Merchich/Nord Maroc. Dans la
figure, c’est celui du sud maroc qui est mentionné.

Les emprises aussi doivent être remplies et il suffit pour cela de cliquer sur « basées sur les
données » et « calculées sur les emprises natives » pour obtenir les X et Y maximum et minimum de
la vue cartographique.

En clique ensuite sur la prévisualisation de la couche dans la rubrique données sur la panneau à
gauche de la page, on pourra constater toutes les données uploadé sur le serveur dont figure la
nôtre.

On cliquant sur la Openlayers sous la colonne « Formats usuels » on peut accéder à une page web de
type client cartographique construit à base de l’API OpenLayers :

43
 Fig 25 : visualisation de la ressource sous GeoServer

L’étape suivante consiste en la programmation d’une interface à l’aide du « Client SDK ». Ce passage
sera traité dans la 9ème titre.

10. La programmation de notre application :

Le « Client SDK » est installé à travers la plateforme « OpenGeo Suite », mais il faut quelques étapes
de configuration pour obtenir utilisabilité de cet outil :

a. Installer l’outil Apache Ant et configurer les variables d’environnement pour. Cela se
fait en rentrant sur la console (cmd.) et en tapant les lignes suivantes :

Set ANT_HOME=C:\ant
(Sachant que C:\ant est le fichier ou l’on a décompressé le fichier binaire de l’outil
Apache Ant).

Set PATH=%PATH% ;%ANT_HOME%\bin

(On ajout au chemin système ou “PATH” chemin qui est le fichier bin de notre
ANT_HOME)

Set suite-sdk= C:\Program Files\OpenGeo\OpenGeo Suite\sdk\bin

Set PATH=%PATH% ; C:\Program Files\OpenGeo\OpenGeo Suite\sdk\bin

Ceci étant fait, il est recommandé de redémarrer l’ordinateur pour que les changements soient pris
en considérations.

44
 Récapitulatif :

- On a installé «OpenGeo Suite ».

- Eventuellement installé postgresSQL avec l’extension PostGIS séparément
de la « suite ». (pour des raisons de dysfonctionnalités de la version sur la
suite).
- Configurer les variables environnement pour pouvoir utiliser le « Client
SDK » disponible sur la « suite ».

Nous sommes à présent prêts de rentrer dans le vif du sujet.

9.1 Création d’une nouvelle application :

Sur la console, on tape :

Suite-sdk create C:/TFZ

Fig 26 : console pour la commande create

Si la requête passe en succès, la console devrait ressembler à celle montrée en haut.

45
On vérifie dans l’emplacement pour trouver un fichier TFZ créé et comportant le suivant :

Le fichier src comporte notamment les fichiers .js (Javascript) qui comportent les classes avec
lesquels nous allons construire notre application.

On passe à présent à la commande de débugage :

Suite-sdk debug c:/TFZ

Fig 27 : console pour la commande debug

En effet, le serveur va publier l’application sur le port 9080, c'est-à-dire sur l’URL :
http ://localhost :9080/

La page suivant s’affiche :

46
 Fig 28 : fond openstreetmap de notre application

La carte du fond est une carte d’OpenStreetMap.

Il suffit de rentrer dans CTRL-C pour voir le serveur s’arrêter.

On entre une commande qui a pour objectif de nous aider à accéder au GeoServer accessible sur le
port 8080.

Suite-sdk debug –g http://localhost:8080/geoserver c:/TFZ

Fig 29 : commande de debuggage

Le déploiement de l’application (mise en production) sera fait après que les scripts seraient modifiés
de sortes à nous donner l’application recherchée.

Avant de faire, ajoutons la couche « Foncier » et jetons un coup d’œil sur la carte :

47
 Fig 30 : couche « foncier » de la TFZ

Le Template de l’application bénéficie d’un nombre d’outils préinstallés, toutefois nous voulons
compléter par d’autres outils.

Nous commencerons par l’outil d’info-bulle dénommé « WMS GetFeatureInfo tool », pour se faire
nous accéderons au fichier C:\TFZ\src\app qui contient le script app.js , nous ouvrons ce script à
l’aide de Notepad++ (ou n’importe quel éditeur texte) :

Analysons d’abord ce fichier, en premier lieu il comporte une liste de dépendances auxquelles il faut
ajouter de nouvelles. L’ajout d’un outil doit passer premièrement par cette étape : l’ajout du fichier
script (.js) qui lui correspond parmi les dépendances, autrement dit : ajouter une ligne de la forme

*@require chemin/de/la/dependance.js

Fig 31 : les dépendances requises pour notre fichier .js

48
Par suite, il faut se diriger à la section « tools » dans l’app.js et ajouter l’outil comme suit :

Ptype : « gxp_teloutil »

Fig 32 : ajout d’outils dans notre application

Ce schéma est à suivre pour tous les outils à ajouter, pour se faire, nous allons ajouter le code
correspondant pour l’info-bulle et qui est :

Dans les dépendances :

* @require plugins/WMSGetFeatureInfo.js

Dans les « tools » :

{
ptype: "gxp_wmsgetfeatureinfo"
}

On enregistre le fichier app.js modifié, et on redémarre le serveur sur la console en :

b. Cliquant sur Ctrl+C ,

c. Entrant la commande : suite-sdk debug.

49
On rafraîchit la page localhost :9080 et on remarquera qu’un outil d’information est ajouté à la barre
des outils :

Il suffit à présent de cliquer sur un objet (lot) dans la carte pour voir s’afficher les informations
attributaires qui lui sont relatifs.

Fig 33 : pop-up avec information sur le lot

A présent on ajoute la table d’affichage des attributs, pour cela on ajoute dans la section
« portalConfig », dans « items » le code suivant :

{
id: "south",
xtype: "container",
layout: "fit",
region: "south",
border: false,
height: 200
}

50
Puis dans la section « tools » on ajoute :

{
ptype: "gxp_featuregrid",
featureManager: "TFZ_manager",
outputConfig: {
loadMask: true
},
outputTarget: "south"
}

Mais avant que cela ne soit totalement fonctionnel, il faut ajouter un « feature_manager » comme
suit :

* @require plugins/FeatureManager.js

Puis :

{
ptype: "gxp_featuremanager",
id: "TFZ_manager",
paging: false,
autoSetLayer: true
autoLoadFeatures: true

On ajoute l’outil pour la modification ou l’édition des objets lots, pour ce faire :

* @require plugins/FeatureEditor.js

{
ptype: "gxp_featureeditor",
featureManager: "TFZ_manager",
autoLoadFeature: true
}

On ajoute l’outil pour les requêtes, via :

* @require plugins/QueryForm.js

{
ptype: "gxp_queryform",
featureManager: "TFZ_manager",
outputConfig: {
title: "Requete",
width: 320
},
actionTarget: {target: "east"},
queryByAttributesText: "Interroger par proprietes"

51
 }

Le résultat est le suivant :

Fig 34 : tableau d’affichage des lots et modules de requête

Les différents modes d’interaction passent par la barre supérieure de la carte qui permet d’éditer, de
consulter les infos d’un lot, de zoomer…Le requêtage est disponible sur un panel en « Est ».

Fig 35 : consultation d’informations d’un lot.

52
 Fig 36 : exemple d’édition d’un lot.

Fig 37 : exemple de requête rendant « Etat_viabi = ‘Oui’ », donc lots viabilisés.

Fig 38 : exemple de requête avec lot viabilisé appartenant à la tranche 2.

53
 Annexes

54
 Annexe 1
Guide d’utilisation et package d’installation de l’application

Réalisation d’un guide d’utilisation pour installer l’application sur un serveur.

Commençons par faire un récapitulatif de ce qu’il faut avoir sur le package :

1/ OpenGeoSuite.

2/ PostgresSQL 9.0.6

Première étape : installation d’OpenGeo Suite

Lancer l’installation en cliquant sur l’exe « OpenGeoSuite-ce-2.5.exe », cliquez ensuite sur next
jusqu’à arriver à cette étape :

55
Dérouler en bas et cocher les extensions :

Cliquez ensuite sur next, sur la fenêtre suivante cliquez sur install.

Ouvrir l’OpenGeo Suite et cliquer sur le bouton « Start » en haut à droite :

56
Il faut attendre quelques minutes avant d’obtenir le déclenchement de l’outil, une fois cela fait, on
est devant une fenêtre comme la suite :

A ce niveau, on doit accéder au GeoServer en cliquant sur « Configure », une page web s’ouvre à
laquelle nous accédant :

Pour se connecter entrant les informations suivantes :

Nom d’utilisateur : admin

57
Mot de passe : geoserver

On obtient :

Il faut à ce point importer le shapefile préparé, pour se faire choisir, en gauche, la rubrique
« Données » et cliquez sur « Importe Data » :

58
La taille et l’usage que l’on fera de l’application ne nécessite pas de passer par une base de données,
quoique ça reste un choix plus orthodoxe, il reste toutefois plus simple de passer par l’ajout directe
du shapefile et ce en :

59
1/ Copier le dossier « Foncier » dans le package et le coller dans le ficher data_dir sur le chemin
suivnat :

C:\Program Files\OpenGeo\OpenGeo Suite\data_dir

2/ on va reprendre “L’import data”, et on choisira « spatial files », en cliquant dessus :

Ensuite, cliquant sur browse :

Après avoir cliqué sur Browse, la fenêtre suivante s’affiche :

Il s’agit donc de suivre le chemin en cliquant sur « C : » puis « Program Files » etc.

Il s’agit d’arriver à cet écran :

60
On choisira donc le fichier « Foncier.shp », cliquer sur le bouton « Ok » en bas à droite (il suffit de
cliquer dessus même).

On clique donc sur next :

61
Cochons la case à côté de « Layer » et de « Foncier ». Cliquons aussi sur le bouton rechercher et
tapons : « Merchich » :

On cliquera sur le deuxième choix, c'est-à-dire 26191 (Merchich/Nord Maroc).

62
Cliquer sur « Apply » à droite de la ligne puis cliquer sur le bouton « Importer les données ». Si tout
suit le chemin correct, on devrait en être à un écran comme celui-là :

Notre couche « Foncier » est ajouté à présent à notre serveur, ceci nous permettra –plutard – de
l’utiliser sur notre application.

Note : Dans la dernière figure, la couche s’écrit « Foncier0 » puisque j’avais auparavant ajouté la
même couche, pour un premier ajout la couche inscrite sera notée « Foncier ».

Deuxième étape : déploiement de l’application.

Commençant d’abord para décompresser le fichier « apache-ant-1.8.4-bin » sur le « C : » (ou toute

autre destination à condition d’en prendre note). On changera ensuite le nom du fichier en « ant »,
puis en veillera à ce que la décompression n’engendre pas un fichier emboîté (ant/ant), c'est-à-dire
que l’on devrait être capable d’ouvrir le fichier et de tomber directement sur les fichiers suivants :

63
On ouvrira par suivante la commande « .cmd » et on passera les commandes suivantes :

Set ANT_HOME=C:\ant
(Sachant que C:\ant est le fichier ou l’on a décompressé le fichier binaire de l’outil
Apache Ant).

Set PATH=%PATH% ;%ANT_HOME%\bin

(On ajout au chemin système ou “PATH” chemin qui est le fichier bin de notre
ANT_HOME)

Prendre le fichier « bin » dans le package et le coller (si préexistant, copier en remplaçant) dans la
destination suivante :

C:\Program Files\OpenGeo\OpenGeo Suite\sdk\bin

Ouvrir la console « .cmd » et entrer les paramétrages suivant :

Set suite-sdk= C:\Program Files\OpenGeo\OpenGeo Suite\sdk\bin

Set PATH=%PATH% ; C:\Program Files\OpenGeo\OpenGeo Suite\sdk\bin

Ces étapes faite, on peut tester la commande “suite-sdk”, le résultat devrait être :

64
On peut oublier pour un moment la console des commandes. Retournons à notre package et copions
le fichier « TFZ » dans une destination reconnaissable (« C : » reste toujours une bonne option). Ce
fichier comporte les scripts .js que fera boucler le débugger ou le « déployeur »de notre outil sdk
d’OpenGeo Suite.

De retour à notre console de commandes, rentrant la suivante :

Suite-sdk debug –g http://localhost:8080/geoserver c:/TFZ

La commande peut échouer si l’on n’a pas faire une des deux :

- Lancer geoserver (cliquez sur « start » dans le dashboard d’OpenGeo Suite).

- Le chemin « c:/TFZ » n’était pas le chemin où l’on a déposé notre fichier « TFZ », à modifier le
cas échant.

Sinon, si elle se s’exécute avec succès, on va avoir :

Dès lors, on peut ouvrir un navigateur et tester l’URL suivant :

http://localhost:9080/

Bien sûr, c’est notre application qui s’affiche après quelques secondes d’attente.

Mais notre objectif n’est pas de debugger, nous voulons l’application présente sur le serveur en
constance, il faudra donc déployer. Sur la console de commande, rentrons la suivante :

suite-sdk deploy -d localhost -r 8080 -u manager -c jetty6x c:/TFZ

65
Notre console doit ressembler à cela :

Après quoi on peut consulter notre application déployée sur l’URL :

http://localhost:8080/TFZ/

Recommandations :

- Les étapes explicitées ont été faites sur l’OS Windows vista.
- Il convient d’installer une version du JDK java (jointe sur le package).
- Le navigateur Firefox semble s’adapter mieux avec les exigences graphiques de notre
application.

66
 Annexe 2

67
 Annexe 3

68