Conception et implémentation d`un SIG pour la
publicité
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 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 1 2 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. 3 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 4 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 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 graphique pour 5 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 MarieDominique 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 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 2 6 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 7 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 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 6 8 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. 9 Figure 1 : La zone d'étude GEOMAR 10 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 11 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. 12 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. 13 Figure 2 : Structure de la base de données GEOMAR dans FilemakerPro 14 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 15 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. 16 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. 17 Figure 4 : Comparaison des trois types de géodatabase Figure 5 : Fenêtre SQL dans ArcGis 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 18 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 19 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 20 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. 21 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 Inconvénients Géodatabase insuffisante pour les besoins Formation nécessaire du SIG GEOMAR Lien OLE DB contraignant 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. 22 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 cidessous 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) 23 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 à 24 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 Dans un espace de travail plugin pour les requêtes attributaires 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 Dans la base de données les requêtes à mener 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. 25 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 26 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 27 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 28 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. 29 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 30 é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. 31 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 32 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. 33 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 34 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. 35 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= 36 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 37
