Archives de catégorie : Géomatique

Monasteries in Digital Humanities

Ce colloque international sur les Monasteries in the Digital Humanities s’est tenu à l’initiative de Marek Derwich cinq jours durant à Czestochowa (Pologne). Il a réuni une bonne cinquantaine d’orateurs issus des sciences humaines (historiens, sociologues, anthropologues, archivistes, musicologues, architectes, archéologues, acteurs du patrimoine) et des technologies numériques. Les projets présentés, dont une partie sont d’ores et déjà accessibles en ligne, couvrent une large Europe, dont seules les marges très septentrionales (Scandinavie) et balkaniques n’étaient pas représentées. Du point de vue chronologique, les contributions ont offert un très large prisme, du haut Moyen Âge aux temps très contemporains. La dimension interdisciplinaire et diachronique de la rencontre constitue l’un de ses points forts.
La collection Hereditas Monasteriorum (université de Wroclaw) devrait accueillir la publication de cette rencontre en 2018.

Projets accessibles en ligne :

Les solutions de cartographie web

Les Solutions de cartographie web – ou webmapping – sont des outils qui permettent de publier sur internet des cartes issues de ses propres données, de ses traitements et de ses choix de symbologie, de manière dynamique et potentiellement interactive. Les outils de cartographie peuvent également permettre de procéder à des traitements géomatiques en ligne. Il existe trois types d’outils pour faire de la cartographie sur internet : des solutions « clefs en main », des SIG en ligne et des combinaisons serveur/client cartographiques.

Des services de cartographie web « clefs en main »

Des programmes en ligne « clefs en main » permettent de produire et de publier facilement et rapidement des contenus cartographiques dynamiques. On peut citer par exemple Google Mymap, programme propriétaire de Google, ou U-Map, programme libre développé par la communauté OpenStreetMap.

Avantages

  • facilité de prise en main
  • rapidités de mise en œuvre

Ils offrent des interfaces qui facilitent la mise en commun et la collaboration sur des projets cartographiques.

Inconvénients

Néanmoins, ces solutions ont les inconvénients de leurs avantages : elles sont très basiques. Ce sont souvent uniquement des outils d’affichage de données vectorielles simples, contraignants dans leurs paramètres de traitements, de symbologie ou dans les possibilités de mise en page qu’ils proposent. Enfin, souvent gratuits, ces services ne sont cependant pas tous libres et ils impliquent des droits de licences qui ne sont pas toujours à l’avantage des utilisateurs ou de la liberté des données (notamment dans le cas de Google Mymap).

Des SIG en ligne

Les SIG en ligne offrent des fonctionnalités comparables aux SIG de bureau (bien que souvent réduites par rapport à celles-ci) et permettent à plusieurs usagers d’intervenir et de collaborer sur un même projet géomatique.

Parmi ces SIG en ligne, on trouve surtout des services payants et propriétaires, par exemple :

  • Carto.com propose une utilisation gratuite mais vite limitée, notamment en termes de rapidité d’affichage et du nombre de données affichables ;
  • ArcGIS Online propose des fonctionnalités SIG simplifiées mais puissantes en ligne ;
  • Géo, anciennement Dynmap, fonctionne également de cette manière.

Avantages

  • fonctionnement multi-utilisateurs ;
  • performance ;
  • une ergonomie et un fonctionnement similaire aux versions desktop, pratique pour ceux qui connaissent déjà les outils.

Ces outils peuvent être très utiles dans le cadre de la phase exploratoire et du géotraitement commun de données géographiques.

Inconvénients

Ce sont la plupart du temps des technologies payantes et propriétaires. Ceci implique que leur utilisation peut être limitée ou soumise à l’achat de licences et de mises à jour. On ne peut donc garantir la pérennité des cartes web qui sont ainsi développées sur le long terme.

Il existe une solution intermédiaire entre les SIG en ligne cités et les solutions serveur/client nécessitant un fort investissement en termes de développement, que nous allons présenter plus loin. Il s’agit de QGIS server, une solution OpenSource qui a pour principe de transposer le SIG libre QuantumGIS desktop sur le web. En théorie, cette solution  vise à transférer les projets de QGIS desktop à QGIS server, et donc d’y retrouver les mêmes données, la même structure, les mêmes choix de symbologie et certains outils similaires. En pratique, cette solution est néanmoins très compliquée à mettre en oeuvre et demande un effort de programmation important.

Serveurs et clients cartographiques

La dernière grande famille de solutions web permet d’avoir davantage la main sur les différentes étapes du processus. Alors que les deux premiers types de solutions sont des services qui proposent en même temps les fonctions d’hébergement, de serveur (charger et stocker les données géographiques) et de client (paramétrer et afficher les données), le troisième type de solutions sépare le serveur du client. Le serveur cartographique est un logiciel qui stocke les informations comme étant des informations géographiques avec des coordonnées, une table attributaire dans le cas de données vecteur, une symbologie, etc. (ce qui permet de pouvoir faire des requêtes attributaire ou de localisation sur les données), et de l’autre côté, le client (un autre logiciel souvent situé sur un autre ordinateur) affiche les données comme étant des images cartographiques, c’est-à-dire avec une légende, une échelle, la possibilité de changer d’échelle, de zoomer sur la carte et potentiellement d’interagir avec elle.

Avantages

Des tâches bien différenciées

Le premier avantage de ce type de solutions est que toutes les étapes du processus sont bien séparées. En amont, il y a une étape de traitement, de mise en forme des données géographiques (sur des outils de SIG de bureau classique). Ensuite, il y a une étape de mise en forme des données pour internet et de chargement sur des serveurs cartographiques qui garantissent la nature géographique des données, par exemple en utilisant MapServer (le pionnier) ou GeoServer (plus facile d’accès).

Ensuite, il peut y avoir une étape de catalogage des données qui utilise aussi des programmes indépendants, comme Geosource (à l’origine du Geocatalogue par exemple), pour formaliser les données selon des normes, comme la norme Inspire. Cette étape est utile dans le cas où les données ont vocation à être téléchargées et réutilisée.

Enfin, il y a l’étape du client, c’est-à-dire de l’affichage et de la programmation des possibilités d’interaction et de visualisation sur la page web de la carte, grâce aux librairies javascript Openlayers (très puissant mais nécessitant plus de développement) ou Leaflet (qui a une syntaxe plus légère).

La segmentation de ces étapes implique qu’elles peuvent être réalisées par différentes personnes. Egalement, lorsque la donnée change, lorsqu’on en rajoute ou qu’elle évolue, il suffit de la modifier en amont et de l’intégrer au reste plus ponctuellement.

Des technologies libres, standardisées, interopérables et bien soutenues

Un autre avantage réside dans le fait que ces technologies sont libres et gratuites, et qu’elle possède une communauté très importante d’utilisateurs, ce qui implique une large documentation et une garantie de leur pérennité (une grande communauté d’utilisateur garantit le fait que la technologie va durer et qu’elle va être entretenue, qu’elle va évoluer, être optimisée).

Les différentes composantes de ces solutions de webmapping reposent sur des standards et offrent donc une grande compatibilité entre elles et avec d’autres fonctionnalités web. Par exemple le client cartographique Leaflet fonctionne directement et très facilement avec la librairie de datavisualisation généraliste, D3.js. A partir de QGIS desktop, il est également possible de produire automatiquement des scripts en OpenLayers.js ou Leaflet.js grâce au plugin qgis2web. On peut aussi signaler Vmap, qui permet d’afficher, côté client, les flux WMS mis à disposition par les serveurs cartographiques, grâce à une interface ergonomique et simplifiée. Cette application remplace le développement complexe de pages html, php et javascript. Cette interopérabilité provient précisément du fait que ce sont des technologies libres : le domaine de la géomatique libre s’est rapidement doté de conventions notamment à travers les normes de l’Open Geospatial Consortium (OGC) qui régulent et garantissent l’interopérabilité entre toutes les initiatives dans le domaine.

Enfin un dernier avantage réside dans la grande liberté de développement que ces solutions offrent. Il est possible de maîtriser toutes les étapes du processus, et, lorsque l’on maîtrise bien les différentes étapes, il est finalement possible de tout faire. La méthode s’avère très puissante et les possibilités – en tout cas en termes de visualisation – sont très vastes. Au sein de l’architecture serveur/client cartographique, il est possible de moduler et d’alléger certaines étapes, notamment celle du paramétrage du serveur pour tout paramétrer côté client. L’architecture de ces solutions est en ce sens flexible. Il est possible de mettre directement en relation une base de données géographiques (Postgis) avec les clients cartographiques en javascript, ce qui facilite l’affichage cartographique par requête directement dans la base de données.

Inconvénients

Evidemment, ces avantages ont leurs inconvénients : ces solutions sont très lourdes à mettre en place en termes de développement. Elles nécessitent un gros effort de programmation. En ce sens, ces solutions ne conviennent pas forcément dans le cas où la carte web est alimentée par des gens différents de ceux qui l’ont mise en place et qui n’auraient pas les mêmes compétences informatiques. Il faut donc que son utilisation vaille le coût de son développement (ce qui n’est pas toujours le cas).
Il faut ajouter que ces solutions de cartographie web n’offrent pas d’hébergement pour l’application de webmapping. Autrement dit, il faut que le développer de l’application trouve à l’héberger, ce qui est la plupart du temps payant et/ou demande un suivi, voire un entretien, sur le long terme. Certains serveurs cartographiques comme Geoserver sont en outre relativement compliqué à installer sur un serveur web distant au moment de la mise en ligne de l’application. La documentation  est effet abondante concernant son installation en local mais beaucoup plus rare concernant son installation sur serveur distant.
Enfin, les solutions serveur/client cartographiques proposent des outils encore faibles en terme de géotraitements de données par l’utilisateur.

S’adapter à l’objectif

Le choix de la technologie de webmapping doit être adaptée à l’objectif : il ne sert à rien de développer quelque chose de très lourd pour une carte simple, et, à l’inverse, une lourde phase de programmation en amont peut alléger bien des opérations en aval. Dans le cadre du projet Col&Mon, les différentes étapes – notamment l’étape d’exploration des données et celle de l’élaboration du livrable final – n’impliquent pas les mêmes fonctionnalités ni les mêmes objectifs. Elles ne nécessitent donc pas forcément les mêmes outils de cartographie web. Ce projet devra donc recourir à tous les types d’outils recensés ici.

Les limites des diocèses au Moyen Âge : sources historiques et outils d’interprétation SIG 

Ce travail postdoctoral, d‘une durée d’un an, s’est donné pour but de travailler sur les limites des diocèses en France, avant 1317, c’est-à-dire pour une période durant laquelle l’espace des diocèses est mal connu. L’objectif est de proposer une restitution de l’emprise de ces espaces diocésains entre IXe et XIVe siècle. Étant donné le temps imparti assez limité et donc l’impossibilité de réaliser ce travail sur tout le territoire national, il a été décidé de traiter en priorité les espaces qui étaient privilégiés dans Col&Mon parce qu’ils étaient déjà bien documentés dans les bases de données sur les collégiales et sur les monastères, véritables points de départ de ce projet ANR. Les diocèses priorisés appartiennent à la région Bourgogne, au Limousin.

Dans cet article, on essaiera de faire le point sur la méthodologie utilisée pour la mise en place du SIG et la reconstitution des limites des diocèses. La première partie du projet s’est concentrée sur l’étude des travaux publiés sur ces espaces et la collecte des données existantes en format compatible avec le SIG. Pour la réalisation de l’outil d’analyse, on a utilisé le logiciel SIG ArcGIS 10.4.1 de l’entreprise ESRI et le logiciel libre QGIS version 2.16. Les données vectorielles SIG (Fig. 1) que nous avons pu recueillir sont les suivantes :

  • les données mises à disposition sur le site Menestrel par Thomas Lienhard, maître de conférences au LaMOP (Laboratoire de Médiévistique Occidentale de Paris) de l’université Paris 1, en particulier les fichiers en format shapefile des évêchés et archevêchés d’Europe, des provinces romaines des Gaules et des royaumes francs, des vici et des villes d’époque romaine ;
  • Le shapefile polygonal des pagus de France que Thomas Lienhard a créé à partir des données visibles sur le site Regnum Francorum Online ;
  • les limites des diocèses de France entre le XIVe et le XVIIIe siècle, réalisées par Thomas Areal (Université de Clermont – Blaise Pascal) et téléchargeables du site Georezo;
  • la collecte des données des projets Collégiales et Monastères, sous forme de points géoréférencés ;
  • les données, d’époque romaine et médiévale, du projet Digital Atlas of Roman and Medieval Civilization, mises à disposition à travers le protocole d’échange WMS.
Figure 1: Données SIG vectorielles
Figure 1: Données SIG vectorielles

À ces données vectorielles, ont été ajoutées les données raster suivantes (Fig. 2) :

  • les cartes des diocèses de France réalisées par Jacques de Font-Réaulx, dans les années 1970, avec la collaboration de plusieurs chercheurs de l’IRHT. Malheureusement, les cartes produites ne couvrent pas tous les diocèses de France ; l’auteur a écrit en 1960 un article intitulé « Atlas des diocèses de France » (Font-Réaulx J. L’atlas des diocèses de France, Bibliothèque de l’école des chartes. 1960, tome 118. pp. 191-198) où il explique la méthodologie utilisée pour les. Les cartes ont été déjà numérisées par le LaMOP et le CERCOR (Université Jean Monnet de Saint-Étienne), à différentes périodes ;
  • grâce à la convention réalisée entre le LaMOP et l’IGN, on a eu la possibilité de télécharger – en les utilisant comme base cartographique – les cartes IGN aux échelles 1/25.000e et 1/50.000e, ainsi que le shapefile linéaire en format vectoriel de l’hydrographie et le shapefile polygonal des communes, des départements et de régions de France ;
  • grâce au protocole d’échange WMS du Geoportail de l’IGN, on a aussi pu utiliser la carte réalisée par les Cassini au XVIIIe siècle.
Figure 2 : Exemple des données raster pour le territoire parmi les diocèses de Langres, Autun et Auxerre (Carte IGN 1/25 000e, carte de Cassini, carte de Font Réaulx)
Figure 2 : Exemple des données raster pour le territoire parmi les diocèses de Langres, Autun et Auxerre (Carte IGN 1/25 000e, carte de Cassini, carte de Font Réaulx)

Une fois récupérées toutes ces données, il était alors temps de se concentrer sur la géoréférenciation des cartes de Font-Réaulx, en utilisant comme base de référence les cartes IGN au 25 000e et le système de projection Lambert 93. Pour la Bourgogne, nous avons géoréférencé les cartes des diocèses de Langres, de Sens, et de Chalon-sur-Sâone mais aussi celui limitrophe de Bourges. Les lieux de culte et les limites se réfèrent au XIVe siècle, sauf cas particuliers qui ont été indiqués sur la carte. Nous avons ensuite vectorisé les limites tracées, en essayant de les repositionner sur la carte IGN au 25000 e et de géolocaliser de façon plus précise les lieux mentionnés sur les cartes (Fig. 3).

web_fig3
Figure 3 : Cartes de Font-Réaulx géoréférencées

Afin d’essayer de restituer les limites des diocèses pour la période qui va du haut Moyen Âge au XIVe siècle, même si l’on a utilisé la même méthodologie que celle utilisée par Font-Réaulx, il a été possible de bénéficier des potentialités offertes par des logiciels SIG. Le premier diocèse étudié a été celui d’Auxerre, pour lequel on avait déjà rassemblé quantité de données. Au-delà des pouillés, nous avons pu utiliser les gesta des évêques (Les Gestes des évêques d’Auxerre, éd. sous la direction de Michel Sot, Paris, 2002), afin de positionner les lieux de culte qui y étaient présentés comment étant sous contrôle épiscopal entre le IIIe et le XVIIIe siècle. En réalité, il faut souligner que la première rédaction des gesta a été réalisée entre 872 et 875.

Pour géolocaliser les lieux (pris en compte d’abord dans les pouillés, ensuite dans les gesta), on a procédé de façon régressive ; ont d’abord été positionnées les localités mentionnées dans les pouillés du XVe siècle (Longnon M. A., Pouillés de la province de Sens, t. IV, Paris, 1904), pour passer successivement aux époques plus anciennes (Fig. 4).

Figure 4 : Lieux de culte du diocèse d'Auxerre entre le Ve et XVe siècle
Figure 4 : Lieux de culte du diocèse d’Auxerre entre le Ve et XVe siècle

Les lieux ont été placés sur la carte IGN au 25 000e à l’aide du shapefile des communes de France et de la carte de Cassini. Pour retrouver sur la carte des toponymes qui ont aujourd’hui disparu, on a utilisé le dictionnaire topographique de la France. Une fois créées les couches des lieux de culte pour chaque période, grâce au SIG, l’évolution de la cartographie des lieux de culte a pu être retracée à l’intérieur du diocèse au cours des siècles, mettant en évidence des phases d’expansion et de contraction des possessions. Nous avons suivi la même méthodologie pour les autres diocèses de Bourgogne comme Autun, Nevers, pour les diocèses de Langres et Chalon-sur-Saône les cartes avaient déjà été faites par Font Réaulx et donc sont été simplement vectorisées. Malheureusement, pour ces autres diocèses, nous n’avons pas une documentation aussi complète que celle constituée par les gesta pour le diocèse d’Auxerre.

Après le XVe siècle, les limites des diocèses ne sont pas très différentes des limites des communes. C’est encore plus vrai en ce qui concerne les communes créées après 1789. J. Font-Réaulx a d’ailleurs souvent utilisé les limites communales pour la réalisation de ces cartes mais à l’échelle de la France, cette option ne pose pas de gros problèmes cartographiques. En revanche, pour les périodes plus anciennes, tracer avec précision les limites des diocèses est méthodologiquement délicat. Au-delà des limites naturelles comme les crêtes des montagnes et les fleuves (dans notre cas la Loire fixait, déjà en 876, la limite entre les diocèses d’Auxerre et de Bourges), il n’existait pas de bornage qui ait survécu jusqu’à nos jours. C’est pour cette raison qu’essayer de dessiner les limites en traçant une ligne qui passe par des points donnés au milieu d’une forêt ou d’une campagne ne correspond pas à la réalité historique, notamment pour les périodes les plus anciennes pour lesquelles rien ne dit que la notion de limite linéaire était opérante. Nous avons donc choisi, pour résoudre ce problème de validité dans la restitution des limites, de créer des zones tampons à l’intérieur desquelles se situent avec la plus grande probabilité les limites des diocèses.

Pour positionner ces zones tampons, nous avons dessiné un fichier polygonal entre les diocèses, ayant pour sommets les lieux de culte les plus externes de chaque diocèse. Pour automatiser la création de la zone tampon, nous avons utilisé la fonction de l’enveloppe concave. Une enveloppe concave est la surface minimale contenant tous les points qui sont positionné sur le territoire (Fig. 5). Nous avons appliqué cette fonction à chaque diocèse afin d’identifier la portion de territoire qui se trouve entre les deux surfaces et qui correspond à notre zone tampon.

Figure 5 : enveloppes concaves réalisées autour des points des lieux de culte des diocèses d'Auxerre et d'Autun.
Figure 5 : enveloppes concaves réalisées autour des points des lieux de culte des diocèses d’Auxerre et d’Autun.

Dans l’exemple donné, il est ainsi impossible de savoir précisément où passe la limite entre les diocèses de Autun et d’Auxerre. Plutôt que de trancher arbitrairement, la zone tampon permet de tracer un zonage de contact (Fig. 6).

Figure 6 : Zone tampon entre XIIIe et XIVe siècle entre le diocèse d'Auxerre et le diocèse d’Autun
Figure 6 : Zone tampon entre XIIIe et XIVe siècle entre le diocèse d’Auxerre et le diocèse d’Autun

C’est donc à l’intérieur de cette zone que, selon toute probabilité, ont fluctué les limites des diocèses. La largeur de la zone tampon est liée à la typologie du territoire, ainsi qu’à la concentration des lieux de culte ; le long de la Loire, par exemple, les zones tampons sont plus étroites que celles que l’on retrouve dans les régions boisées. En recréant ces zones tampons pour toutes les périodes, nous avons pu les comparer afin de mettre en évidence les variations des limites de diocèses pendant le laps de temps étudié (Fig. 7).

Figure 7 : Superposition des zones tampons entre le diocèse d'Auxerre et le diocèse de Autun (XIIIe et XIVe siècles)
Figure 7 : Superposition des zones tampons entre le diocèse d’Auxerre et le diocèse de Autun (XIIIe et XIVe siècles)

Ensuite, on comparera ces zones avec les limites obtenues en utilisant la méthode du polygone de Thiessen et les limites des communes actuelles.

La méthodologie des polygones de Thiessen a été déjà utilisée pour reconstituer le tissu du maillage paroissial en Touraine (Pascal Chareille, Xavier Rodier, Elisabeth Zadora-Rio. L’analyse des transformations du maillage paroissial et communal en Touraine à l’aide d’un SIG. Histoire & Mesure, EHESS, 2004, XIX (3/4), pp.317-343)

Toutes ces données seront mises à disposition en libre format sur la plateforme SIG du projet Col&Mon.