Université de Toulouse
MASTER 2 GEOMATIQUE
« Science de l’Information Géoréférencée pour la Maîtrise de l’environnement et
l’Aménagement des territoires » (SIGMA)
http://sigma.univ-toulouse.fr
RAPPORT DE STAGE
Conception et implémentation d’un SIG pour la réalisation d’une
carte archéologique et paléo-environnementale de la Maréotide
(Egypte)
RAMM Aenne
Maître de stage : Cécile Shaalan
Tuteur-enseignant : Laurent Jégou
Septembre 2016
1
Résumé
Dans le cadre d’un stage de fin d’études de quatre mois, un SIG (Système d’Information
Géographique) a été développé pour le CEAlex (Centre d’Etudes Alexandrines, USR 3134 du
CNRS), centre d’études archéologiques et pluridisciplinaires dans la région d’Alexandrie en
Egypte. Ce SIG doit regrouper les données cartographiques vectorielles et archéologiques
écrites sur la région ; l’utilisateur manipulera une carte interactive qui permettra des requêtes
à la fois spatiales et attributaires sur les deux types de données. Les utilisateurs n’étant pas
informaticiens, doivent manipuler une interface parlante et facile d’accès. Le projet a débuté
par une recherche approfondie et la proposition de solutions. Les attentes et réflexions sont
présentées dans ce texte. A la fin de cette première phase, il a été décidé de travailler avec une
combinaison de deux logiciels : PostGreSQL qui héberge la base de données et QGis, un
logiciel cartographique affichant le SIG. En plus, FilemakerPro est utilisé pour la saisie des
données archéologiques. Un mode de mise à jour régulière des données vers PostGreSQL a
été mis en place. La base de données spatiale a été constituée. Des cartes de fond au format
raster ont été regroupées et reliées à la base de données. A l’issue de ce travail, le SIG existe
mais doit encore être manipulé en écrivant des requêtes en SQL. C’est la raison pour laquelle
un grand nombre de guides d’utilisateurs ont été rédigés et une formation des chercheurs a été
organisée. Cependant, une future intervention d’un informaticien visera le développement
d’une interface graphique sous forme de plugin pour faciliter l’interrogation du SIG.
Mots-clés : QGis, PostGreSQL, archéologie
Abstract
In the context of a four-month internship a GIS (geographic information system) has been
developed for the CEAlex (Centre d’Etudes Alexandrines, USR 3134 of the CNRS), centre of
archaeological and cross-disciplinary studies, in the region of Alexandria in Egypt. The GIS
should collect the cartographic vector data and the archaeological metadata of the region; the
user will be enabled to query the interactive map by spatial and written requests. As the users
are no computer scientists, a simple graphical interface must be developed. The project has
started with a period of research and solution proposals. The different expectations and
reflexions are presented in this report. After careful consideration, we decided to work with a
combination of two softwares : PostGreSQL, an object-relational database management
system and QGis handling the geographic data. In addition, FilemakerPro will be used for the
archaeological data entry. A method for transferring FilemakerPro data to PostGreSQL has
been developed. Maps and raster data have been merged and linked to the database. Currently,
the GIS exists but it must be queried by using SQL querying language. This is the reason why
a certain number of user guides has been produced and training sessions have been organised
for the researching team.
Hereafter, a computer scientist will work on the development of a plugin as a graphical
interface.
Keywords: QGis, PostGreSQL, archaeology
2
3
Remerciements
Je souhaite d’abord remercier toute l’équipe du CEAlex pour sa confiance et son soutien
pendant la durée du stage.
Un grand merci à Cécile Shaalan pour son accompagnement ainsi qu’à Monsieur Jégou
d’avoir accepté de diriger mon travail.
Je tiens à exprimer ma gratitude à l’ensemble du corps enseignant du master SIGMA pour la
formation que j’ai reçu tout au long de l’année, qui m’a permis d’effectuer mon stage.
4
Table des matières Lexique ....................................................................................................................................... 5
Introduction ................................................................................................................................ 6
Un SIG GEOMAR ..................................................................................................................... 8
Personnes et données ............................................................................................................ 11
Finalité du SIG ..................................................................................................................... 11
Données archéologiques et SIG ............................................................................................... 13
BdD GEOMAR .................................................................................................................... 13
L’export ................................................................................................................................ 15
Structure de la nouvelle base de données ............................................................................. 16
ArcGis .................................................................................................................................. 17
PostGreSQL / PostGis .......................................................................................................... 19
PostGis - Qgis ................................................................................................................... 20
PostGis - ArcGis ............................................................................................................... 21
Interface SIG : possibilités et résultats ..................................................................................... 23
Modeleur graphique et plugin .............................................................................................. 25
Plugin ................................................................................................................................... 27
Solutions tiers en QGis ......................................................................................................... 28
L’interface des résultats de la requête .................................................................................. 29
Les images dans le SIG ........................................................................................................ 29
Conclusion ................................................................................................................................ 32
Table des Figures ..................................................................................................................... 34
Ouvrages ............................................................................................................................... 35
Articles de revues scientifiques ............................................................................................ 35
Thèses et rapports de stage ................................................................................................... 35
Sites web consultés régulièrement ....................................................................................... 36
Annexes .................................................................................................................................... 37
5
Lexique ANR Agence Nationale de la Recherche
ArcGis Suite de logiciels d’information géographique
BdD Base de données
CEAlex Centre d’Etudes Alexandrines
FMP FilemakerPro, logiciel de base de données
GEOMAR Appellation du projet ANR : « Gestion de la
ressource en Eau dans l’Orient Méditerranéen :
Alexandrie et son Réseau hydrographique »
GO Giga octet
Karm Appellation d’un vignoble ancien dans la région
alexandrine
MapInfo Logiciel d’information géographique
ODBC Open Database Connectivity
OLE DB Interface de programmation permettant d’avoir
accès aux données à partir d’un logiciel
secondaire
PgAdmin Outil d’administration graphique pour
PostGreSQL
PostGis Extension spatiale de PostGreSQL
PostGreSQL Système de base de données relationnelle
QGis Logiciel d’information géographique
Shapefile Fichier vectoriel géoréférencé
SIG Système d’Information Géographique
SQL Structured Query Language, langage
informatique d’exploitation des bases de données
6
Introduction Ce rapport a pour but de résumer et analyser un stage de quatre mois qui s’est déroulé entre le
5 mars et le 5 juillet 2016 dans le cadre du Centre d’Etudes Alexandrines dirigé par Marie-
Dominique Nenna.
L’exercice géomatique de ce stage de fin d’études se construit autour d’un travail
archéologique effectué sur la région de la Maréotide qui se trouve au sud-ouest d’Alexandrie
dans le nord de l’Egypte. Le Centre d’Etudes Alexandrines (CEAlex)1, structure d’accueil
pour ce stage, pose un contexte particulier en raison de sa diversité scientifique et son
caractère international. Il s’agit d’un laboratoire du CNRS fondé en 1990 par Jean-Yves
Empereur à Alexandrie, aujourd’hui dirigé par Marie-Dominique Nenna. Jusqu’à aujourd’hui,
il est le seul Centre d’études archéologiques permanent dans cette ville de l’Egypte. De ce
fait, un certain nombre de missions internationales s’appuient sur les moyens du CEAlex et
sur leurs relations avec le gouvernement égyptien qui sont, en raison de leur continuité, plus
proches qu’avec d’autres équipes européennes. C’est la raison pour laquelle des chercheurs de
différentes nationalités et horizons divers viennent effectuer des missions de durées
différentes, tels que les archéologues et égyptologues mais aussi les architectes,
géomorphologues et historiens. Cette pluridisciplinarité du travail archéologique constitue un
facteur très intéressant de ce stage. En même temps, elle pose des contraintes parce que toutes
les personnes participant au projet GEOMAR, pour lequel le SIG a été développé, ne se
trouvent pas sur place. Ils viennent à Alexandrie pour effectuer des missions et certains ont
passé seulement quelques semaines au CEAlex pendant le temps de mon stage, comme par
exemple la directrice du service informatique et le géomorphologue travaillant sur la zone
d’étude concernée par le SIG à développer. Cependant, il a fallu intégrer l’ensemble des
données de chercheurs sur place ou non. Le titre du stage annonce déjà sa pluridisciplinarité :
« Conception et implémentation d’un SIG pour la réalisation d’une carte archéologique et
paléo-environnementale de la Maréotide ». Les données archéologiques aussi bien que les
données paléo-environnementales (géomorphologiques) se trouvent au cœur de la carte à
réaliser. Elles s’intègrent dans un programme de recherche intitulé GEOMAR qui s’interroge
sur la « Gestion de la ressource en Eau dans l’Orient Méditerranéen : Alexandrie et son
Réseau hydrographique ». Mais, à quoi correspond alors la Maréotide ?
La « Maréotide » correspond à la région entourant le lac Mariout qui se trouve au sud-ouest
de la ville d’Alexandrie. Les appellations tant du lac que de la région sont très anciennes et
trouvent leur origine dans l’antiquité. Cependant les premiers documents qui mentionnent le
Mariout sont rédigés par Strabon, géographe grec qui vit entre 64 av. J.-C. et 25 ap. J-C.
environ. Il décrit l’impressionnante taille de ce lac qui aurait fait plus que 150 stades en
largeur et un peu moins que 300 stades en longueur, ce qui correspond à environ 30 km
suivant l’axe nord-ouest/sud-est et 60 km suivant l’axe nord-est/sud-ouest2.
1 http://www.cealex.org/ , 03.07.2016 2 Pichot V. (2012). « La Maréotide : région fertile de la chôra d’Alexandrie, carrefour du commerce à l’époque gréco-romaine ». In Esposito A., Sanidas G.M. Archaiologia « Quartiers » artisanaux en Grèce ancienne, Lille, Septentrion, p. 82
7
Grâce aux travaux géomorphologiques réalisés dans la région, nous savons que le lac qu’on
peut appeler comme tel, existe depuis 5500 av. J.-C. Avant cette date, toute la région aurait
fait partie d’une plaine d’inondation d’un paléo-Nil3. Suite aux différents changements
climatiques et aux activités de l’homme, le lac s’est fortement transformé pendant les
dernières décennies ; il aurait perdu plus que 80% de sa superficie depuis 18004. L’évolution
du bassin du Mariout est un des axes d’étude au sein du CEAlex visant à expliquer les
changements anthropiques et naturels ainsi que leurs interactions. L’évolution de l’eau dans la
région ainsi que les sites potentiels de fouilles sont cartographiés par le service topographique
du CEAlex. Un SIG doit permettre de croiser les différentes informations recueillies et de
visualiser les interactions anthropiques avec les changements environnementaux.
3 Cl. Flaux, Chr. Mohrange, M. Torab, M. El-Assal (2011). « Alexandrie, un cordon entre deux mers : une lecture géomorphologique ». In Hairy I. Du Nil à Alexandrie, Paris, De Boccard, p. 121 4 Awad, I. (2010). « A study of the evolution of the Maryut Lake through maps ». In Blue L. and Khalil E. (Eds.), Lake Mareotis: Reconstructing the Past, Proceedings of the International Conference on the Archaeology of the Mareotic Region Held at Alexandria University, Egypt 5th-6th April 2008, Oxford, University of Southampton Series in Archaeology 2, BAR S2113, pp. 11-33
8
Un SIG GEOMAR Le développement d’un SIG est formalisé dans les résultats attendus du programme ANR
GEOMAR. Le sujet de stage proposé par le CEAlex s’intitule :
« Conception et implémentation d’un SIG pour la réalisation d’une carte archéologique et
paléo-environnementale de la Maréotide (Égypte) »
A première vue, il s’agit d’un sujet relativement large qui laisse de la place à l’interprétation.
Quand on évoque un SIG, il convient de penser à un ensemble de couches cartographiques
auxquelles on ajoute des métadonnées et parfois des fichiers raster. Wikipédia définit un SIG
comme suit :
« Un système d'information géographique (SIG) est un système d'information conçu pour
recueillir, stocker, traiter, analyser, gérer et présenter tous les types de données spatiales et
géographiques. »5
Le SIG sert alors au stockage et à l’organisation de fichiers. Des fonctionnalités
supplémentaires s’ajoutent selon les attentes des utilisateurs. C’est pourquoi il faut d’abord
s’interroger sur l’utilisation envisagée du SIG par l’équipe de recherche. Comment vont-ils
exploiter les données ? Dans un premier temps, nous devons analyser les besoins des
utilisateurs face au nouvel outil. Une grande partie des particularités du SIG dépend du
programme de recherche dans lequel il s’intègre.
Le programme de recherche GEOMAR thématise la question de la gestion de l'eau dans la
région d'Alexandrie qui comprend la Maréotide et la zone voisine de Wadi Natrun6. Une
« lecture historique et pluridisciplinaire des changements hydrologiques »7 est menée en
affichant les conséquences et contraintes de ces changements sur l'environnement et sur la
société. L'équipe cherche à connaître les pratiques d'exploitation des ressources en eaux
douces dans la région alexandrine qui se trouve sur la limite entre la zone désertique et le
delta du Nil. De même, on s'interroge sur la question de savoir si une relation entre l'évolution
de l'eau et le peuplement de la région peut être établie. L'adaptation de l'homme au
changement environnemental pendant la période de désertification ainsi que l'interaction entre
homme et nature sont thématisées. Comme il a été mentionné plus haut, il s'agit d'un
programme interdisciplinaire qui se construit autour de quelques analyses clé :
1. « L'analyse morphologique à haute résolution d'un ancien vignoble (karm), qui sera
sélectionné à partir des prospections de terrain.
2. L'analyse macro- et micro-botanique de restes végétaux trouvés dans le contexte de
fermes viticoles et oléicoles (pressoirs et cuves, amphores, fours, briques de terre crue,
champs...) et en dehors de ces espaces agricoles (espaces adjacents non cultivés ou
espaces cultivés abandonnés).
5 Wikipedia. https://fr.wikipedia.org/wiki/Syst%C3%A8me_d'information_g%C3%A9ographique, 18.04.2016 6 Voir la carte de la zone d’études, page 3 7 Agence Nationale de la Recherche. http://www.agence-nationale-recherche.fr/?Projet=ANR-12-SENV-0008, 18.04.2016
9
3. Chronologie des phases de développement et de rétraction agricole et pastorale en
Maréotide.
4. L'étude des variations holocènes des niveaux des lacs du Wadi Natrun.
5. L'étude des sources hydrologiques des lacs du Wadi Natrun.
6. La reconstitution des variations du couvert végétal naturel et potentiellement induit par
l'anthropisation.
7. L'analyse des isotopes du plomb le long de la séquence sédimentaire. »8
A ce jour, 105 sites archéologiques et géoarcheologiques sont recensés. Ils ont été découverts
à partir du dépouillement de la bibliographie, en comparant ces sites avec des informations
issues d’anciennes cartes et des images satellitaires et lors des prospections archéologiques.
Plusieurs ont été fouillés ou ont fait l’objet d’une prospection très poussée par le CEAlex :
Akadémia, Bahig, Kôm de la Carrière, Marea. Un bilan sédimentaire du delta du Nil a été fait.
Les « résultats montrent que la vulnérabilité du delta du Nil présente une histoire
particulièrement longue, en réponse aux changements climatiques ainsi qu'à la pression
anthropique. »9 Travaillant sur ce projet depuis 201310, l’équipe du CEAlex a déjà recueilli un
grand nombre d’informations qui peuvent être intégrées dans le SIG. Ces informations se
présentent sous différents formats. La base de données continue à être alimentée et deviendra
plus volumineuse dans l’avenir.
8 Agence Nationale de la Recherche. http://www.agence-nationale-recherche.fr/?Projet=ANR-12-SENV-0008, 18.04.2016 9 Ibid. 10 L’ANR GEOMAR a débuté en 2013. Cependant, les prospections et fouilles dans la région qui nourrissent la base de données ont commencé depuis les années 1980.
10
Figure 1 : La zone d'étude GEOMAR
11
Personnes et données Des chercheurs de différents domaines participent au programme GEOMAR ce qui mène à la
diversité des données et prospections sur le terrain. Plusieurs archéologues organisent les
fouilles, un géomorphologue mène les recherches sédimentaires et paléo-environnementales,
les topographes participent par la recherche cartographique sur l’évolution du lac Mariout et
toute la région alexandrine. La base de données existante regroupe les métadonnées
archéologiques et paléo-environnementales avec un catalogue d’images illustrant les sites.
Une couche vectorielle affichant l’emplacement des sites répertoriés et des carottages
effectués pour la recherche géomorphologique, constitue la base cartographique du SIG. En
plus, plusieurs autres couches vectorielles renseignent sur les structures complémentaires dans
la région, telles que des anciens puits ou des cimetières, mais aussi sur l’avancée du lac à
différentes époques. Plusieurs rasters servent de fond de carte, il s’agit de cartes anciennes qui
ont été scannées et d’images satellitaires.
Finalité du SIG Au début du stage, les informations recueillies par l’équipe de recherche sont divisées en deux
ensembles. D’un côté, les métadonnées et les photos se trouvent dans une base de données
gérées par une archéologue. De l’autre côté, les fichiers cartographiques sont gérés au sein du
service de topographie. Il faut alors rassembler ces données et les relier dans un SIG. Ceci
doit permettre de mener des requêtes à la fois attributaires et spatiales sur la base de
l’ensemble des données et d’afficher cette sélection de sites sur une carte. De cette manière,
les chercheurs peuvent identifier des ensembles de sites qui pourraient indiquer l’organisation
de l’espace à un certain moment de l’histoire. Les chercheurs souhaitent manipuler ce qu’on
peut appeler une carte interactive permettant de faire des sélections et d’afficher des
ensembles.
Voir le projet SIG comme une carte interactive fait rapidement penser à un webSIG qui
facilitera les trois niveaux de distribution envisagés par le CEAlex : une version interne, une
version qui sera transmise au Ministère égyptien des antiquités et une distribution en ligne des
données archéologiques. Cependant, l’équipe de recherche s’est montrée réticente à cette
solution pour différentes raisons qui seront développées ci-dessous. Les attentes des
utilisateurs se définissent en partie par rapport aux expériences SIG qui ont été faites
auparavant, d’autres ont été identifiées lors des entretiens avec les personnes participant au
projet GEOMAR.
Plusieurs stagiaires ont déjà contribué aux projets géomatiques au sein du CEAlex. Ces
interventions ont visé le développement d’un SIG de la ville d’Alexandrie. Une série de stages
a mené à la digitalisation du plan cadastral alexandrin, son croisement avec des données
archéologiques et à la conversion de données sous MapInfo vers ArcGis. L’ensemble de ces
évolutions est resté très informatique destiné aux utilisateurs habitués aux logiciels de
cartographie. Ceci a posé des problèmes à différents niveaux : l’utilisateur du SIG devait bien
connaitre le logiciel (au début du stage, seulement ArcGis était utilisé) afin de le manipuler ; il
devait en plus avoir une connaissance de la structure des tables attributaires et leurs liens afin
d’exploiter les données et de les croiser ; finalement, le nombre de licences étant restreint, la
12
diffusion du SIG et son utilisation sur le terrain étaient très limitées. La solution d’utilisation
du SIG en dehors des bureaux de topographie s’est faite par export des cartes en format PDF.
Ici apparait aussi une problématique supplémentaire qui concerne l’utilisation de différents
systèmes informatiques au sein du CEAlex. La plupart des archéologues travaillent sur des
environnements Macintosh alors que le service topographique reste sur des ordinateurs
Windows. Une installation d’ArcGis sur les Macs s’avère difficile à mettre en place. Un des
objectifs principaux du SIG GEOMAR est de s’adresser à un public plus large que ses
précédents. L’utilisation du SIG par des non-informaticiens doit être facile et une diffusion
d’une partie des données par le web doit être envisagée.
Au début de l’intervention, il a alors été proposé de construire le SIG en ligne. Un webSIG
permettrait une très bonne adaptation de l’interface et des interrogations complexes.
Néanmoins, cette solution a rapidement été mise de côté pour des différentes raisons. Tout
d’abord, l’entretien d’un webSIG aurait été compliqué après le départ du stagiaire. Le service
informatique s’occupe de l’entretien des machines ainsi que de l’installation des logiciels
mais ne dispose pas de connaissances de programmation. Le programme GEOMAR est loin
d’être terminé, la base de données continue d’être alimentée et de nouveaux sites viendront
très probablement s’ajouter au corpus existant. Le SIG nécessitera alors des mises à jour
régulières. L’équipe topographique doit être capable de modifier le programme en cas de
problèmes.
Aussi, la connexion internet n’étant pas toujours très bonne et surtout pas fiable à Alexandrie,
un webSIG ne serait pas forcément toujours accessible aux utilisateurs. Certains archéologues
pensent qu’une version portable sera nécessaire au travail sur le terrain cependant cet aspect
reste discuté au sein de l’équipe de recherche. Néanmoins, il faut envisager l’utilisation du
SIG hors connexion internet.
Enfin, le SIG GEOMAR comprendra un grand nombre de données de différents types qui
seront relativement lourdes. L’ensemble des photos se trouvant dans la base de données a un
volume de 5 GO, les cartes anciennes et images satellitaires sont d’environ 8 GO, les couches
vectorielles et les métadonnées sont de taille moins importante. Par conséquent, le webSIG
serait très chargé et peu réactif avec une connexion moyenne.
Des solutions fixes ont alors été envisagées. Le CEAlex souhaitait que le SIG soit développé
sous ArcGis comme il a également été mentionné dans le cahier de charges qui a été constitué
avant le début de stage. Ce souhait est lié aux habitudes de travail de l’équipe et aux
infrastructures qui existent déjà dans les bureaux. Construire un SIG sous ArcGis
comprendrait l’organisation des données dans une géodatabase. Cependant cette structure
native de stockage de données d’ArcGis reste limitée. La question de savoir si ArcGis sera
assez puissant pour exploiter l’ensemble des données présentes, a été vérifiée. Il s’agit d’une
question centrale de la première partie du stage. Le choix de supports informatiques du SIG
doit satisfaire les commanditaires. Analyser l’ensemble des besoins et présenter les solutions
répondant à l’ensemble des attentes est alors important. Les différentes solutions envisagées et
les choix qui ont été faits seront présentés dans la partie suivante.
13
Données archéologiques et SIG Le SIG GEOMAR doit relier les informations rassemblées dans une base de données existante
aux données géographiques et cartographiques. De manière générale, les bases de données
archéologiques du CEAlex sont réalisées à l’aide du programme FileMaker Pro (FMP).
Il s’agit d’un programme relativement facile d’accès qui offre une interface parlante, c’est
pourquoi il est souvent utilisé quand un spécialiste de base de données n’est pas présent. Une
archéologue au sein du CEAlex s’occupe de la construction des bases de données. Au début
du stage, le transfert de la version FMP 11 vers la version FMP 14 était en cours. En outre,
l’installation de la version serveur était prévue pendant la durée du stage. Jusque-là, chaque
membre de l’équipe de travail dispose d’une licence « ordinateur » qui lui permet à la fois de
consulter et de manipuler les bases de données installées sur son poste. Les bases de données
qui sont renseignées par plusieurs personnes sont transmises sur des disques durs externes
sachant qu’il existe toujours une version la plus actuelle et les ajouts n’ont du sens que sur
cette unique version. L’installation d’une version serveur du logiciel est donc une grande
avancée. Cependant, le développement du SIG s’est orienté au travail de l’équipe sous FMP
14 mais sans l’accès au serveur dont l’installation n’a pas été finalisée pendant mon stage.
BdD GEOMAR La base de données GEOMAR est une base relationnelle qui comprend seize (16) tables dans
FMP. La table « SIT_Sites » se trouve au centre de la base de données comme nous pouvons
le voir dans la représentation ci-dessous générée par FMP. Elle comprend les informations
basiques sur les sites archéologiques. Toutes les autres tables dépendent d’elle. Pendant les
premiers rendez-vous avec l’équipe GEOMAR, nous avons traité la question de savoir quelles
données doivent être transférées dans le SIG et utilisées pour les requêtes. La première
réponse était alors « tout ». Les archéologues souhaitent pouvoir interroger la base de données
sur tous les enregistrements. Cependant, il s’est montré que la table « Toponymie » n’a pas
été renseigné et ne le sera pas dans un temps proche. Etant vide, cette table ne sera alors pas
transmise au SIG. De même, la table « visites » n’est pas conservée pour le SIG, les
chercheurs ont décidé qu’elle ne présentait pas d’intérêt pour les requêtes à mener. De plus,
nous trouvons plusieurs tables vides marquées en gris ci-dessous, elles servent à créer la mise
en page dans FMP et ne sont pas réutilisées dans le SIG.
14
Figure 2 : Structure de la base de données GEOMAR dans FilemakerPro
15
L’export Les données se trouvant en FMP doivent être liées à la composante spatiale. Une manière
efficace d’exporter les données doit être trouvée qui permet de garder les liens entre les tables.
La base de données GEOMAR sous Filemaker Pro, étant construite avec une organisation et
une interface bien connue par l’équipe, va continuer d’être utilisée. Le SIG ne servira pas pour
la saisie des données qui seront exclusivement chargés à partir de FMP. Saisir les données
dans les deux structures, base de données FMP et SIG, mènerait probablement à une
confusion parce qu’on ne saurait plus quelle donnée a été saisie dans quel logiciel. Le SIG
serait alors actualisé à partir de FMP, les retouches sur les couches vectorielles seront quand
même possibles. Il a été estimé que les actualisations se feront deux à trois fois par an.
Plusieurs possibilités de transfert de données ont été envisagées.
Une première solution est proposée par le support de FMP. Il s’agit d’une connexion ODBC
(Open Database Connectivity) qui permet de créer un lien direct entre FMP et une base de
données extérieure. Un driveur ODBC doit être installé et paramétré sous FMP. Par la suite,
les données pourraient être tirées vers le programme choisi pour le SIG. Une série d’essais et
une recherche approfondie sur internet ont montré des résultats relativement décevants.
Effectivement, le transfert de données via une telle connexion est possible mais s’avère plus
compliqué que cela a été décrit par FMP. FilemakerPro présente un large panorama de
formats utilisables qui n’existent pas tous dans d’autres types de bases de données. Les
formats de calcul, date etc. ne sont pas bien supportés par les programmes récepteurs. Des
tables sont partiellement exportées mais restent en majeure partie vides. Quelques colonnes
sont doublées parce que les liens entre tables semblent être mal interprétés lors du transfert.
En plus, nous n’avons pas de choix sur l’export des colonnes. Si un transfert de la table a lieu,
toutes les colonnes, utiles ou pas, sont transmises.
Ces problèmes que nous avons rencontrés sont également décrits par les utilisateurs en ligne.
Il peut en partie s’agir d’un problème de choix de logiciel. Nous utilisons PostGreSQL pour
les essais cependant FMP soutient officiellement les connexions vers Oracle, MySQL et
Microsoft SQL Server. S’agissant de logiciels payants, non disponibles au CEAlex, nous
n’avons pas pu faire des essais d’export vers ces logiciels. Des programmes de support de
transfert de données entre FMP et des programmes de bases de données SQL sont également
proposés en ligne. Le transfert de données semble être un problème bien connu et traité par le
marché des logiciels. Toutefois, l’achat des tels logiciels est relativement coûteux et la prise
de décision et la mise en place de tels achats dépassait la durée du stage.
Une deuxième solution est proposée par le support d’ArcGis. Le programme propose de
connecter les bases de données FMP directement aux logiciels d’ArcGis via une connexion
OLE DB. Cette connexion se sert également du serveur ODBC. Elle permet d’afficher les
tables de la base de données en ArcCatalogue. Cependant, la connexion reste fragile. Elle se
défait rapidement et doit être renouvelée au redémarrage de l’ordinateur. La majeure partie
des tables sont vides, une partie des tables n’est pas importée. Tous les problèmes qui ont été
décrits plus haut se posent lorsqu’on utilise l’OLE DB entre FilemakerPro et ArcGis. En
raison de l’ensemble de ces problèmes, nous avons abandonné cette voie. Pourtant, la
16
connexion OLE DB peut être très utile dans certains cas. Nous la retrouverons un peu plus
loin dans nos recherches.
A la recherche d’une solution, nous avons également fait appel aux expériences de personnes
qui ont déjà été confrontées aux mêmes problèmes. Ainsi, les rapports de stage de l’Ecole
française d’Athènes (institut archéologique) et des forums sur internet ont été consultés. De
même Carine Calastrenc, archéologue-sigiste à l’Université de Toulouse a été interrogée sur
ses habitudes de travail concernant la migration de données depuis FMP. Ces recherches nous
ont montré que la manière la plus facile et sûre de transmettre les données serait d’exporter
des fichiers excel ou CSV depuis FMP et de les injecter dans une base de données dont la
structure de base aurait été créée sous un logiciel de base de données SQL. Cette possibilité
nous semble efficace en raison du nombre relativement peu important des tables à transmettre.
Cependant, un travail important de triage des données dans les tables doit précéder leur
exportation. Dans FMP, nous pouvons sélectionner les colonnes d’une table qui doivent être
exportées. Le tri a été fait lors d’une première exportation. Nous disposons ainsi d’une liste de
colonnes retenues et le travail peut se faire plus rapidement.
Structure de la nouvelle base de données
Figure 3 : MCD de la base de données du SIG GEOMAR
La nouvelle base de données SIG va relier les tables exportées sous FilemakerPro à la couche
vectorielle cartographique « geomar_sites » présentant l’emplacement des sites
archéologiques qui se trouve au centre du SIG. La plupart des tables sont liées par des
relations « 1,1 » d’un côté et « 0, N » de l’autre, comme nous le voyons sur la représentation
ci-dessus. C’est la raison pour laquelle il n’existe qu’une table intermédiaire.
17
Pour reconstruire la base de données du SIG, nous proposons deux solutions :
Une géodatabase sous ArcGis, directement exploitable par ArcMap
Une base de données PostGreSQL qui avec son extension PostGis est exploitable sous
QGis et en ArcMap
Ces solutions seront discutées dans ce qui suit.
ArcGis Dans ArcGis, nous pouvons créer une géodatabase qui regroupe les données attributaires liées
au SIG. « La géodatabase est la structure de données native d'ArcGIS et le principal format de
données utilisé pour la mise à jour et la gestion des données »11. Elle « est un ensemble de
jeux de données géographiques de différents types stockés dans un dossier système de fichiers
commun […] utilisant principalement un système de gestion de bases de données (SGBD) ou
un système de fichiers »12. Cependant, la géodatabase dispose de fonctionnalités SQL
limitées.
Trois types de géodatabases existent :
11 http://desktop.arcgis.com/fr/desktop/latest/manage-data/geodatabases/what-is-a-geodatabase.htm, 20.04.2016 12 Ibid.
18
Figure 4 : Comparaison des trois types de géodatabase
Avec la licence Desktop dont nous disposons au
CEAlex, nous avons accès à la géodatabase
personnelle et à la géodatabase fichier. La
géodatabase d’entreprise est réservée aux licences
serveur bien que la documentation d’ESRI reste
floue à ce sujet. L’image ci-dessus synthétise les
différences entre les trois géodatabases qui
peuvent être utilisées dans ArcGis. La géodatabase
personnelle, étant limitée à une taille de stockage
en 250 et 500 MO, ne correspond pas à nos
besoins parce que les tailles de fichiers dépassent
largement la limite de stockage comme nous
l’avons vu plus haut dans la description des
données. La géodatabase fichier est mieux adaptée
à nos besoins de stockage car elle peut atteindre
une taille de 1 TO. Chaque jeu de données est
stocké en tant que fichier dans un emplacement de
la géodatabase. Nous pouvons y intégrer des tables
Excel exportées de FMP et les relier aux couches
shapefile. Pourtant, les requêtes multi-tables se
Figure 5 : Fenêtre SQL dans ArcGis
19
montrent difficiles. La structure de requête d’ArcGis nous impose de faire une requête sur une
table à la fois.
L’interface ArcGis nous propose de sélectionner « tout » dans la table ouverte comme la
syntaxe l’indique :
SELECT * FROM ___ WHERE :
Nous ne pouvons pas sortir de cette syntaxe prédéfinie pour interroger la géodatabase sur les
données croisées entre plusieurs tables. A partir de la sélection qui est faite dans une table,
nous pouvons aller dans une table liée puis ajouter une autre sélection, mais il s’agit ici
d’actions manuelles qui peuvent être menées dans ArcMap. Une version automatisée de la
requête multi-tables n’existe pas sous ArcGis.
Il serait possible de contourner ce problème par une programmation en langage python qui
combine une fonction curseur et une fonction SQL. Cette voie n’a pas été poursuivie pour
différentes raisons. Premièrement, nous avons seulement trouvé des exemples de croisement
de deux tables. Aucun exemple ne traitait plus de deux tables à la fois. Ensuite, il s’agit d’une
solution relativement compliquée et encapsulée pour une problématique simple. Les requêtes
SQL se trouvent au centre de l’utilisation du SIG. Il n’est pas envisagé de traiter cette
problématique principale par une solution provisoire.
D’autres complications se sont ajoutées à l’utilisation de la géodatabase, liées au format de
données dans la BdD à transférer. Dans la base de données GEOMAR se trouvent beaucoup
de champs descriptifs sans limitation de la taille du texte. La géodatabase d’ArcGis limite les
champs de texte à 255 caractères. Nous pouvons créer à la main des tables contenant des
champs de texte plus importants, mais nous ne pouvons pas importer des tables entières
contenant des textes longs. Ces champs ne sont pas reconnus par ArcGis. Une alternative
serait alors d’exporter ces champs un par un et de les injecter dans le SIG via l’identifiant du
site archéologique, mais cette solution est très laborieuse. De ce fait, elle ne semble pas être
adaptée aux mises à jour qui auront lieu dans l’avenir. Un champ de texte long se trouve dans
pratiquement chaque table de la BDD et chaque table concerne 105 sites, voire plus dans le
futur. Les transferts de texte prendraient alors beaucoup de temps, ils pourraient également
devenir source d’erreurs.
PostGreSQL / PostGis A cette étape, il a fallu constater et transmettre aux commanditaires qu’il était difficile
d’exploiter un ensemble de données complexes sans utiliser un réel logiciel de base de
données. L’installation d’un tel logiciel supplémentaire était alors nécessaire afin de bien
rassembler et exploiter les données du SIG. Nous avons choisi de construire la base de
données dans PostGreSQL. Il s’agit d’un logiciel gratuit, ce qui a été important au moment de
la constitution de la base de données ; on se trouvait toujours dans une phase exploratoire et la
décision pour ou contre l’utilisation d’une géodatabase n’était pas encore prise. PostGreSQL
présente d’autres avantages au-delà de sa gratuité : grâce à son extension PostGis,
PostGreSQL gère des formats spatiaux et peut intégrer des fichiers shapefile dans la base de
20
données ce qui nous permet de créer un lien direct entre métadonnées et cartographie. De
plus, nous avons la possibilité d’automatiser un grand nombre de processus à l’aide des scripts
préenregistrés. Par exemple, nous avons écrit un script qui construit toute la structure de la
BdD et remplit les tables à l’aide des fichiers CSV que nous avons exportés de FMP. Les
mises à jour se feront de la même manière. Les tables CSV pour peupler et mettre à jour la
BdD doivent être déposées à un endroit précis puis, le script les importera directement dans la
base de données. Les documents CSV peuvent être supprimés par la suite. Ceci présente un
atout important parce qu’il n’y pas de spécialiste BdD au CEAlex. De ce fait, il est positif
d’automatiser un maximum de processus.
PostGis - Qgis PostGreSQL s’intègre facilement dans QGis par son extension PostGis. Les deux
programmes interagissent par plusieurs voies. D’un côté, nous pouvons directement ajouter
des couches vectorielles à partir d’une BdD PostGis. De l’autre côté, nous pouvons nous
connecter à l’ensemble de la base de données par le gestionnaire de base de données. Ce
deuxième point nous permet également de créer des requêtes attributaires complexes. Nous
pouvons créer des vues à partir des résultats de ces requêtes ou charger une couche temporaire
dans l’espace de travail ouvert. Cette dernière fonction nous intéresse spécialement. Le SIG
GEOMAR doit permettre d’afficher des sites archéologiques à partir d’une sélection
attributaire. Cela correspond aux fonctionnalités de la fenêtre SQL dans le gestionnaire de
base de données QGis.
Au moment de la connexion de la base de données PostGreSQL à QGis, le SIG GEOMAR
dans sa version la plus simple existe déjà. Maintenant, il faut réfléchir à l’interface
d’utilisation. Ici, nous rencontrons une problématique importante qui est le choix du logiciel
d’utilisation du SIG. Il a été mentionné plusieurs fois que l’équipe du CEAlex voulait
continuer de travailler sur ArcGis. Cependant, lors des recherches sur les possibles
connexions entre la BdD et le SIG, il a été proposé de travailler avec QGis. Ceci est entré
dans une discussion qui s’est révélée ancienne sur l’utilisation des logiciels et qui n’a pas été
soulignée au début du stage. Effectivement, certains membres du CEAlex ont proposé de
changer complètement vers QGis, d’autres ont souhaité continuer de travailler sur ArcGis. Il
s’agit en grande partie de questions financières et d’habitudes de travail, mais aussi des
expériences qui ont été rapportées par des collègues d’autres centres archéologiques. Un débat
sur un possible changement de logiciel s’est alors déclenché.
Plusieurs points seraient favorables à l’option QGis. C’est un programme gratuit qui pourra
être distribué aux collègues du CEAlex sans problèmes de licence. Contrairement à ArcGis,
QGis est compatible avec les systèmes Macintosh. De même, le logiciel est plus léger
qu’ArcGis et tournera mieux sur les machines anciennes ou les portables de travail qui
peuvent être emmenés sur le terrain. Le logiciel est également très flexible. Développé par des
développeurs pour des développeurs, QGis comporte un grand nombre de composantes
dédiées à la personnalisation du logiciel. La suite QtDesigner permet une adaptation de
l’interface utilisateur de QGis, elle est téléchargée avec la version standard du programme.
L’installation de son équivalent dans ArcGis a pris des semaines en raison des hiérarchies et
21
de licences ESRI. Toutes les solutions d’adaptation de l’interface d’ArcGis se réfèrent
généralement à des programmes payants qui peuvent être lourds à télécharger (Visual Studio
notamment). QGis par contre, propose des solutions qui sont gratuites. En plus, leur
utilisation a été prévue dans la conception du logiciel SIG. L’utilisation de QGis rendra le
service topographique alors plus autonome et flexible.
Cependant, il a fallu prendre en compte que des fichiers très lourds peuvent parfois poser des
problèmes à QGis. Pour des très gros fichiers, ArcGis serait alors plus stable. L’installation de
QGis et de son partenaire PostGreSQL demanderait également un temps et une organisation
supplémentaire. L’interface et l’organisation du logiciel devraient également être acquis par
les cartographes. Un choix entre les deux solutions devait alors être fait.
PostGis - ArcGis Ici, nous devons mentionner que la base de données GEOMAR dans PostGis est également
utilisable dans ArcMap. La connexion OLE DB qui a été mentionnée plus haut peut être
établie entre ArcGis et PostGis. Les problèmes rencontrés lors d’une connexion à la base de
données FMP ne se posent pas parce que le format de base de données SQL est bien supporté
et interprété par ArcGis. Les tables sont alors complètes et les liens entre tables persistent.
Cependant, nous allons voir que la connexion est moins stable que son équivalent sous QGis.
Premièrement, seulement peu de fonctions se servant de cette connexion existent sous ArcGis.
La fonction « Make Query Layer » est le principal outil utilisant cette connexion. Il permet
une sélection SQL multi-table et importe une couche vectorielle comportant les polygones
triés selon la requête attributaire. C’est la même fonctionnalité que nous trouvons également
dans le gestionnaire de base de données dans QGis. Cependant, il n’y a pas de possibilité de
créer des vues ou d’accéder autrement que par le « Make Query Layer » à la base de données.
Elle permet d’afficher les couches shapefile et les tables de la base de données, mais elle ne
permet pas de les interroger de manière exhaustive.
En plus, pendant l’utilisation de la connexion OLE DB, le programme mère de la base de
données doit être ouvert tout le temps. Si PgAdmin n’est pas ouvert, la connexion ne peut pas
être établie. Si PgAdmin est fermé pendant que la base de données GEOMAR est utilisée en
ArcGis, les données sont perdues dans l’espace de travail ArcMap. Ces mêmes problèmes ne
se posent pas quand on exploite PostGis en Qgis. L’ensemble des avantages et des
inconvénients de l’utilisation de QGis et ArcGis est présenté ci-dessous.
22
ArcGis QGis
Avantages
Connu
Stable
Puissant avec les licences nécessaires
OLE DB
Avantages
Gratuit
Souple
Installation sur Mac
Bonnes possibilités d’exploitation de
PostGis
Interface intuitif
o Les mêmes fonctionnalités qu’en
ArcGis existent mais l’interface
doit être apprise
Inconvénients
Géodatabase insuffisante pour les besoins
du SIG GEOMAR
Lien OLE DB contraignant
Inconvénients
Formation nécessaire
L’ensemble des éléments et considérations nous ont menés au choix de QGis. La souplesse du
logiciel constitue un point décisif autant que la possibilité d’installation sur Mac. Les deux
chercheurs travaillant davantage sur le SIG sont divisés entre les deux systèmes
informatiques. L’un, travaillant sur Windows, avait la main sur les couches vectorielles.
L’autre, travaillant sur Mac, se servait jusqu’alors des exportations en format AI qui étaient
affichées en Adobe Illustrator. Ce logiciel propose des traitements géographiques très limités
et tous les changements faits sur Illustrator devaient être refaits par le collègue dans ArcGis.
Nous espérons que l’utilisation de QGis facilitera les échanges de travail dans le futur.
Cependant, l’actualisation du travail de l’un par l’autre reste évidemment un défi.
En résumé, le schéma ci-dessous montre l’ensemble des composantes et traitements qui feront
partie du SIG :
Figure 6 : Schéma de processus FMP vers le SIG
Une fois que le choix d’un des logiciels a été définitif, nous avons avancé vers le
développement d’une interface convenable comme nous allons le voir en troisième partie.
23
Interface SIG : possibilités et résultats Dans l'idéal, l'interface du SIG GEOMAR devrait être une fenêtre personnalisée dans QGis
qui propose des choix selon les rubriques existantes dans la base de données. Une telle
interface permet d'interroger la base de données sans devoir saisir du SQL. Elle serait
également inspirée par l'interface qui existe déjà dans FilemakerPro. Certaines données étant
des booléens pourraient être cochées pour savoir si elles sont renseignées dans la base de
données ou non. Ceci concerne surtout les données paléo-environnementales. D'autres
recherches se feront par liste déroulante, une très grande partie des recherches se fera
également en écrivant des mots clés qui se trouvent dans la base de données. Les dessins ci-
dessous rendent compte des idées envisagées pendant la durée de stage.
Figure 7 : Conceptions graphique d'une fenêtre d'interrogation du SIG (1)
24
Figure 8 : Conceptions graphique d'une fenêtre d'interrogation du SIG (2)
La base de données, contenant un très grand volume de données, est séparée en plusieurs
sous-parties. Pendant la requête, on pourrait alors également afficher et cacher les parties de la
base de données pertinentes ou pas. Il serait également intéressant d’intégrer un choix pour
une requête AND ou OR, donc pour savoir si l’ensemble des choix doivent être vrais pour la
réponse. De même, il faudra réfléchir à l’interface de présentation des résultats de la requête.
La conception graphique est rapidement trouvée parce qu’elle s’inspire à la base de données
déjà existante. La fenêtre peut être créée dans Qt Designer, programme complémentaire de
QGis. Les prototypes ci-dessus ont été générés à l’aide d’un programme de dessin. La vraie
problématique est de relier l’interface à la base de données et aux fonctionnalités de QGis.
Dans ce qui suit, nous allons présenter les solutions envisagées et les difficultés rencontrées.
Ces solutions sont différentes par leur interface mais aussi par le format de stockage des
couches vectorielles que j’appelle contextuelles. Dans un premier temps, nous avons envisagé
de garder ces couches vectorielles ainsi que les cartes anciennes (sous format raster) dans un
dossier à part qui serait lié à l’espace de travail enregistré sous QGis. Cette démarche vise à
25
alléger la base de données. Cependant, il est apparu qu’il peut être intéressant d’intégrer les
couches vectorielles contextuelles dans la base de données et de réaliser toutes les requêtes
spatiales en langage SQL également. Les solutions proposées pendant la période de recherche
sont synthétisées dans le tableau ci-dessous et décrites plus précisément par la suite.
Solution interface Stockage des couches vectorielles
Modeleur graphique pour les traitements spatiaux et un
plugin pour les requêtes attributaires
Dans un espace de travail
Plugin pour les requêtes spatiales et attributaires Dans la base de données ou dans
l’espace de travail
Solutions tiers, donc un plugin de QGis existant facilitant
les requêtes à mener
Dans la base de données
Les solutions d’adaptation de l’interface du SIG sont présentées de manière chronologique
dans l’ordre dans lequel elles ont été étudiées pendant le stage.
Modeleur graphique et plugin D’abord, nous avons envisagé de développer un plugin pour les requêtes attributaires et
d’utiliser un modeleur graphique pour les requêtes spatiales. Le modeleur graphique est
l’équivalent du model builder dans ArcGis. Ceci a semblé être la solution la plus facile et
rapide pour créer une interface pour les traitements spatiaux qui pourraient par la suite être
combinés avec le plugin, à la recherche attributaire. Le modeleur graphique permet
d’automatiser des fonctions complexes qui comprennent plusieurs étapes comme par exemple
la création de buffer (zone tampon) autour des objets et la sélection spatiale d’une deuxième
couche sur ce buffer. Dans notre cas, il a été testé de modeler une telle démarche avec jusqu’à
cinq tampons à la fois. Un tel modeleur graphique permettrait aux archéologues d’identifier
des sites qui se trouvent à une distance donnée de plusieurs structures « contextuelles » (puits,
ruines, lac etc.). Effectivement, la création d’un modeleur se fait relativement rapidement et
donne des résultats corrects. Ci-dessous, nous voyons un modèle développé dans le cadre du
stage, d’abord sa structure dans le modeleur puis son interface à l’utilisation. Pour des raisons
de lisibilité, nous présentons ici un modèle qui comprend deux couches contextuelles,
cependant nous avons fait des essais qui prennent en compte jusqu’à cinq couches comme
cela a été demandé par les archéologues.
Le schéma montre les étapes que comprend le modeleur : la saisie de couches contextuelles,
la définition de la distance du tampon (buffer), la création d’un tampon qui sera supprimé à la
fin de la chaîne de traitements et la sélection spatiale qui affiche les sites GEOMAR qui
intersectent avec les tampons. Les données en entrée sont saisies dans QGis, comme présentée
sous le Schéma.
26
Figure 9 : Etapes du modeleur graphique dans QGis
Figure 10 : Interface utilisateur du modeleur graphique
De manière générale, notre modeleur marche mais il se pose un problème. Le tampon qui est
créé autour des polygones est généré dans l’unité par défaut du système de coordonnées dans
lequel les couches sont projetées. Dans notre cas, c’est du WGS84, son unité par défaut est le
degré décimal ce qui correspond à environ 111 319,9 mètres. Il faut alors convertir les degrés
décimaux en mètres, voire kilomètres. C’est la raison pour laquelle il a été envisagé d’inclure
un calcul dans le modeleur ou de reprojeter les couches à l’intérieur du modeleur. Il a été
exclu de changer la projection pour un autre système de coordonnées, parce qu’il s’agit d’un
choix fait par l’ensemble du groupe de chercheurs. Il n’est pas nécessaire d’exposer
27
l’ensemble des raisons ici. Nous avons alors cherché une nouvelle solution pour transformer
la valeur en entrée du tampon. La solution a paru simple au début de la recherche car le
modeleur graphique offre un outil qui s’appelle « calculatrice arithmétique » et qui est destiné
à l’intégration des calculs dans le modeleur. Malheureusement, la calculatrice rencontre des
problèmes et ne reconnait jamais les variables en entrée. Il n’existe pas de documentation sur
ce problème. Seulement très peu de questions ont été posées sur ce sujet dans les forums, elles
sont restées sans réponse. Après avoir contacté une personne qui avait soulevé ce problème
dans un forum il y a cinq ans et qui n’a jamais fait marcher cet outil de QGis, l’idée a été
abandonnée. Alors nous avons réfléchi à reprojeter les couches à l’intérieur du modeleur pour
les mettre dans un système de projection qui utilise l’unité mètre ou kilomètre, mais cela pose
également des problèmes. Il semble que les couches sont reprojetées mais la sélection spatiale
ne s’effectue pas.
Finalement, nous avons décidé de réaliser les géotraitements dans la base de données PostGis.
Ici, nous pouvons créer des buffers, mesurer des distances etc. à l’aide des expressions SQL
dans lesquelles nous pouvons inclure des calculs. Ces essais nous ont menés à une étape
suivante de réflexions.
Plugin Nous pouvons intégrer la totalité des couches vectorielles dans la base de données PostGis et
mener des requêtes spatiales entre ces couches. A la place de créer des buffers et de faire une
sélection sur ces nouveaux polygones, nous pouvons directement utiliser la fonction
ST_DWithin de PostGis. Elle sélectionne tous les polygones qui se situent à l’intérieur d’une
distance définie autour d’une autre couche. L’exemple ci-dessous sélectionne tous les sites qui
se trouvent à un kilomètre des puits renseignés sur la carte de l’atlas de l’Egypte en 1914.
SELECT DISTINCT ON (geomar_sites.geomar) geomar_sites.geomar,
geomar_sites.nom, geomar_sites.geom, FROM geomar_sites,
"1914_atlas_puits" WHERE ST_DWithin("1914_atlas_puits".geom,
geomar_sites.geom, (1/111,3199)) ;
L’exemple inclut un calcul qui convertit les degrés décimaux en kilomètres. De même,
PostGis sélectionne certains polygones plusieurs fois parce qu’ils se trouvent à proximité de
plusieurs puits. C’est pourquoi nous utilisons la fonction SELECT DISTINCT ON. Les
doublons de polygones sont alors regroupés sur la base du champ défini entre parenthèses.
Les requêtes en SQL peuvent être intégrées dans les scripts en python. Le Python est un
langage de programmation orienté objet qui est beaucoup utilisé de nos jours, notamment par
les applications de QGis. C’est la raison pour laquelle il a été envisagé de créer un Plugin qui
sera réservé à l’utilisation interne au CEAlex. Grâce au PluginBuilder de QGis, nous pouvons
créer la structure de base du plugin sans problèmes. Une fenêtre d’interrogation est créée à
l’aide du logiciel Qt Designer qui est installé avec la version basique de QGis. Malgré cette
aide à la construction d’un Plugin, il faut avoir une très bonne connaissance du langage
Python, mais aussi de l’algorithmique et de l’organisation des classes et des héritages à
l’intérieur du plugin à construire. Après un temps assez long d’essais et d’appropriation de
l’outil PluginBuilder, nous avons réussi à réaliser quelques fonctionnalités très simples, par
28
exemple choisir une couche parmi les couches activées dans l’espace de travail ouvert. Des
exercices plus complexes comme la connexion à une base de données n’ont pas pu être
modelés, sans penser aux requêtes à mener par la suite. En raison du temps passé et en
regardant la complexité du développement qui restait à faire, j’ai pris la décision de laisser de
côté le développement d’un plugin afin de trouver des solutions qui seraient prêtes à
l’utilisation à la fin de mon stage. Nous avons alors dû trouver des compromis qui seront
utilisés jusqu’à ce que le projet SIG GEOMAR soit davantage développé. Contrairement à ce
que j’avais souhaité faire en début de ma recherche, je me suis tournée vers des solutions tiers
déjà existantes en QGis.
Solutions tiers en QGis Dans QGis, il existe plusieurs plugins et fonctions pour accéder à une base de données
PostGis et l’interroger. L’outil le plus simple ne fait qu’ajouter une couche PostGis dans
l’espace de travail ouvert, d’autres plugins plus complexes peuvent être installés. Une
sélection de plugins qui ont été testés dans le cadre du stage, se trouve ci-dessous.
DB Manager
eVis
PostGis query builder
PostGis SQL query editor
Le DB Manager est un outil qui est aujourd’hui installé par défaut dans QGis. Il s’agit d’un
outil indispensable permettant de gérer la base de données à partir de QGis, d’exporter et
importer des shapefiles, de traiter les fichiers de la base de données directement dans QGis.
En plus, le DB Manager contient une fenêtre SQL permettant d’interroger la base de données
par des requêtes ; une aide à la construction de requêtes attributaires et spatiales est également
fournie. De ce fait, le DB Manager constitue l’outil le plus complexe bien que son interface
reste très technique. Pour l’utilisateur lambda, il est alors nécessaire d’avoir une introduction à
la gestion de base de données et à l’utilisation du SQL.
L’outil eVis facilite la visualisation de photos dans QGis. Pour cela, eVis se sert des chemins
d’accès. Les images se trouvant à l’emplacement enregistré sont visualisées avec d’autres
métadonnées de la couche projetée. L’utilisation d’eVis a été d’abord rejetée parce que la
transmission de la base de données d’un ordinateur engendrait un changement du chemin
d’accès et alors, un travail de préparation supplémentaire était nécessaire si on voulait changer
les chemins d’accès des images à chaque utilisation. Cependant, nous allons voir que
l’extension eVis a gagné en importance avec l’installation d’un serveur de bases de données
en fin de stage. L’utilisation d’eVis sera décrite davantage par la suite.
PostGis query builder constitue un moyen d’interroger une base de données par des requêtes
spatiales sans entrer du code SQL. Malheureusement, cet outil se limite aux requêtes
spatiales.
PostGis SQL query editor permet d’entrer une requête SQL et de charger son résultat dans
l’espace de travail sans passer par le DB Manager. L’interface est très simple et rapide
29
d’accès. En dehors de sa simplicité, cet outil ne présente pas d’avantage comparé au DB
Manager.
D’autres plugins pour PostGis existent dans QGis mais ne sont pas présentés ici. Il faut retenir
qu’un grand nombre de possibilités existent mais qu’ils ne regroupent jamais tous les critères
désirés, dont la combinaison entre requête attributaire et spatiale, sans écrire en SQL. C’est la
raison pour laquelle nous avons finalement choisi de former l’équipe de chercheurs travaillant
sur GEOMAR à l’utilisation basique du langage SQL. Il a été choisi de travailler dans le DB
Manager parce qu’il donne l’accès visuel à la base de données et il permet d’afficher le
contenu des tables en cas de besoin. La formation de l’équipe a également constitué un
exercice intéressant pendant le stage. La préparation de supports, la structuration d’un cours et
la transmission de savoir ont été une nouvelle expérience pour moi. Aussi, la décision de
renoncer au développement d’un plugin avec une interface personnalisée pour le moment a
défini les objectifs pendant le dernier mois de stage. Une future intervention d’un stagiaire, en
informatique par exemple, est envisagée. Les résultats existants ont dû être rangés, des guides
d’utilisateurs13 ainsi qu’un cahier des charges pour la personne suivante ont dû être rédigés et
la formation des chercheurs a été organisée. Cette formation a compris l’utilisation de QGis
de manière générale et l’utilisation du SIG, principalement la base de données en QGis. Un
catalogue de requêtes en SQL et un catalogue de messages d’erreur récurrents ont été
constitués pour faciliter la réalisation de requêtes.
Les dernières semaines du stage ont surtout visé le rendu d’un ensemble propre et lisible pour
qu’on puisse facilement travailler avec les résultats actuels et poursuivre le développement
dans le futur.
L’interface des résultats de la requête En résultat d’une requête s’affiche un tableau avec les colonnes que nous avons choisies dans
notre fonction. Ce tableau s’affiche d’abord dans le gestionnaire de base de données, il peut
être enregistré en tant que vue qui peut être intégrée dans l’espace de travail. Il est également
possible d’exporter le résultat au format d’une nouvelle couche. La table attributaire de cette
nouvelle couche comprend les colonnes sélectionnées, il s’agit alors d’un choix personnalisé.
Nous pouvons utiliser les outils habituels de QGis pour afficher les données de la table
attributaires.
Les images dans le SIG En plus et aussi pour cette solution provisoire, les archéologues souhaitent afficher les images
liées aux sites qui se trouvent dans la base de données. L’intégration des images dans le SIG
peut se faire de différentes manières. Depuis le début du stage, il a été question de trouver la
manière la plus adaptée pour afficher les images de la base de données dans le SIG mais dans
le cours de l’avancée du stage, des différentes solutions ont pu être trouvées.
13 Différents guides d’utilisateurs ont été rédigés dont quelques exemples se trouvent dans les annexes : Mise à jour du SIG, Fusion de rasters dans ArcGis, Utilisation du catalogue de requêtes SQL, Cahier des charges pour le prochain stagiaire.
30
Dès le départ, nous avons deux choix pour intégrer les images dans le SIG : nous pouvons
enregistrer les photos dans la base de données ou nous pouvons enregistrer les liens vers les
images soit les chemins vers les fichiers dans la base de données.
La première solution est peu adaptée à nos besoins parce que les images devraient être
enregistrées dans la base de données une par une. Ceci prend beaucoup de temps et nous
rencontrons une fois de plus le problème de la mise à jour de FMP vers PostGreSQL. Une
mise à jour automatique ne sera pas possible. En plus, la base de données risquerait de devenir
très lourde et moins réactive en raison du nombre d’images qui comptent 5 GO dans leur
ensemble à ce jour. Cette solution a rapidement été mise de côté.
La deuxième possibilité pour afficher les images est de se servir des chemins d’accès des
photos. Dans QGis, nous avons deux possibilités d’utiliser les liens vers les photos. Nous
pouvons créer une action « ouvrir l’image » mais qui ne s’applique que pour la couche pour
laquelle elle a été créée. Quand une nouvelle couche est enregistrée ou chargée depuis une
requête de la base de données, il faudrait recréer cette action. La manière la plus adaptée
semble être l’utilisation du plugin eVis qui a été mentionné plus haut. Cette application
reconnait les chemins d’accès et affiche l’image avec les autres informations de la table
attributaire.
Figure 11 : Affichage des métadonnées avec image d'un site archéologique (eVis)
L’application eVis constitue probablement la manière la plus facile d’afficher des photos
d’une couche. Cependant, pour certaines raisons, nous n’avons pas opté pour cette solution
tout de suite. D’un côté, nous avons cherché pendant longtemps une fenêtre tout à fait
personnalisée comme il a été décrit plus haut. Lorsqu’un Plugin d’interrogation avec
31
également un affichage en sortie des métadonnées de chaque site existera, les photos
devraient alors être intégrées dans cette fenêtre du Plugin. EVis s’intègre alors dans la
démarche de trouver des solutions tiers adaptées aux SIG et fera plutôt partie des solutions
provisoires.
D’autre part, les chercheurs ont d’abord été réticents à cette solution parce que les chemins
d’accès aux images sont différents sur chaque poste. A l’actualisation et la transmission du
SIG, l’utilisation des chemins d’accès engendre une préparation des données plus longue. Les
chemins d’accès devraient être adaptés à chaque ordinateur.
Pour ces raisons, nous avions alors déjà mis la solution eVis de côté. Cependant, à la fin du
stage, un serveur à utilisation interne au CEAlex a été installé pour faciliter le partage des
bases de données FMP. La base de données GEOMAR a été installée sur le serveur qui est
accessible par tous les utilisateurs du SIG en intranet. Les images de la BdD y sont stockées
dans des dossiers auxquels nous pouvons accéder depuis le SIG. Nous utiliserons alors les
chemins d’accès vers le serveur qui seront les mêmes de tous les postes. Les chemins d’accès
des images sont enregistrés dans les tables que nous exportons de FMP pour constituer ou
actualiser la base de données. De ce fait, nous pouvons traiter les images comme une colonne
d’une table de la BdD et les afficher dans QGis à l’aide d’eVis.
32
Conclusion Toute la durée de mon stage mais surtout le dernier mois au Centre d’Etudes Alexandrines
m’a fait comprendre certains aspects de la gestion de projets et de la vie en entreprise. J’étais
venue pour un temps limité et avec un cahier des charges bien défini. Cependant, à la fin du
stage, il était moins important d’aller aussi loin que possible dans le cahier des charges que de
s’assurer que le projet sera finalisé un jour à l’aide du travail que j’ai pu réaliser et des
personnes qui viendront après moi. De ce fait, la finalité de mon projet s’est alors transformée
pendant le stage, de la réalisation de la totalité du projet vers la réalisation d’une étape de
travail.
De ce point de vue, la première étape du projet SIG GEOMAR n’a pas seulement consisté
dans la constitution de la base de données mais surtout dans un travail de recherche et de
conseil qui a été important au début du stage. Les différentes possibilités de transfert de
données, la question du stockage des données et la décision entre les deux logiciels SIG
ArcGis et QGis ont déterminé/caractérisé une grande partie de mon stage. Depuis un certain
moment, il avait été prévu de construire un SIG GEOMAR. Cependant, les besoins techniques
n’étaient pas connus. Il a fallu satisfaire les attentes des commanditaires et en même temps
avancer mes propres idées et propositions. En plus, certaines discussions sur les choix de
logiciels ainsi que sur le volume des données à publier ont été déclenchées par ma venue. Il
s’agit de questions qui étaient soulevées depuis longtemps, mais qui étaient mises de côté, tant
qu’elles n’étaient pas urgentes. Mon stage a donc donné lieu à une nouvelle réflexion sur les
outils utilisés mais aussi à la présentation du projet GEOMAR dans le futur.
Dans ces moments de réflexion et prise de décisions, il a parfois été difficile d’être la seule
géomaticienne sur place. Bien qu’il y ait le service topographique dans lequel je travaille ainsi
qu’une collègue archéologue qui est spécialisée dans la constitution de base de données sur
FMP, personne n’a une très bonne connaissance des outils informatiques que j’ai utilisés. De
ce fait, j’ai dû prendre la plupart des décisions toute seule. Quand je les présentais à mes
collègues, j’ai bien sûr entendu des suggestions et des souhaits d’amélioration dont j’ai vérifié
et expliqué leur faisabilité par la suite. Mais finalement, je n’ai jamais pu prendre le conseil
d’un autre géomaticien sur place. De ce fait, j’ai été très autonome et j’avais une certaine
responsabilité parce que personne n’a pu vérifier mes choix. Dans cette position, je me suis
parfois sentie un peu solitaire, mais cette expérience a également été très enrichissante.
Dans l’ensemble, je dois dire que j’ai toujours eu l’impression que les chercheurs du CEAlex
ont fait confiance à mes jugements et à mon travail pendant toute la durée du stage. J’ai pu
travailler en grande autonomie et je n’ai jamais senti de mauvaise pression. Un bon exemple
pour cela est la formation que j’ai organisée à la fin de mon stage.
Mener une formation, et en plus une formation pour des personnes qui sont mes supérieurs au
travail, a été une nouvelle expérience pour moi. D’un côté, j’ai expérimenté toute
l’organisation en amont du cours, donc la recherche de tutoriels, de données adaptées, de
structuration du cours et d’estimation du temps qui serait nécessaire pour les différents
exercices. D’un autre côté, j’étais confrontée aux problèmes et questions souvent inattendues
qu’il a fallu gérer pendant la formation. Pendant la phase de développement du SIG j’avais
33
convaincu l’équipe de l’utilisation des logiciels PostGreSQL/PostGis et de QGis. La
formation était alors aussi le moment pour convaincre qu’on avait fait le bon choix et de
défendre QGis devant les comparaisons avec ArcGis.
De manière générale, mon stage m’a beaucoup appris sur les différents logiciels SIG, leurs
avantages et inconvénients. Ma recherche très poussée sur le transfert de données entre FMP
et un format de stockage du SIG qui n’était pas encore clair au début du stage a élargi mon
regard sur les bases de données. Effectivement, je pense que la connaissance de FilemakerPro
est très enrichissante parce qu’il s’agit d’un logiciel de base de données qu’on va
constamment rencontrer dans les milieux non-informatiques.
34
Table des Figures Figure 1 : La zone d'étude GEOMAR ...................................................................................... 10
Figure 2 : Structure de la base de données GEOMAR dans FilemakerPro .............................. 14
Figure 3 : MCD de la base de données du SIG GEOMAR ...................................................... 16
Figure 4 : Comparaison des trois types de géodatabase ........................................................... 18
Figure 5 : Fenêtre SQL dans ArcGis ........................................................................................ 18
Figure 6 : Schéma de processus FMP vers le SIG ................................................................... 22
Figure 7 : Conceptions graphique d'une fenêtre d'interrogation du SIG (1) ............................ 23
Figure 8 : Conceptions graphique d'une fenêtre d'interrogation du SIG (2) ............................ 24
Figure 9 : Etapes du modeleur graphique dans QGis ............................................................... 26
Figure 10 : Interface utilisateur du modeleur graphique .......................................................... 26
Figure 11 : Affichage des métadonnées avec image d'un site archéologique (eVis) ............... 30
35
Bibliographie
Ouvrages Esposito A., Giorgos M. S. (2012). « Quartiers » artisanaux en Grèce anciennce, Septentrion,
Lille.
Hairy I. (2012). Du Nil à Alexandrie, De Boccard, Paris.
Articles de revues scientifiques Awad, I. (2010). « A study of the evolution of the Maryut Lake through maps ». In Blue L.
and Khalil E. (Eds.), Lake Mareotis: Reconstructing the Past, Proceedings of the
International Conference on the Archaeology of the Mareotic Region Held at Alexandria
University, Egypt 5th-6th April 2008, Oxford, University of Southampton Series in
Archaeology 2, BAR S2113.
Briquet Q. (2012). Mise en place d’un WebSIG de l’île de Délos (Cyclades). Revue
Géomatique Expert, n°87.
Flaux Cl. (2012). Environmental changes in the Maryut lagoon (northwestern Nile delta)
during the last 2000 years. Revue Journal of Archaeological Science, n°39.
Flaux Cl. (2013). A 7500-year strontium isotope record from the northwestern Nile delta
(Maryut lagoon, Egypt). Revue Journal of Archaeological Science, n°78.
Pichot V. (2010). Marea Peninsula: Occupation and Workshop Activities on the Shore of
Lake Mariout in the Work of the Center d’Etudes Alexandrines (CEAlex, CNRS USR 3134).
Revue University of Southampton Series In Archaeology, n°2.
Thèses et rapports de stage Audouard A. (2012). Mise en place d’une Infrastructure de Données Spatiales pour les pays
du Maghreb. Rapport de stage, Université de Toulouse.
Alami S. (2013). Aide à la structuration et à l’utilisation d’un SIG libre au sein d’un bureau
d’études en environnement. Rapport de stage, Université de Toulouse.
Cunault M. (2011). Une carte archéologique du cœur d’Alexandrie. Rapport de stage,
Université François Rabelais.
Flaux Cl. (2012). Paléo-environnements littoraux Holocène du lac Maryut, nord-ouest du
delta du Nil, Egypte. Thèse en géographie, Université Aix-Marseille.
Kuntz C. (1997). Mise en œuvre du S.I.G. alexandrin. Rapport de stage, E.S.G.T.
Larrouture J. (2012). Mise en place d’un SIG pour la réserve nationale d’Arjuzanx. Rapport
de stage, Université de Toulouse.
Ribiere O. (2013). Mise en place d’une Infrastructure de Données Spatiales et création d’un
zonage valléen sur le massif des Pyrénées. Rapport de stage, Université de Toulouse.
36
Séard C. (2015). Réalisation du catalogage des données SIG du Syndicat Mixte des
Transports en Commun de l’Agglomération de Toulouse. Rapport de stage, Université de
Toulouse.
Simony A. (2009). L’export de données : application au SIG Alexandrin. Rapport de stage,
Université François Rabelais.
Sites web consultés régulièrement http://www.ades.cnrs.fr/tutoqgis/index.php
https://anitagraser.com/
http://desktop.arcgis.com/en/arcmap/
http://www.digital-geography.com/
http://docs.qgis.org/2.0/de/docs/index.html
http://doc.qt.io/qt-4.8/designer-manual.html
http://www.filemaker.com/
http://www.fmsource.com
http://gis.stackexchange.com/
https://www.postgresql.org/docs/
https://www.python.org/doc/
https://www.qgis.org/fr/docs/index.html
http://www.qgistutorials.com/de/index.html
https://sites.google.com/site/pyarchinit/
http://seig.ensg.ign.fr/fichchap.php?NOCONT=&NOCHEM=CHEMS005&NOFICHE=FP20
&NOLISTE=4&N=4&RPHP=&RCO=&RCH=&RF=&RPF=
37
Annexes Annexe 1 : Mise à jour du SIG GEOMAR……………………………………………37
Annexe 2 : Guide d’utilisation du SIG………………………………………………..61
Annexe 3 : Cahier de charges……………………………………………………………73
Annexe 4 : Diagramme de Gantt………………………………………………………75
