Archives de catégorie : Outils SIGH en ligne

Population du Canada dans l’Atlas historique du Canada selon les divisions de recensement 1851-1961: projet pilote en cartographie web

Outils SIGH en ligne, Projets SIGH, Visualisations innovantes,

Liens rapides:
Carte web de démonstration utilisant un logiciel libre (Mapbox, JQueryUI):
Historical Atlas of Canada Online Learning Project (HACOLP) :Croissance démographique, densité et répartition – par division de recensement, 1851 à 1961
http://mercator.geog.utoronto.ca/georia/mapbox-hacolp
Carte web de démonstration utilisant ArcGIS Online:
HACOLP : Densité de population par division de recensement, 1851-1961, applications sensibles au temps (3 versions)
HACOLP : Croissance de la population par division de recensement 1851-1961 applications sensibles au temps
http://hgisportal.esri.ca/portal/apps/MapAndAppGallery/index.html?appid=f7e6329dd6b3494b9b689e1750cf6781

Pour des documents détaillés sur le développement des projets pilotes, voir les liens à la fin de cet article.

TL’Atlas historique du Canada est un projet de recherche et de publication en trois volumes, terminé en 1993, qui utilise des cartes, du texte et d’autres documents graphiques pour explorer des thèmes de l’histoire du Canada. Une sélection de planches thématiques de l’Atlas a été publiée en ligne en 2008 à l’aide de la technologie ArcIMS d’Esri, dans le cadre du Historical Atlas of Canada Online Learning Project (HACOLP). Pour plus d’informations sur ce projet, voir: http://www.historicalatlas.ca/website/hacolp/about.htm

L’un des principaux thèmes abordés dans l’Atlas a été l’évolution rapide de la population à travers le pays au cours du siècle précédent 1961, année qui marque la fin de la période couverte dans l’Atlas. Un certain nombre de mesures démographiques ont été utilisées pour différentes cartes, périodes et sous-régions, mais quand le HACOLP a été mis en place, il a été décidé de créer un chapitre intitulé Summary of Population Growth, 1851-1961 qui permettrait aux utilisateurs de voir comment le changement s’est produit pendant toute cette période, mettant en relation trois représentations cartographiques différentes.

Le site web original présentait trois cartes interactives de la population par division de recensement, utilisant trois méthodes de symbolisation différentes: densité de population (choroplèthe), croissance démographique (cercles gradués) et répartition de la population (densité de points) pour onze recensements canadiens, 1851 à 1961. Ces cartes utilisaient la technologie ArcIMS et une légende JavaScript personnalisée utilisant des cases à cocher pour afficher ou masquer chaque année.

Le but de ce projet pilote était de créer de nouvelles cartes web pour rajeunir et améliorer les cartes originales, en performance et en visualisation. À l’aide des données fournies par HACOLP, les cartes ont été reproduites pour ce projet pilote tout en étant mises à jour selon les normes actuelles de cartographie web et en mettant en place un curseur de temps pour visualiser chaque période de recensement afin de remplacer les cases à cocher. Ce projet était également approprié pour explorer la capacité du logiciel de cartographie web selon sa flexibilité de conception des légendes et pour les projections cartographiques autres que le Web Mercator standard.

Comme prévu pour ce projet, nous avons conçu et produit deux versions différentes pour chacun de ces thèmes : l’une utilisant la plateforme ArcGIS Online et l’autre utilisant un logiciel libre et des outils de service web, dans ce cas, nous avons utilisé principalement les bibliothèques Mapbox et JQueryUl javascript.

Les VERSIONS EN LIGNE d’ArcGIS se trouvent sur le portail de développement Geohistory-Géohistoire Canada (techniquement un portail ArcGIS Entreprise) hébergé en ligne par nos partenaires d’Esri Canada à HACOLP Population Apps Gallery. Pour voir le contenu d’un autre portail, allez à: http://hgisportal.esri.ca/portal/home. La « Galerie » contient 4 applications : une pour la croissance démographique (cercles gradués) et trois versions de la densité de la population (choroplèthe) – une avec une projection Web Mercator, une autre avec une projection Lambert Conic Conformal et la troisième utilisant une configuration qui génère des cartes en mosaïque à la volée – à des fins de comparaison des performances. Nous avons également créé une version de l’application pour tester la procédure   Optimize Layers », disponible dans ArcGIS Online, mais pas dans l’environnement du portail. Ces méthodes comparatives sont expliquées dans le document de développement détaillé ArcGIS Online (voir le lien ci-dessous) – vous pouvez les visualiser pour comparer leur performance pour vous-même. La version Lambert met en évidence la capacité de projections alternatives dans ArGIS Online, qui sont plutôt faciles à réaliser. D’un autre côté, la cartographie par densité de points n’était pas facile à réaliser en utilisant les outils disponibles.

ArcGIS Portal Population Density Map using Lambert Projection
Carte de densité de la population du portail ArcGIS utilisant la projection Lambert. 

Les version Mapbox des cartes HACOLP sont hébergées sur un serveur du département de géographie de l’Université de Toronto. Nous avons été en mesure de générer des cartes pour les trois types de représentations en utilisant Mapbox. Toutefois, il ne prend pas en charge les projections autres que le Web Mercator. Les cartes ont été placées dans une seule page d’accueil affichant des images de chaque carte avec des liens vers les cartes interactives. Elles peuvent être trouvées ici : http://mercator.geog.utoronto.ca/georia/mapbox-hacolp.

Mapbox est une plateforme de cartographie en ligne et libre (open source) pour la conception de cartes personnalisées. Les cartes sont créées à partir de mosaïques d’images vectorielles et ont développé ce format, « [traduction] une approche avancée de la cartographie où les données sont livrées à l’appareil et précisément rendues en temps réel » (www.mapbox.com/maps). Les mosaïques vectorielles fournissent une version vectorielle de la technologie de pavage d’images que Google a utilisé pour révolutionner les performances de cartographie web. Esri et d’autres leaders de l’industrie utilisent maintenant des tuiles vectorielles pour leur cartographie de base.

Mapbox fournit un certain nombre d’outils faciles à utiliser pour la gestion des cartes et des données en ligne ainsi que pour la composition des cartes, comme ArcGIS online. Cependant, il s’agit toujours d’un environnement de développement libre, offrant une personnalisation grâce à un certain nombre d’outils de développement (SDKs et APIs) qui sont résumés en ligne ici :  https://www.mapbox.com/developers/.  Pour les nouveaux utilisateurs de Mapbox, notre document de développement sur logiciel libre est disponible ci-dessous. Il fournit un « [traduction] aperçu du flux de travail dans Mapbox » (pages 3-4) que nous avons utilisé pour créer les cartes web du projet pilote.

L’un des domaines où Mapbox est très flexible est la composition de la légende. Contrairement à ArcGIS, où les légendes sont faciles à inclure, mais plutôt inflexibles, Mapbox vous laisse le contrôle. Par conséquent, nous avons entrepris le défi de créer du code pour générer une légende basée sur le même tableau configuré pour la classification des données cartographiques.

Choropleth legend array as coded in Mapbox
Légende choroplèthe codée dans Mapbox

Par exemple, lorsqu’un tableau de couleurs est défini pour les classes choroplèthes, une légende est générée automatiquement qui hérite du jeu de symboles. Ceci est détaillé dans le document de développement avec logiciel libre sous « Data driven styling and automated legend creation », p. 12-15 et un gabarit est fourni sur GitHub.

Pour les versions d’ArcGIS Online et de Mapbox, nous avons constaté que les améliorations de la vitesse d’affichage n’étaient pas aussi bonnes que nous l’espérions. Les polygones des divisions des recensements et les lignes sont complexes, même lorsqu’ils sont généralisés et optimisés pour le déploiement sur le web, et leur diffusion est plus lente que ce que l’on pourrait souhaiter. Nous avons expérimenté diverses solutions suggérées pour cela, dans les deux suites logicielles, mais nous n’avons rencontré que des améliorations modérées. Si vous avez des commentaires ou des suggestions à propos de ces questions, ou de tout autre aspect de conception des projets pilotes, n’hésitez pas à publier vos commentaires ci-dessous ou à contacter l’auteur à byron.moldofsky@gmail.com.

Pour plus d’informations sur le travail effectué sur ces projets pilotes de cartographie web, nous avons rendu disponibles nos documents de développement via les liens ci-dessous. Aussi, pour le logiciel libre, nous avons posté le code utilisé et quelques exemples de « modèles » sur GitHub.

LIENS VERS LA DOCUMENTATION

Cartes HACOLP de la « population par division de recensement », Document de développement avec logiciel libre (open-source)

Cartes HACOLP de la « population par division de recensement » Document de développement avec ArcGIS Online

Pour le code pour le site de cartographie libre, voir :  HACOLP Github Open Source Repository

Projet pilote de cartographie web des marchands de Montréal vers 1880

Enseigner avec les SIGH, Outils SIGH en ligne, Projets SIGH, Visualisations innovantes,

Liens rapides:
Carte web de démonstration utilisant un logiciel à code ouvert (Carto.com):
Annuaires Lovell de Montréal 1880-81 carte de base
https://canadian-hgis.carto.com/builder/70212344-415a-11e7-9fef-0e3ff518bd15/embed 
Carte finale des marchés et des maisons des marchands de Montréal – avec widget
https://canadian-hgis.carto.com/builder/a20b5b37-52ed-417b-b6fa-f73d618d6fcd/embed
Cartes web de démonstration ArcGIS Online:
Annuaire Lovell de Montréal en 1880 application web de base : Couches d’origine et carte de base ArcGIS.
Marchés et maisons des marchands de Montréal vers 1880 avec filtres
http://hgisportal.esri.ca/portal/apps/MapAndAppGallery/index.html?appid=f081eb9a363c46caa37c77d132def423

Pour des documents détaillés sur le développement des projets pilotes, voir les liens à la fin de cet article.

Montréal, l’avenir du passé (MAP) est un projet qui a marqué l’histoire canadienne des SIG historiques canadiens. Les professeurs Sherry Olson, Robert Sweeny et leurs collaborateurs de l’Université McGill ont recensé, cartographié et analysé plusieurs ensembles de données fondamentales pour comprendre le contexte de l’histoire urbaine de Montréal au XIXe siècle : le tissu urbain incluant les types de bâtiments tirés des cartes historiques de 1825, 1846 et 1880, les données démographiques d’un certain nombre de recensements, des informations à propos des résidents et des entreprises provenant d’annuaires. Leur site web, basé à l’Université Memorial, explique en détail ces données et les diverses applications mises à disposition des chercheurs et des étudiants. (http://www.mun.ca/mapm/)

Cependant, dans le cadre de la discussion ouverte à notre réunion du projet Geohistory/Géohistoire en août 2016, notre collaborateur Robert Sweeny a exprimé sa déception (si je peux paraphraser) de ce qu’on pourrait appeler la promesse ratée de la cartographie en ligne. La cartographie interactive et les outils SIG ne devraient pas limiter les utilisateurs aux résultats de recherches préalablement orientées, comme les cartes imprimées ont pu le faire. Ces outils devraient permettre une exploration active des données SIG historiques, comme poser des questions nouvelles ou imprévues, établir des relations spatiales nouvelles ou imprévues, en bref, permettre à l’utilisateur d’utiliser des outils SIG pour explorer et analyser des données dans un environnement en ligne.

De nombreuses voix dans le public se sont levées pour assurer Robert que les applications et outils SIG en ligne étaient en cours de développement à ce moment-là et qu’elles permettraient bientôt le type d’enquête qu’il prévoyait et attendait. Comme prévu, ces outils ont émergé au cours des deux dernières années, à la fois dans la communauté utilisant les logiciels libres (open source) et dans le monde d’ArcGIS Online. Robert était peut-être un peu sceptique, mais il restait prêt à être convaincu. Ainsi, lors de la recherche de projets pilotes de cartographie web pour notre partenariat à la fin 2016, nous lui avons posé une question : trouverait-il un scénario pour prouver que les outils SIG en ligne avaient atteint leur maturité? Que les élèves de sa classe, qui avaient toujours eu besoin de logiciels SIG complets, pouvaient maintenant utiliser un navigateur web?

WRobert a répondu avec un « [traduction] scénario pour les marchés basé sur l’application QGIS de MAP créée à partir des annuaires Lovell » qui figure en annexe 1 dans les documents de développement disponibles via les liens ci-dessous. Pour citer une section pertinente :
« [traduction] comme dans de nombreuses régions du monde, les Montréalais du 19e siècle achetaient la majeure partie de leur nourriture dans les marchés… D’ouest en est, Saint-Gabriel, Saint-Antoine, Sainte-Anne, Saint-Laurent, Saint James et Papineau avaient leur propre marché, alors que le Marché Bonsecours, sur la rue Saint-Paul, servait de marché principal. Dans les annuaires Lovell, il était fréquent que les personnes qui louaient des étalages sur les marchés de détails indiquent également leur adresse domiciliaire. Dans cet exercice, nous comparerons cette information résidentielle avec d’autres variables pour évaluer le caractère de ces différents marchés. »

Les « autres variables » du scénario Robert sont les professions. Il a décrit une méthode utilisant QGIS pour établir des liens entre les lieux de travail des marchands et leurs emplacements résidentiels (ainsi que ceux qui pourraient être déterminés). Il a ensuite suggéré que le type d’occupation pourrait illustrer différentes tendances par rapport au type d’habitation ou à la distance entre le marché et le domicile des marchands. Identifier ces emplacements et dessiner les lignes de liaison entre eux ouvre de nombreuses possibilités d’analyse.

C’est ce que nous avons tenté de faire, en utilisant d’abord Carto, un logiciel libre et gratuit (open source), puis en utilisant ArcGIS Online. Les cartes finales qui illustrent l’emplacement des maisons et des lieux de travail des marchands se ressemblent beaucoup (comme on pourrait l’espérer!). Les vues par défaut sont illustrées ci-dessous : la carte Carto montrant toutes les catégories professionnelles, la carte ArcGIS Online montrant les symboles et les lignes pour les bouchers seulement.

Carto user view showing ALL vendors and connections

Vue utilisateur Carto montrant TOUS les marchands et toutes les liaisons

ArcGIS Online App filtered to show points and connections only for "Butchers"

Application ArcGIS Online filtrée pour afficher les points et les liaisons pour les bouchers.

Remarque: Contrairement à nos autres projets pilotes, qui mettent l’accent sur la fonctionnalité et la personnalisation du codage pour la conception et la présentation des cartes, ce projet vise avant tout à permettre à l’utilisateur d’analyser et d’explorer les données de manière interactive. Par conséquent, plutôt qu’une présentation du code requis pour produire une carte web finale, notre documentation détaillée consiste en un processus étape par étape pour utiliser les derniers outils en ligne de Carto.com et d’ArcGIS Online (à la mi-2017) pour atteindre les objectifs de l’exercice.

Il y a des similitudes et des différences dans la façon dont les deux ensembles d’outils traitent les opérations et les produits finaux sont certainement distincts. Cependant, il y a plus de similitudes que de différences – ce qui suscite un débat intriguant entre beaucoup de personnes faisant de la cartographie web : qui suit qui? Nous n’avons pas l’espace pour explorer cette question ici, mais n’hésitez pas à publier vos propres commentaires ci-dessous.

Certaines des similitudes sont superficielles. Par exemple, les outils pour réaliser ces produits sont des ajouts assez récents à leurs boîtes à outils en ligne. Les deux suites de logiciels les rassemblent dans ce qu’ils appellent tous les deux des outils « d’analyse ». Leurs interfaces d’édition sont similaires, comme illustrées ci-dessous. Carto utilise un outil « Analysis » de Carto Builder appelé « Connect with Lines », pour créer des liens entre les points. ArcGIS Online utilise un outils « Analysis » nommé « Connect Origins and Destinations » pour obtenir un résultat similaire. Cependant l’outils AGOL est en fait construit pour faire l’analyse de réseau et des itinéraires, et a des applications potentielles beaucoup plus sophistiquées, alors que l’outil Carto se limite à faire des liens en ligne droite entre des points.Table Connect with lines AGOL and Carto

Malgré les limites relatives de l’outil Carto, il permet d’atteindre les objectifs de ce projet. De plus, sa simplicité le rend plus facile à utiliser et plus tolérant face au manque de données que l’outil AGOL. Par exemple, l’ensemble de données issu de l’annuaire Lovell de Montréal s’est avéré avoir plus de lieux de travail que de lieux d’habitations – tous les lieux de marchés n’avaient pas toujours de lieux d’habitation correspondants. De plus, certains lieux de travail avaient beaucoup plus d’un emplacement « habitation » associé à eux. L’outil Carto a passé outre ces divergences et a dessiné des lignes entre tous les points correspondants sans aucun problème. L’outil AGOL, d’un autre côté, a affiché les messages d’erreurs suivants :

AGOL O-D error message table

Messages d’erreur ArcGIS Online pour Origins-Destination

Donc, pour que l’outil AGOL Origin-Destination fonctionne pour nos objectifs, il a fallu effectuer une manipulation importante des données – tout cela est décrit dans la documentation détaillée pour ceux qui sont intéressés.

Cela ne veut pas dire que l’inconscience des écarts de données est toujours une vertu. Le dépannage des problèmes de données pour l’outil AGOL a fourni une bien meilleure compréhension des points de lieux de travail qui se connectaient réellement aux points d’habitation. Au contraire, il s’agit simplement de dire que, comme d’habitude, il faut s’assurer que pour toute tâche analytique, le bon outil pour le travail est identifié et utilisé.

À mon avis, AGOL et Carto offrent tous deux des outils interactifs en ligne qui permettent de cartographier des données. Ils ont du moins été suffisants pour réaliser le scénario que Robert Sweeny avait souhaité pour ses étudiants et d’autres utilisateurs du projet de Montréal, l’avenir du passé. Cependant, la question demeure : est-ce un environnement efficace pour faire ce genre de travail? Les SIG et autres fournisseurs de logiciels mettent de plus en plus de fonctionnalité dans un « logiciel de service » basé sur un navigateur, livré en ligne. Les avantages sont évidents : tout appareil de navigation peut accéder à ces outils SIG, rien ne doit être installé localement, ce qui se traduit par un accès beaucoup plus large pour les utilisateurs. Les inconvénients : limitations dans les outils de traitement, limitation dans la conception de l’interface et des symboles et limitation du nombre de vues autorisées sans payer de frais. La question de savoir ce qui convient le mieux à un groupe d’étudiants ou à d’autres utilisateurs nécessite un équilibre entre ces limitations.

N’hésitez pas à écrire vos commentaires sur ces projets pilotes en utilisant l’espace ci-dessous.

Pour plus d’informations sur le travail effectué sur ces projets pilotes de cartes web, nous avons rendu disponibles nos documents de développement technique via les liens ci-dessous.

LIENS VERS LA DOCUMENTATION

Les marchands de Montréal vers 1880: document de développement avec un logiciel libre (open source)

Les marchands de Montréal vers 1880: document de développement avec ArcGIS Online

Projet pilote en cartographie Web de Lost Rivers à Toronto

Outils SIGH en ligne, Projets SIGH, Visualisations innovantes,

Liens rapides:
Cartes web de démonstration Open Source (utilisant Leaflet, JQueryUI):
Rivières perdues de Toronto – Rivières en voie de disparition – Chronologie
Visite à pied de la région de baie d’Ashbridge de Lost Rivers (3 excursions)
http://mercator.geog.utoronto.ca/georia/lostrivers/
Cartes web de démonstration sur ArcGIS Online:
Rivières perdues de Toronto – Rivières en voie de disparition – Application de ligne du temps (2 versions)
SIGH Lost Rivers – Carte de l’histoire d’Ashbridges Bay (McMurrich 1882)
http://hgisportal.esri.ca/portal/apps/MapAndAppGallery/index.html?appid=3272511933fa41498201836717b41a27

Pour des documents détaillés sur le développement de projets pilotes, voir les liens à la fin de cet article.

Le projet Lost Rivers Walks (http://lostrivers.ca/) invite les gens à faire des visites guidées à pied autour de la ville de Toronto  « [traduction]… pour créer une appréciation de la connexion intime de la ville à son réseau hydrographique en retraçant les cours d’eau oubliés, en découvrant notre patrimoine naturel et bâti et en partageant cette information avec les autres ». Ils sont l’un des partenaires communautaires de Geohistory-Géohistoire Canada. Pendant de nombreuses années, ils ont dépouillé différentes sources historiques (archives cartographiques et autres), passé des entrevues avec des résidents de longue date et relevé les particularités topographiques de la ville en effectuant des visites sur le terrain pour dessiner la carte du système de drainage de Toronto comme il devait être avant que le processus de construction de la ville en ait enfuie une grande partie sous terre.

Avec Helen Mills et John Wilson représentant le projet Lost Rivers, nous avons décidé de créer des cartes web pour ce projet pilote à propos de deux thèmes différents:
1. Les rivières disparues de Toronto:  Une carte de la ville de Toronto montrant le réseau de cours d’eau original de la ville et comment ces cours d’eau ont disparu au fil du temps, ayant été enterrés à des fins de développement.
2. Rivières perdues, promenades dans la baie d’Ashbridge:  Une série de cartes interactives illustrant de façon dynamique les étapes de trois des marches offertes par Lost Rivers dans le secteur riverain à l’est de Toronto. Ces cartes, créées sous forme de circuits, relient les emplacements des arrêts et comprennent des photos et des textes explicatifs.
Des liens vers toutes les cartes sont inclus ci-dessous.

Comme prévu pour ce projet, nous avons conçu et produit deux versions différentes pour chacun de ces thèmes : l’une utilisant la plateforme ArcGIS Online et l’autre utilisant des logiciels libres (open source) et des outils de service web, dans ce cas nous avons principalement utilisé les bibliothèques JavaScript Leaflet et JQueryUI.

Les VERSIONS EN LIGNE d’ArcGIS se trouvent sur le Portail de développement de Geohistory-Geohistoire Canada (techniquement un portail ArcGIS Entreprise) hébergé en ligne par nos partenaires d’Esri Canada ici : Lost Rivers of Toronto Apps Gallery. Pour voir le contenu d’un autre portail, allez à: http://hgisportal.esri.ca/portal. La « Galerie » contient 3 applications. C’est parce qu’il y a deux versions de l’application Les rivières disparues de Toronto. L’une est hébergée sur le portail lui-même. Elle est conçue avec une ligne du temps « standard » pour faire disparaître les rivières au fil du temps. Cette ligne du temps ressemble à ceci :
ArcGIS_standard_timeline
Cette version de l’application a été créée à l’aide d’ArcGIS Online Web AppBuilder, un outil très convivial qui permet aux auteurs de cartes web de glisser et déposer des composants d’interface utilisateur, comme ce widget « Time Slider », dans leur application web. Le widget peut même, de façon limitée, être configuré spécifiquement pour sa carte et ses données. Par exemple, il est possible de modifier l’icône utilisée pour l’outil et afficher ou non les couches spécifiques au temps au-dessus.
Pour plus d’informations sur l’application Web App Builder voir: http://doc.arcgis.com/en/web-appbuilder/

Cependant, il est impossible d’effectuer des personnalisations plus sophistiquées souhaitées, voire nécessaires. Par exemple, le curseur a deux « poignées » définies à 1830 et 1840 dans l’image ci-dessus. Chacun peut glisser indépendamment vers l’avant ou vers l’arrière le long de la ligne du temps afin de sélectionner une plage de données. Cette conception est très appropriée pour certaines applications. Cependant, lorsque le but est d’illustrer un instantané de l’environnement à un moment donné – comme notre carte des « Rivières disparues » – cela peut être déroutant et la carte résultante peut être floue. Une conception de curseur offrant une seule poignée à l’utilisateur, identifiant un seul point dans le temps, comme l’image ci-dessous, simplifie et clarifie l’interface.
ArcGIS_custom_timeline

Cette personnalisation a été rendue possible uniquement en hébergeant l’application sur un serveur indépendant (pas sur ArcGIS Online lui-même ou le portail Geohistoire) et en utilisant l’édition développeur du Web AppBuilder pour ArcGIS (https://developers.arcgis.com/web-appbuilder/). Il s’agit d’un processus plutôt compliqué nécessitant l’installation de l’application de développement sur un ordinateur local, l’enregistrement de l’application sur le portail Geohistoire pour incorporer des cartes web basées sur un portail, le développement et les tests de l’application sur l’ordinateur local, déployer l’application sur le serveur indépendant, puis enregistrer l’application finale sur le portail Geohistoire afin qu’il y soit accessible.

Les versions du logiciel libre (Open Source) des cartes de Lost Rivers  sont hébergées sur un serveur du département de géographie de l’Université de Toronto. Les cartes sont incorporées dans une seule page web avec un menu comportant les liens vers les cartes des rivières disparues et chacune des marches de la région d’Ashbridge. Elles peuvent être trouvées ici: http://mercator.geog.utoronto.ca/georia/lostrivers

Contrairement au curseur de la ligne du temps de ArcGIS, la ligne du temps utilisée pour la carte des Rivières disparues fait partie d’un ensemble d’outils génériques JQueryUI adaptés aux besoins spécifiques et au calendrier de notre carte (http://jqueryui.com/slider/). La version à laquelle nous sommes arrivés ressemble à ceci :
JQueryUI_custom_timeline_lostrivers

Travailler avec des outils JavaScript génériques a des avantages et des inconvénients. Les avantages ont à voir avec la transparence du codage lié à la conception. La documentation de l’API JQueryUI est complète et les techniques utilisent un codage JavaScript et CSS assez basique. Nous avons pu adapter l’outil et en modifier le graphisme sans trop de problèmes. Les widget ArcGIS web AppBuilder, bien qu’ils soient entièrement disponibles pour la personnalisation, utilisent un cadre de conception plus complexe et la boîte à outils Dojo (https://dojotoolkit.org/). Ils ne sont donc pas aussi accessibles aux programmeurs moins experts. De plus, comme décrit ci-dessus, le système dans lequel les modèles ArcGIS sont intégrés et le flux de travail requis est plutôt compliqué. Par rapport à la personnalisation de l’application ArcGIS Web AppBuilder, le flux de travail impliqué dans le développement du site basé sur Leaflet était extrêmement simple. Les documents peuvent être écrits et testés sur des disques locaux et téléchargés sur un serveur Web une fois complétés.

L’inconvénient de travailler dans un environnement générique plus simple est une réduction des fonctionnalités, ce que l’on pourrait appeler l’intelligence native de l’application. Dans ce contexte, en utilisant GeoJSON pour la superposition des rivières, il n’y a pas de concept de données « sensible au temps ». Les données des lignes sont affichées sur la base d’une requête simple de la valeur du champ entier, dans ce cas l’ « année de la dernière vue sur la carte ». Cela a bien fonctionné pour nos données d’attributs basées sur l’année, mais toute requête plus sophistiquée basée sur la chronologie, ou utilisant une variété de formats de temps, pourrait être très problématique au niveau du code ou être plus compliquée à intégrer dans l’interface.

Il n’y a pas assez d’espace ici pour parler de la production du projet de cartes web promenades de Lost Rivers dans la baie d’Ashbridge, mais un processus semblable s’est produit avec ArcGIS Online et le développement, en parallèle, avec un logiciel libre (open source). Pour des informations plus détaillées sur le travail effectué sur ces cartes web de projets pilotes, nous avons monté des documents de développement technique sur ce site. Ils sont disponibles en suivant les liens ci-dessous. Aussi, pour le codage à code ouvert, nous avons posté le code utilisé et quelques exemples sur GitHub. Pour d’autres questions sur les projets, n’hésitez pas à publier des commentaires et à discuter ci-dessous, ou à contacter l’auteur à byron.moldofsky@gmail.com.

LIENS VERS LA DOCUMENTATION

Document de développement de code ouvert des cartes des « Rivières disparues » de Toronto, projet Lost Rivers.

Document de développement avec ArcGIS Online des cartes des « Rivières disparues » de Toronto, projet Lost Rivers.

Document de développement de code ouvert des cartes des « Promenades dans la baie d’Ashbridges » de Toronto, projet Lost Rivers.

Document de développement avec ArcGIS Online des cartes des « Promenades dans la baie d’Ashbridges » de Toronto, projet Lost Rivers.

Pour le code ouvert du site, voir: Lost Rivers Toronto Github Open-Source Repository

Neptis Geoweb 4

Le Neptis Geoweb: un aperçu derrière les scènes dans le cadre sous-jacent

Outils SIGH en ligne, Projets SIGH, Visualisations innovantes

Commentaire publié par Vishan Guyadeen, Neptis Foundation. Neptis est un des partenaires du Projet de Partenariat canadien en SIG historique.

Nous sommes dans une ère de données. Des données provenant de différents champs, de qualité variable et de types divers sont de plus en plus disponibles. Cependant, dans de nombreux cas, il peut être difficile de recueillir des informations précieuses à partir de données, car il est possible que l’on ne puisse pas facilement le visualiser ou le comparer avec d’autres ensembles de données.

En étudiant les forces qui forment et qui façonnent les régions urbaines, il est particulièrement difficile de contextualiser les données, car elles existent dans de nombreux endroits différents. Neptis Geoweb est une plate-forme interactive de cartographie et de visualisation de données qui vise à résoudre ce problème. Spécifique à la région de Toronto, Geoweb utilise des données qui sont normalement éparpillées dans diverses organisations gouvernementales afin de rendre les politiques complexes qui façonnent la région plus accessible et plus facile à comprendre.

Un sujet qui nécessite des données souvent difficiles à obtenir, à comprendre et à visualiser est l’histoire du Grand fer à cheval doré (Greater Golden Horseshoe). Neptis Geoweb a une caractéristique unique: la chronologie guide l’utilisateur à travers les politiques et les événements marquants qui ont contribué à façonner la région dans son état actuel. La chronologie est une fonction interactive qui décrit et permet de visualiser les jalons dans le contexte régional. Les utilisateurs peuvent également comparer ces couches de cartes historiques avec d’autres ensembles de données actuelles et historiques pour un contexte plus poussé.

Neptis Geoweb showing historical information about Region of Niagara, keyed to timeline below map
Dans Neptis Geoweb, informations historiques sur la région de Niagara liées au calendrier sous la carte

La création d’une plate-forme capable de présenter et de gérer de grandes quantités de données n’est pas une tâche facile. Neptis Geoweb a été construit avec un cadre entièrement personnalisé, ce qui permet un accès facile, des données claires et à jour, ainsi que la possibilité de maintenir différents types de contenus (cartes, graphiques, texte, etc.). Il existe deux principaux composants sous-jacents qui rendent cela possible.

Le premier composant de Neptis Geoweb, le plus important, est Carto (anciennement CartoDB). Carto est une plate-forme SIG basée sur le « cloud » qui héberge et interroge toutes les couches de données sur le Geoweb. Carto a été utilisé, car c’est une plate-forme puissante et flexible qui est facile à utiliser. Par exemple, Carto permet de manipuler rapidement des données en ligne à l’aide du SQL et de visualiser des données spatiales à l’aide d’une interface utilisateur conviviale ou d’un éditeur CartoCSS avancé (voir la capture d’écran ci-dessous). De plus, Carto offre à Geoweb la flexibilité d’utiliser différents types de données et la possibilité d’interagir en toute transparence avec d’autres plates-formes telles que Leaflet, MapBox et OpenStreetMaps. Ces plates-formes supplémentaires améliorent la fonctionnalité globale de Geoweb. Carto offre de nombreux avantages à Geoweb tout en conservant une facilité d’utilisation générale qui n’exige pas toujours un professionnel en SIG.

Carto graphic interface for editing layer graphics using CartoCSS (one of several methods)
Interface graphique Carto pour l’édition de graphiques de couches utilisant CartoCSS (une des nombreuses méthodes)

Le deuxième composant, l’interface d’administration de Neptis Geoweb, a été conçu sur mesure par les développeurs Carto afin d’organiser et d’entretenir les couches de cartes et d’autres contenus non spatiaux. Le personnel de Neptis est en mesure de préparer, organiser et entretenir des contenus tels que les couches cartographiques, les profils de données municipaux et les récits courts. Lorsqu’il s’agit de grandes quantités de données brutes et de couches de cartes, il est essentiel d’avoir un moyen de gérer le contenu. L’interface d’administration contient des formes simples qui composent le contenu affiché sur Neptis Geoweb. La capture d’écran ci-dessous montre une partie du formulaire requis lors de la création et de la mise à jour des couches de la carte.

Neptis Geoweb custom administrative interface - form for New Layer
Interface d’administration personnalisée de Neptis Geoweb – formulaire pour une nouvelle couche

Ceci est une brève introduction à Neptis Geoweb et les deux composants principaux qui en font une plate-forme efficace. Comme Carto et la cartographie Web dans son ensemble, Neptis Geoweb est un projet en évolution. Au fur et à mesure que de nouvelles données sont disponibles, qu’il s’agisse de zones locales, de région ou au-delà, l’intention est de continuer à enrichir le Geoweb.

OCUL site banner edited crop2

OCUL publie plus de 1000 cartes topographiques anciennes de l’Ontario…

Nouvelles du partenariat CSIGH, Outils SIGH en ligne, Projets SIGH

Commentaire de Amber Leahey, Scholars Portal, et Jay Brodeur, McMaster University Library

Le Ontario Council of University Libraries (OCUL1) est heureux d’annoncer la publication d’une collection numérique partagée de plus de 1000 cartes topographiques anciennes de l’Ontario. Cette collection est maintenant disponible en ligne!

Les cartothèques sont vraiment des endroits merveilleux : demandez simplement à un bibliothécaire ou à un membre du personnel qui offre aux clients des services, des conseils et l’accès aux cartes et au matériel cartographique dans les bibliothèques universitaires de l’Ontario. Ou mieux encore, demandez aux innombrables clients qui utilisent l’information vaste et variée des collections pour soutenir leurs activités de recherches, leur éducation, leur travail et leur vie privée. En effet, il y a beaucoup à dire sur l’intérêt des cartes et des SIG pour raconter une histoire avec les anciennes cartes – qui sont très nombreuses – dans les différentes bibliothèques de la province. Avec des collections de cartes aussi riches et diverses, et grâce à la préservation et la numérisation de plus de 1000 cartes topographiques anciennes de l’Ontario, les bibliothèques universitaires continuent de jouer un rôle clé dans la préservation de notre patrimoine national et provincial à l’ère numérique.

Dirigé par la OCUL Geo Community, le Historical Topographic Map Digitization Project est une collaboration à l’échelle de la province pour inventorier, numériser, géoréférencer et offrir un large accès aux cartes topographiques anciennes de l’Ontario. L’initiative représente le projet de numérisation le plus complet de la collection de cartes de la National Topographic Series (NTS) au Canada. La collection accessible au public permet d’accéder à des cartes topographiques géoréférencées aux échelles 1:25000 et 1:63360 (un pouce par mille), couvrant les villes, cités et régions rurales de l’Ontario de 1906 à 1977. En tant que réalisation collective d’individus représentant diverses bibliothèques universitaires de l’Ontario, cette collection partagée illustre l’engagement continu d’OCUL à des approches collaboratives qui améliorent l’accès au savoir à l’intérieur et à l’extérieur de la province. L’achèvement de ce projet sert également d’occasion de réfléchir sur l’histoire de la OCUL Geo Community et de célébrer la vision et les efforts partagés qui ont rendu possible cette réalisation.

La signification des cartes historiques

Tout comme une photographie, une peinture de paysage ou un texte, une carte historique préserve l’information du passé et offre à celui qui la regarde l’occasion d’explorer les façons dont les environnements, les cultures et la connaissance humaine ont changé au fil du temps. Dans le cadre de leur mission, les collections de cartes, les bibliothèques et les archives ont une longue tradition de préservation et d’accès à un large éventail d’informations cartographiques et culturelles.

À l’heure actuelle, les premières cartes topographiques sont une ressource essentielle pour ceux qui s’intéressent aux événements historiques et explorent les changements au fil du temps. Pour de nombreux chercheurs, les historiens locaux, les planificateurs, les conservateurs, les ingénieurs et les firmes de consultants (pour ne citer que quelques-uns), les cartes topographiques historiques fournissent un regard instantané unique d’une période donnée, montrant à la fois des caractéristiques naturelles et construites par l’homme telles que le relief, les cours d’eau, les rivages, les limites géographiques, les routes, les chemins de fer, les maisons, les granges, les lignes électriques, les industries et bien plus encore.

Ottawa’s Changing Landscape and Growth 1906-1948
Compilation animée des premières cartes topographiques de la région d’Ottawa montrant les changements et la croissance entre 1906 et 1948
De la guérison à la numérisation: le rôle de la OCUL Geo Community

Parmi les défis auxquels fait face la production d’une collection numérique aussi complète, il faut s’efforcer d’inventorier et de rassembler des planches qui existent dans une multitude de cartothèques. Compte tenu de la variété et de la quantité de cartes créées pendant une période donnée et de la nature limitée de l’espace de stockage et des budgets, les conservateurs sont tenus de faire des choix prudents (et souvent difficiles!) sur les collections qu’ils développent, délèguent et préservent à travers le temps. En conséquence, de nombreuses institutions ont concentré leurs collections de cartes topographiques autour d’éléments de pertinence et d’importance locales. En Ontario, par exemple, les cartes qui composent la série numérisée – originellement produite par le ministère de la Défense nationale (jusqu’en 1923 : le Département de la Milice et de la Défense) – sont dispersées dans de nombreuses bibliothèques universitaires de l’Ontario. Au fil des ans, les bibliothèques de l’Ontario ont collaboré à l’élaboration d’un inventaire complet des cartes connues de la série existante, en étroite collaboration avec les Archives de l’Ontario et Bibliothèques et Archives Canada plus récemment pour ce projet de numérisation. Que la grande majorité des planches de ces collections pourraient être trouvées dans les établissements OCUL témoigne du travail fondamental des premières communautés Geo et Map.

Prédécesseur de la OCUL Geo Community, le OCUL Map Group (alors connu sous le nom de OULC Map Group) a été créé en 1973 dans le but de communiquer et de collaborer à des projets liés à la cartographie. Parmi leurs initiatives achevées figure la création d’un catalogue collectif de cartes topographiques dans toutes les institutions. L’importance de ce travail pour le succès actuel d’OCUL Geo ne doit pas être négligée, car ces efforts fondamentaux ont permis de coordonner les collections de cartes dans les établissements OCUL et ont contribué à assurer une couverture collective maximale de manière rentable et économique. Aujourd’hui, la OCUL Geo Community poursuit les objectifs de son prédécesseur, en s’engageant à favoriser le dialogue autour de questions importantes telles que les meilleures pratiques pour la numérisation des cartes dans les bibliothèques, l’accès aux cartes et les SIG pour la recherche et collaboration sur une variété d’activités de la bibliothèque dans ces domaines.

Dans l’avenir, le groupe envisage s’engager avec la grande communauté canadienne en cartographie au sujet du projet, en particulier lors de la prochaine Conférence Carto 2017 de l’Association des cartothèques et archives cartographiques du Canada à Vancouver, en juin (site web de l’ACACC). Le groupe espère identifier les occasions de construire sur le projet, s’engager avec d’autres bibliothèques universitaires et archives pour numériser des cartes de cette collection nationale.

Nous sommes très enthousiastes face à la publication de cette collection, veuillez nous faire savoir comment vous comptez utiliser les cartes dans vos prochains projets. Pour plus d’informations ou pour contacter les membres du projet, écrivez à topomaps@scholarsportal.info.

Nous espérons avoir de vos nouvelles!

1 Ocul est un consortium de 21 bibliothèques universitaires en Ontario qui favorise la collaboration autour des activités et des services de la bibliothèque, y compris les collections de cartes et de SIG, la numérisation et la conservation numérique. Les bibliothèques universitaires de l’Ontario ont travaillé ensemble par l’intermédiaire de OCUL sur des initiatives comme celle-ci depuis 1967. En 2017, OCUL célèbre son 50e anniversaire et ce projet démontre le succès de cette collaboration.

À la recherche de données SIGH canadiennes

Avancement du projet, Outils SIGH en ligne

Depuis plusieurs années, des quantités appréciables de données géohistoriques ont été créées par les chercheurs qui s’intéressent au Canada. Alors que l’on réfléchit à la création d’une infrastructure géohistorique nationale, il est pertinent d’identifier les jeux de données à différentes échelles qui pourront nourrir un tel portail. La démarche actuelle vise donc à faire connaître les jeux de données existants et disponibles. Si, à terme, il serait préférable d’énumérer et de décrire chaque couche et chaque table de données attributaires, il n’est pas nécessaire, en ce moment, d’aller à un niveau de granularité aussi fin. Nous espérons plutôt, à cette étape, identifier les collections découlant de différents projets de recherches ou de mise en ligne des données numériques déjà géoréférencées comme celles-ci :

  • cartes géographiques matricielles
  • photographies aériennes
  • couches vectorielles
  • données attributaires liées à des couches vectorielles

Nous avons déjà identifié une série de données offertes par différents types de créateurs, question de présenter une diversité dans la nature et les types de données qui peuvent intéresser les chercheurs. Ainsi, on y retrouve :

  • des données internationales de qualité (FAO)
  • des données issues de projets de cartographie collaborative (Open Street Map, Natural Earth)
  • des données disponibles sur les sites d’entreprises en SIG (ESRI)
  • des données nationales (gouvernement du Canada, Géogratis)
  • des données provinciales ou territoriales (Colombie-Britannique, Yukon, Québec, Nouvelle-Écosse, Île-du-Prince-Édouard, Nouveau-Brunswick)
  • des données municipales (Toronto, Montréal, Sherbrooke)
  • des données d’équipes de recherche (CIEQ, NICHE, LHPM, MAP, VIHistory)
  • des données de cartothèques et de centres d’archives (Scholars’ Geoportal, MADGIC, GéoIndex+)
  • des données d’initiatives personnelles (lignes de chemins de fer historiques)

Le choix des métadonnées à associer à chaque jeu de données nous amène à faire des compromis. Un niveau de détail insuffisant ne permettrait pas de faire des recherches efficaces alors qu’un niveau de détail trop grand pourrait décourager les créatrices et les créateurs de données qui ne sont pas formés pour créer des métadonnées qui répondent aux standards internationaux. Selon Rodolphe Devillers, six caractéristiques sont nécessaires pour définir la qualité d’un jeu de données géospatiales1.

i. Définition : Permet d’évaluer si la nature exacte d’une donnée et de l’objet qu’elle décrit, c.à.d. le « quoi », correspond aux besoins (définitions sémantique, spatiale et temporelle);

ii. Couverture : Permet d’évaluer si le territoire et la période pour lesquels la donnée existe, c.à.d. le « où » et le « quand », correspondent aux besoins ;

iii. Généalogie : Permet de connaître d’où provient une donnée, ses objectifs d’acquisition, les méthodes utilisées pour l’obtenir, c.à.d. le « comment » et le « pourquoi », et de voir si cela correspond aux besoins;

iv. Précision : Permet d’évaluer ce que vaut une donnée et si elle est acceptable pour le besoin exprimé (précision sémantique, temporelle et spatiale de l’objet et ses attributs);

v. Légitimité : Permet d’évaluer la reconnaissance officielle et la portée légale d’une donnée et si elles rencontrent les besoins (standards de facto, respect de normes reconnues, reconnaissance légale ou administrative par un organisme officiel, garantie légale par un fournisseur, etc.);

vi. Accessibilité : Permet d’évaluer la facilité avec laquelle l’usager peut obtenir la donnée analysée (coût, délai, format, confidentialité, respect des normes reconnues, droits d’auteur, etc.).

Un standard de métadonnées permettant de répondre à tous ces critères risquerait de rebuter plusieurs personnes qui souhaiteraient rendre leurs données accessibles. Nous proposons donc d’utiliser le format prescrit par le Dublin Core Metadata Initiative, un standard international dont les types de champs sont plus compréhensibles pour les personnes moins familières avec les métadonnées. Nous appliquons et interprétons le DCMI en nous inspirant de la définition générale disponible sur Wikipédia2 et des interprétations de certains champs proposés par la Bibliothèque nationale de France3. L’approche utilisée peut certainement être critiquée, car elle vise une application simple plutôt que la perfection. À la lumière de leur utilisation dans cette liste, nous pourrons évaluer comment revoir ces principes afin d’en arriver au meilleur compromis possible. Les champs n’apparaissent pas dans l’ordre prescrit par le DCMI et certains sont subdivisés afin d’apporter certaines précisions et d’en arriver à un niveau de granularité un peu plus fin.

Tableau 1. Liste des champs utilisés pour décrire les jeux de données

Élément Élément (anglais) Commentaire
Créateur Creator L’entité principalement responsable de la création du contenu de la ressource. Il s’agit du nom d’une ou de plusieurs personnes, d’une organisation ou d’un service.
Format : Nom, Prénom.
Séparer par des points-virgules les multiples entités.

Optionnel
Contributeur Contributor Entité responsable de contributions au contenu de la ressource.
Les exemples de contributeur comprennent une ou plusieurs personnes, une organisation ou un service.
Format : Nom, Prénom.
Séparer par des points-virgules les multiples entités.

Optionnel
Titre Title Nom donné à la ressource.
Le titre est généralement le nom formel sous lequel la ressource est connue.
Utiliser le titre tel qu’indiqué dans la langue d’origine de la ressource.
Si la ressource ne porte pas de titre formel et que le titre inscrit est dérivé du contenu, inscrire le titre entre crochets.

Obligatoire
Description.Générale Description.General Une présentation du contenu de la ressource.
Les exemples de description comprennent, notamment un exposé du contenu en texte libre.
Privilégier la description prévue par les créatrices ou les créateurs de la ressource.

Optionnel
Description.Nature-du-projet Description.Project-type Un mot-clé qui permet de classer les projets selon la typologie suivante :

– gouvernementale
– ONG
– universitaire
– individuelle
– commerciale
– collaborative

Obligatoire
Description.Méthodologie Description.Methodology Un texte suivi décrivant la démarche suivie pour créer la ressource. Optionnel
Description.Sources Description.Sources Énumération des documents qui ont servi à créer la ressource. Ce champ est distinct du champ Source, lequel sert à identifier l’endroit où on peut se procurer la ressource. Optionnel
Description.Champs Description.Fields Liste des champs utilisés dans le tableau ou la base de données, si possible avec description.

Optionnel
Date.Publication Date.Published Date de la création initiale de la ressource. Il ne s’agit pas nécessairement de la date représentée par la ressource.

Obligatoire
Date.Mise-à-jour Date.Updated Date d’un événement de mise à jour dans le cycle de vie de la ressource.

Optionnel
Couverture.Temps Coverage.Time Périmètre ou domaine d’application du contenu de la ressource, dans ce cas-ci, la date, l’année ou la période représentée par la ressource.

Obligatoire
Couverture.Espace Coverage.Space Périmètre ou domaine d’application du contenu de la ressource, dans ce cas-ci le territoire. intervalle de temps) ou une autorité (comme le nom d’une entité administrative). Il est recommandé de sélectionner une valeur dans un vocabulaire contrôlé.

Obligatoire
Couverture.Niveau Coverage.Level Un mot-clé qui permet d’identifier le niveau de couverture spatiale de la ressource :

– international
– national
– provincial
– régional
– municipal
– local

Obligatoire
Sujet.ISO Subject.ISO Un mot-clé permettant d’associer la ressource à une des catégories de classement ISO des données géospatiales.

– agriculture / farming
– biota / biota
– limites administratives / boundaries
– climatologie / climatology
– économie / economy
– élévation / elevation
– environnement / environment
– information géoscientifique / geoscientific information
– santé / health
– imagerie / imagery
– intelligence / intelligence (militaire)
– eaux intérieures / inland waters
– localisation / location
– océans / oceans
– urbanisme / planning
– société / society
– structure / structure
– transport / transportation
– services publics / utilities

Voir : https://geo-ide.noaa.gov/wiki/index.php?title=ISO_Topic_Categories

Obligatoire
Sujet Sujet Un ou des mot-clés permettant de classer la ressource. Optionnel
Format Format La manifestation (ou matérialisation) physique ou numérique de la ressource. Type MIME du document :

– shp
– kml
– kmz
– zip
– csv
– autres formats de données utilisés en SIG

Obligatoire.
Langue Language La langue du contenu intellectuel de la ressource.
Il est recommandé d’utiliser une des valeurs définies dans la RFC 3066 [RFC3066] qui, avec la norme ISO 639 [ISO639], définit des codes de langues primaires à deux, ainsi que des sous-codes facultatifs.
Exemples :- en
– fr

Obligatoire
Type de ressource Type Genre de contenu.
Par défaut, les ressources identifiées dans le cadre de ce projet font partie du type dataset (jeu de données).

Obligatoire
Droits.Licence Rights.License Identification brève du type de licence qui s’applique aux données :

– copyright
– CC (ou une ses variantes)
– domaine public
– ouverte

Obligatoire
Droits.Accessibilité Rights.Access Un des termes suivants permettant d’identifier la nature de l’accès aux données.

– gratuit
– payant
– abonnement gratuit
– abonnement payant

Obligatoire
Droits.Conditions d’utilisation Rights.Terms of use Texte copié et collé du site même pour préciser les conditions d’utilisation prescrites par l’équipe de création. Optionnel
Source Source Emplacement à partir duquel on peut obtenir la ressource. La source sera généralement un URL.
Un champ Source.URI pourra être ajouté si cela s’avère pertinent.

Obligatoire
Relation Relation Lien avec d’autres ressources. Une ressource peut être dérivée d’une autre ou être associée à une autre dans le cadre d’un projet.
Exemples : isPartOf [numéro de l’autre ressource]
isChildOf [numéro de l’autre ressource]
isDerivedFrom [numéro de l’autre ressource]

Optionnel
Éditeur Publisher Nom de la personne, de l’organisation ou du service à l’origine de la publication du document.

Optionnel
Commentaire Comment Tout information complémentaire qui permet de mieux comprendre la ressource.

Optionnel

Une liste de ressources déjà identifiées est disponible ici : http://bit.ly/2rlIkRC.
Certaines notices sont incomplètes et nous travaillerons à les compléter. Si vous désirez proposer un jeu de données, vous pourrez le faire en remplissant le formulaire suivant disponible ici : http://geohist.ca/donnees-sigh-hgis-data-form

1  DEVILLERS, Rodolphe (2004). « Conception d’un système multidimensionnel d’information sur la qualité des données géospatiales », [En ligne], Ph. D., Université Laval <http://theses.ulaval.ca/archimede/fichiers/22242/22242.html>.

2  Collaborateurs de Wikipédia (2016). « Dublin Core » <https://fr.wikipedia.org/wiki/Dublin_Core#Liste_des_.C3.A9l.C3.A9ments_et_raffinements>.

3  Bibliothèque nationale de France, Direction des Services et des Réseaux, Département de l’Information bibliographique et numérique (2008). « Guide d’utilisation du Dublin Core (DC) à la BnF : Dublin Core simple et Dublin Core qualifié, avec indications pour utiliser le profil d’application de TEL », version 2.0 <http://www.bnf.fr/documents/guide_dublin_core_bnf_2008.pdf>.

Edelson_MapScholar

Utiliser Mapscholar.org pour mettre les cartes Murray du Canada (ca 1761) en ligne

Enseigner avec les SIGH, Outils SIGH en ligne, Projets SIGH, ,

Billet de S. Max Edelson, University of Virginia

Ce semestre, je mène un groupe d’universitaires de l’Université de Virginie dans un cours de sciences humaines collaboratif et par projet pour mettre les cartes Murray du Canada en ligne dans une exposition numérique dynamique. En tant que séminaire sélectif du Pavillon, cette « Pratique numérique dans l’histoire de la carte » est une expérience pratique qui combine la lecture, l’écriture et la discussion traditionnelle avec un atelier de développement des sciences humaines numériques. Cela implique un regard interdisciplinaire sur l’histoire de la cartographie, du design visuel, des sciences humaines numériques, de l’histoire publique et de l’histoire mondiale de l’empire.

Alors que les bibliothécaires analysent le contenu de leurs archives cartographiques, préservant des artefacts fragiles en créant des images de haute résolution, de nouveaux outils sont développés pour présenter ces objets historiques à un large public. L’un de ces outils est MapScholar, un outil en réseau pour la création de visualisations utilisant un navigateur web conçu pour illustrer les recherches en histoire de la cartographie. Avec le soutien de l’ACLS et du NEH, le chercheur Bill Ferster et moi-même avons construit MapScholar au SHANTI (Sciences, Humanities, and Arts Network of Technological Initiatives) de l’Université de Virginie. Mon objectif principal était de construire une plate-forme dynamique pour afficher quelque 300 cartes qui font l’objet de mon prochain livre, The New Map of Empire: How Britain Imagined America before Independence (Harvard University Press, 2017). Parmi les nombreuses cartes que j’ai examinées pour cette recherche, j’ai été intrigué par la collection de cartes Murray à la William H. Clements Library de L’Université du Michigan. Cette grande collection de manuscrits, qui est également détenue par la British Library et Bibliothèque et Archives Canada, a semblé être une source idéale pour être montrée et visualisée en ligne. Réunir toutes ses pièces disparates grâce au géoréférencement nous permet d’apprécier pleinement la portée et l’ambition de cette étude du XVIIIe siècle et du projet de cartographie.

Lorsque les forces britanniques ont occupé la Nouvelle-France en 1760, le gouverneur militaire du territoire, le général James Murray, a lancé une enquête approfondie sur ce qui deviendrait, après la cession officielle en 1763, la colonie britannique de Québec. L’incitation à cartographier le Québec venait des conceptions militaires plutôt qu’administratives. Murray s’attendait à ce que la province soit rendue à la France après la négociation de la paix et il voulait rassembler des informations stratégiques qui pourraient être utiles à une invasion future. Comme Murray l’a expliqué à William Pitt en 1762, avec ce sondage en main pour révéler les passages complexes le long des cours d’eau de la vallée du fleuve Saint-Laurent, la Grande-Bretagne « ne sera plus jamais perplexe quant à la manière d’attaquer et de conquérir ce pays en une seule campagne. » Murray a envoyé huit ingénieurs de l’armée pour mener des enquêtes sur différentes sections de la rivière. La carte composite qu’ils produisaient contenait 74 sections cartographiées séparément qui, lorsqu’elles étaient réunies, formaient une image interconnectée de 45 pieds le long et 36 pieds de hauteur. Représentant un espace à l’échelle de deux mille pieds par pouce, ces cartes figuraient parmi les cartes topographiques de la plus haute résolution produites par les arpenteurs du XVIIIe siècle. La conception des cartes de Murray comme profil stratégique de la province a été précisée par l’ajout de résumés démographiques qui énumèrent combien d’hommes capables de porter des armes vivaient dans chaque district.

Les conservateurs en cartographie Brian Dunnigan et Mary Pedley à la William L. Clements Library de l’Université du Michigan ont fourni des documents numériques à haute résolution de la carte Murray et ont rencontré les élèves de la classe par vidéoconférence pour nous aider à le développer. En participant au géoréférencement des cartes, à la conception de visualisations dynamiques, à l’enregistrement de métadonnées, à la gestion des ressources Web distribuées et à l’écriture d’essais et d’annotations qui fournissent un contexte et une interprétation, les élèves auront une expérience de première main dans le domaine des sciences humaines numériques.

Nous venons de commencer à géoréférencer la collection. Je vais fournir des mises à jour sur nos progrès dans une future publication.

S. Max Edelson est professeur agrégé à l’Université de Virginie au Corcoran Department of History .

Cartographiez votre histoire! Construire et partager une infrastructure de données spatiales historiques avec Keweenaw Time Traveler Project

Enseigner avec les SIGH, Outils SIGH en ligne, Projets SIGH

Alors que le SIG historique (SIGH) est devenu une approche familière dans les sciences sociales et humaines (Gregory et Geddes, 2014), les tendances récentes de l’utilisation des SIG dans les sciences sociales ont requis des mises en oeuvre des SIGH qui peuvent appliquer des approches SIGH découlant de la datamasse (Big Data) à des questions de recherches plus qualitatives et, peut-être plus important encore, impliquer davantage le public. Les approches vont de permettre aux utilisateurs de contribuer à la recherche SIGH en utilisant des interfaces Web améliorées, telles que le New York Public Library’s Building Inspector, à l’expansion de la recherche qualitative SIGH (Olson, 2011; Lafreniere et Gilliland, 2015). Dans le monde des sciences SIG, les chercheurs ont développé des combinaisons d’outils qualitatifs et quantitatifs hybrides qui élargissent encore le potentiel de la recherche en SIG (Kwan and Ding, 2008; Jung et Ellwood, 2010). Ces derniers sont plus récemment devenus des sujets d’intérêt pour la communauté SIGH. Faisant parti de cette tendance,  Michigan Technological University’s Historic Environments Spatial Analytics Lab (HESAL) se prépare à lancer le Keweenaw Time Traveler project – combinant la dernière génération d’infrastructure de données spatiales historiques avec la technologie Web 2.0 et la diffusion publique de manière à favoriser des liens plus étroits entre la recherche et le public en rendant l’histoire à la fois amusante et accessible.

 

Notre sujet en bref: le Pays du Cuivre

Le Keweenaw Time Traveler Project (KeTT) apporte au public un SIGH régional axé sur le Pays du Cuivre du Haut-Michigan, une région du Midwest des États-Unis qui contient les plus grands gisements de cuivre pratiquement pur, élémentaire ou natif. Les Amérindiens ont exploité cette ressource pendant des milliers d’années; un boom de cuivre industriel subséquent au milieu du 19e siècle a conduit la région à devenir le plus grand fournisseur mondial de cuivre dans les années 1880, avec une population en croissance rapide et une infrastructure minière massive construite rapidement dans ce qui était une nature sauvage éloignée bien que spectaculaire. À la fin de la Première Guerre mondiale, les facteurs économiques associés au coût croissant de l’extraction ont entraîné une longue et lente baisse de l’économie minière du Pays du Cuivre, se terminant par la fermeture des dernières mines à la fin des années 1960. Lorsque l’activité minière a cessé, toute la région est devenue un vaste site d’archéologie industrielle, un paysage de vestiges. Aujourd’hui, la taille de la population n’est qu’une fraction de son sommet historique et la base économique du Pays du Cuivre se concentre maintenant dans les domaines du service et du tourisme. L’identité locale reste toutefois étroitement liée au patrimoine minier de Keweenaw et la région attire autant les visiteurs pour son histoire minière que pour sa beauté naturelle.

www.mapyourhistory.org
www.mapyourhistory.org

Construire la fondation du KeTT: Jeux de données et CC-HSDI

Le Keweenaw Time Traveler bénéficie de la richesse des données historiques trouvées dans son domaine d’activité géographique. Les plus grandes sociétés minières historiques de cuivre de la région, telles que les sociétés minières Calumet & Hecla ainsi que Quincy, figuraient parmi les grands géants industriels de leur époque. L’échelle de leur entreprise nécessitait une vaste infrastructure industrielle, ainsi que des villes de compagnies pour loger leurs travailleurs. Ces dernières devaient être conçues, construites et financées. Par conséquent, la plupart des villes et des grands sites miniers dans le Pays du Cuivre sont extraordinairement bien documentés sous la forme d’un vaste ensemble de plans d’assurance-incendie Sanborn (PAI), des cartes produites par les compagnies minières dont les détails surpassent même les PAI, des dessins et des bleus. À l’ère du paternalisme corporatif et des pratiques de gestion scientifique, les sociétés minières ont également largement documenté la vie de leurs travailleurs et de leurs familles. L’équipe de KeTT a commencé la numérisation d’une richesse sans précédent de dossiers détaillés sur le logement de l’entreprise, les dossiers des employés et les dossiers de santé qui fournissent beaucoup plus d’informations que les données de recensement standard. Ceux-ci sont combinés avec les données décennales du recensement du Minnesota Population Center, les annuaires commerciaux et téléphoniques et les dossiers scolaires afin de donner un aperçu unique et détaillé de l’histoire d’une région entière jusqu’au niveau de l’individu au cours d’un siècle.

Le coeur du projet est le Copper Country Historical Spatial Data Infrastructure (CC-HSDI) (Infrastructure de données spatiales historiques du Pays du Cuivre), une nouvelle implémentation de SIGH de nouvelle génération conçue pour faciliter la recherche quantitative et qualitative tout en favorisant l’engagement du public avec l’histoire locale et le concept de SIGH lui-même. À l’aide d’ArcGIS Desktop, ArcGIS Server et d’une base de données géospatiales PostgreSQL, le CC-HSDI comprend  une série de cartes en réseau (map service) ESRI constituées de cartes géoréférencées ou de PAI divisés en une série de tranches de temps à peu près égales aux années de recensement (en plus des collections de cartes plus petites pour les autres années). La construction de ce service de carte a présenté un défi initial pour l’équipe de KeTT, car la taille de chaque service de carte (représentant une seule ville et une seule année) exigeait des dizaines de gigaoctets et nécessité la création d’un serveur dédié PostreSQL au Michigan Tech. L’expansion ultérieure de la HSDI nécessitera que ces services migrent vers une installation de serveur à échelle industrielle hors site (Amazon AWS) dans un avenir rapproché.

L’environnement historique de chaque tranche de temps construit dans le CC-HSDI est ensuite numérisé à la main à partir des cartes en réseau, ce qui donne lieu à plus de cent mille polygones d’empreinte immobilière (ainsi que des routes, des lignes ferroviaires et quelques autres éléments d’infrastructures). Ces fichiers SIG de polygones servent de point d’ancrage géographique pour toutes les données historiques non cartographiques du CC-HSDI que nous avons mentionnées précédemment et constituent « l’étape de l’environnement bâti » du HSDI (suivant le modèle de Lafreniere et Gilliland, 2015). Cette étape comprend non seulement l’empreinte du bâtiment elle-même, mais d’autres données pertinentes transcrites des PAI, y compris l’aménagement spatial, les adresses et un certain nombre d’histoires pour chaque bâtiment.

Liées à l’étape de l’environnement bâti, les bases de données géospatiales comprennent des sources non cartographiques comprenant les données de recensements, les répertoires d’entreprises, les annuaires téléphoniques et les dossiers d’entreprises et d’écoles. Ces enregistrements capturent l’environnement social de chaque tranche de temps avec des détails incroyables, comprenant par exemple la liste des élèves du primaire qui ont été vaccinés ou le profil médical des employés de l’entreprise minière. Associé aux données du recensement et aux données du répertoire des entreprises qui sont déjà des éléments de base de SIGH, cette « étape de l’environnement social » (selon Lafrenière et Gilliland, 2015) représente non seulement un pas en avant de la capacité des SIGH à contribuer à la recherche qualitative sur les environnements sociaux, mais fournit au public une multitude d’informations locales qui favorisent une connexion personnelle avec les SIGH.

The KeTT prototype web apps, developed in ArcGIS Online Web AppBuilder, allowed the team to gain valuable experience in developing requirements for the forthcoming full public launch of the KeTT Project.
Les applications web prototypes du projet KeTT développées dans ArcGIS Online Web AppBuilder ont permis à l’équipe d’acquérir une expérience précieuse dans le développement des exigences pour le prochain lancement public du projet complet de KeTT.

Sensibilisation et collaboration publiques: Le Keweenaw Time Traveler

Alors que CC-HSDI est un outil de recherche inestimable à part entière, le projet KeTT sert à faire découvrir au public une nouvelle façon de visualiser leurs environnements passés. Cela se fait grâce à l’utilisation d’applications Web. Chaque application représente une autre façon d’explorer ou de contribuer au SIGH. Le KeTT développe actuellement quatre applications Web différentes qui permettent au public d’interagir et de contribuer au HSDI. Ces applications Web fournissent à l’utilisateur des tâches allant des exercices d’interaction de carte historiques à faciliter la narration plus complexe :

  • Enregistrement de l’environnement construit avec le matériel de construction (en utilisant les codes de couleurs du plan d’assurance incendie)
  • Identifier et enregistrer le type d’utilisation général (structure d’habitation, commercial, institutionnel)
  • Transcrire un texte de carte descriptif pour les bâtiments individuels
  • Contribuer en fournissant des histoires personnelles et des souvenirs sur des endroits spécifiques sur les cartes historiques

Initialement, l’équipe a utilisé le Web Appbuilder de ArcGIS Online pour créer et tester ces applications pour le KeTT. Les applications ArcGIS en ligne sont une excellente ressource pour les chercheurs en SIGH cherchant à partager des données avec le public. Les chercheurs ayant peu ou pas de connaissance en programmation peuvent rapidement convertir des données SIG en applications Web personnalisables, accessibles au public et qui profitent de l’infrastructure dorsale robuste d’ArcGIS Online. Cependant, les grands ensembles de données matricielles peuvent devenir coûteux à partager de cette façon, car la mise en place d’outils d’analyse géospatiale consomment des crédits ESRI. Après avoir construit plusieurs prototypes, l’équipe de KeTT a également réalisé qu’ils voulaient plus de contrôle sur les interfaces de l’application et sur la logique de programmation sous-jacente que les options offertes par le Web AppBuilder. Cela impliquait l’embauche d’un programmeur et le développement d’applications Web personnalisées en version JavaScript qui utilisaient la carte ESRI et les services de fonctionnalité de CC-HSDI. Malgré cela, ArcGIS Online Web AppBuilder s’est révélé inestimable pour la création de prototypes d’applications et a permis à l’équipe de développer des idées plus claires sur l’apparence des applications Web finales.

Le projet GRACE

Le projet KeTT a mis l’accent sur la sensibilisation et la participation du public comme composante essentielle de la construction du SIGH et non comme une ultime étape de diffusion ou d’utilisation finale. Les applications web ont permis d’atteindre cet objectif. Le projet  GRACE de l’été dernier a servi d’exemple du potentiel du projet KeTT. Le projet G.R.A.C.E. (GIS Ressources and Applications for Career Education project) (Ressources SIG et Applications pour le projet d’éducation professionnelle) est une collaboration financée par la NSF impliquant Dr. Yichun Xie, PhD, professeur/ directeur au Institute of Geospatial Research and Education de Easter Michigan University, Dr. Don Lafreniere chez HESAL de MTU, l’Université virtuelle du Michigan ainsi que plusieurs organisations SIG professionnelles à l’échelle de l’État. Le financement permet de dispenser une formation pratique sur l’utilisation des SIG aux étudiants et aux enseignants des communautés économiquement désavantagées. L’été dernier, le projet GRACE s’est associé au Keweenaw National Historic Park pour offrir des activités au Pays du Cuivre. Les stagiaires recrutés dans les écoles secondaires locales ont rejoint le HESAL du MTU à Houghton, Michigan, pour numériser les principales parties de l’environnement bâti de KeTT à partir des plans d’assurance incendie de Sanborn. Au cours du stage, les étudiants de GRACE ont non seulement appris à acquérir des compétences en SIG, mais ont également exploré l’histoire de leur communauté locale à un niveau de détail auquel peu de personnes ont accès. À la fin du stage, les stagiaires ont utilisé StoryMaps d’ArcGIS Online pour partager des parties de leur histoire locale qu’ils ont trouvées les plus intéressantes pendant leur travail avec les membres du public. L’équipe de KeTT estime que le projet GRACE était un excellent moyen d’impliquer la communauté locale de manière à offrir des avantages réels et à générer de la publicité dans le processus.

 

The GRACE project took high school students into the lab and field, helping to build the Copper Country HSDI while also using it to explore the historical built environment of their local community and, ultimately, to share their experiences through public presentations.
Le projet GRACE a permis aux élèves du secondaire de travailler dans le laboratoire et sur le terrain, en aidant à construire le HSDI du Pays de Cuivre tout en l’utilisant pour  explorer l’environnement bâti historique de leur communauté locale et, en fin de compte, partager leurs expériences par le biais de présentations publiques.

Prochaines étapes

Bien que beaucoup ait été accompli jusqu’à présent, le projet KeTT commence tout juste à se prendre son envol. Nous prévoyons dévoiler le projet au public ce printemps en remplaçant les applications Web bêta actuelles sur le site Web du projet par des applications Web complétées et personnalisées qui permettent au public d’explorer, d’interagir avec et de contribuer au Keweenaw Time Traveler. La sortie des applications finales coïncidera avec une nouvelle saison des activités de sensibilisation de l’équipe KeTT en partenariat avec Keweenaw National Historic Park et Keweenaw Heritage Sites afin de sensibiliser le public au projet. En plus du projet GRACE en cours, nous proposons des kiosques à écran tactile personnalisés à de nombreux événements publics autour de Keweenaw qui permettent aux utilisateurs d’utiliser les applications Web KeTT avec l’aide des membres de l’équipe KeTT et des partenaires. Restez à l’écoute sur www.mapyourhistory.org!

Références

Gregory, I. N. et Geddes, A. (2014). Toward spatial humanities: Historical GIS and spatial history. Bloomington: Indiana University Press.

Jung, J.-K. et Elwood, S. (2010). Extending the Qualitative Capabilities of GIS: Computer-Aided Qualitative GIS. Transactions in GIS, 14, 1, 63-87.

Kwan, M.-P. et Ding, G. (2008). Geo-Narrative: Extending Geographic Information Systems for Narrative Analysis in Qualitative and Mixed-Method Research. The Professional Geographer, 60, 4, 443-465.

Lafreniere, D. et Gilliland, J. (2015). “All the World’s a Stage”: A GIS Framework for Recreating Personal Time-Space from Qualitative and Quantitative Sources. Transactions in GIS, 19, 2, 225-246.

Olson, S. et Thornton, P. A. (2011). Peopling the North American city: Montreal 1840-1900. Montreal: McGill-Queen’s University Press.

Donner une nouvelle vie aux anciennes données SIG historiques

Outils SIGH en ligne, Projets SIGH

— Les avantages de la « longue traîne » des données des projets Ontario Historical County Map Project et Don Valley Historical Mapping Project

La plupart des universitaires qui ont écrit sur les SIG historiques ont discuté du coût élevé de la construction de projets SIGH (Gregory et Ell, 2007). La construction d’un projet SIG est un effort couteux. Cependant, peu ont mentionné les avantages de la nature continue ou de la durée prolongée de certains projets et des avantages à long terme des données issues des projets. Le Ontario Historical County Map Project (OCMP) et le Don Valley Historical Mapping Project (DVHMP) sont deux projets qui ont profité de la « longue traîne » de leur existence afin de continuer à développer et à exploiter des applications utiles ainsi que d’utiliser des données historiques construites depuis longtemps (ou en cours de construction).

Le OCMP a été conçu quelques années après la publication du célèbre Canadian County Atlas Project aux bibliothèques de l’Université McGill à la fin des années 1990. Les cartes de comté du XIXe siècle ont généralement été publiées plus tôt que les atlas de comté. Le projet Atlas se concentre uniquement sur les cartes liées et l’OCMP se concentre uniquement sur les cartes antérieures de grand format. Toutefois, comme le projet Atlas, le County Map Project vise principalement à permettre d’interroger les noms des occupants des terrains figurant sur les cartes et d’afficher les noms sur les images des cartes historiques.

Fortin 2017 3
Canadian Historical County Map Project résultat d’une recherche par nom dans la planche de la municipalité d’Etobicoke, York County Atlas, 1878

Bien que le projet de McGill n’utilise pas de technologie SIG pour afficher des informations sur les noms, il a profité de la technologie Web pour faire la mise en page des images des atlas et de la programmation PHP pour lier les emplacements d’images dans la base de données des noms des propriétaires fonciers. Le projet Atlas nous a certainement inspirés dans l’élaboration du Ontario Conunty Map Project.

Contrairement au projet Atlas, l’OHCMP a été un projet SIG dès le début. Cependant, comme pour le projet Atlas, nous voulions également veiller à ce que les utilisateurs du County Map Project puissent bénéficier de la technologie Web pour visualiser les cartes et les données SIG. Étant une base de données SIG, une nouvelle méthode de diffusion devait être utilisée.

Les tests préliminaires de la technologie Web étaient « pré-Google » et utilisaient ce qui est maintenant un logiciel archaïque de cartographie Web. Lors de notre première tentative en 2004, nous avons utilisé ArcIMS (Internet Map Server) d’Esri, mis à notre disposition dans le cadre de notre licence de campus avec Esri Canada. Nous avons chargé notre base de données entière dans ArcIMS qui, à l’époque, était composée uniquement des comtés de Waterloo et Brant. À notre surprise, nous avons pu construire un outil de requête sophistiqué et avons réussi à afficher les cartes de comtés numérisées et géoréférencées sur l’application en ligne.

 

Ontario Historical County Map Project rendered in Esri’s ArcIMS software
Ontario Historical County Map Project rendu dans le logiciel ArcIMS d’Esri

Tout en produisant des résultats relativement impressionnants pour l’époque (si quelqu’un était suffisamment patient pour attendre les résultats d’une requête ou d’un zoom in ou d’un zoom out), il était clair que cette configuration était moins idéale, car le logiciel était extrêmement difficile à installer, très lent à rendre les résultats et nous a donné des difficultés à trouver un espace serveur adéquat sur lequel installer en permanence le logiciel. En raison des limitations des logiciels disponibles, la partie du projet qui consistait à développer une carte Web avec les noms des occupants fonciers a été mise en veilleuse. Bien sûr, Google Maps a changé l’ensemble du paysage de la cartographie Web en 2005. Bien que beaucoup aient adopté Google Maps pour afficher leurs données sur le Web, nos tentatives ont été entravées par la grande taille de notre base de données des occupants. Alors que, à l’époque, MySQL était souvent utilisé pour travailler avec le PHP et Google API, la conversion de notre base de données géospatiale en une base de données MySQL aurait été un recul dans le développement SIG du projet.

D’autres tentatives plus récentes d’utilisation de la technologie de cartographie Web en 2013 incluaient également une configuration Mapserver avec OpenLayers et une base de données géospatiale PostgreSQL utilisant PostGIS. Bien que les données shapefile devaient être converties en PostGIS, cette configuration a au moins permis la maintenance de notre base de données dans un environnement SIG, contrairement à l’utilisation de MySQL. La carte Web qui en a résulté était très prometteuse, mais nécessitait un peu de codage et de manipulation. N’ayant aucun programmeur dans l’équipe ou aucun fonds pour en embaucher un, la programmation de l’application était limitée à un congé de recherche de six mois et aux rares journées tranquilles à la Map and Data Library. Sans un programmeur, il était clair qu’il ne s’agissait pas d’une solution idéale et qu’il faudrait des années pour terminer le projet.

Openlayers-Mapserver-PostGIS rendition of the Ontario Historical County Map Project
Openlayers-Mapserver-PostGIS, rendu du Ontario Historical County Map Project

Pendant de nombreuses années, j’ai ignoré ArcGIS Online que je considérais comme un projet très lourd d’Esri pour des projets moins ambitieux. Je me demandais comment on pouvait construire un outil en ligne avec des fonctionnalités SIG et amener les gens à s’y intégrer. Cependant, sa popularité a grandi tellement parmi nos utilisateurs de l’Université de Toronto que j’ai finalement eu besoin d’apprendre à l’utiliser pour pouvoir offrir du support technique. Quelle meilleure façon de m’enseigner comment utiliser ArcGIS Online que d’y verser les données du projet County Map Project? À ma grande surprise, ArcGIS Online n’était pas seulement amusant et plein de fonctionnalités en SIG et cartographie Web, il a également implanté l’application Web AppBuilder. Outre des dizaines de modèles StoryMaps, Web AppBuilder vous permet de rendre vos données SIG dans une interface Web où vous pouvez ajouter des widgets personnalisables qui fonctionnent très bien, même dans les navigateurs mobiles. Être capable d’interroger ou filtrer les 80 000 noms de notre base de données a été un critère clé pour l’adoption de toute technologie Web pour le projet. ArcGIS Online répond à ce critère fondamental, et a également permis le rendu d’images de haute résolution des cartes de comté numérisées. La facilité d’utilisation et la personnalisation des applications Web sans programmation sont également de bons points de vente. D’autres widgets amusants et utiles incluent l’utilisation de lignes de temps animées des données et d’un outil de navigation qui permet de visualiser deux ensembles de données l’une par-dessus l’autre et de glisser une barre d’outils pour basculer entre les affichages.

ArcGIS Online version of the Ontario Historical County Map Project with Querying tool display
Version ArcGIS Online du Ontario Historical County Map Project avec l’affichage de l’outil de recherche

Adopter ArcGIS Online en tant qu’outil de cartographie Web a permis au projet d’être présenté au public où les utilisateurs peuvent effectivement profiter des données construites au cours des 15 dernières années. Je n’ai jamais pensé que nous aurions une solution de cartographie Web avant de terminer la base de données, mais dans l’ensemble, je suis très content de la plupart des fonctionnalités de l’application Web à ce stade, car notre base de données continue de croître et nous continuons à compiler plus de noms de propriétaires fonciers à partir des cartes de comté historiques. Fait intéressant, pendant l’écriture de ce billet, j’ai reçu trois messages sur le projet et des demandes d’informations supplémentaires auprès des utilisateurs du site de County Maps. Sans mettre nos données à disposition de cette manière, je doute que notre projet ait attiré tant d’attention.

Inspiré par notre succès avec l’outil de création d’applications Web, j’ai décidé de créer une application pour le DVHMP et j’ai constaté que les données que nous avions construites il y a plus de sept ans ont vraiment pris vie sur le Web. Être capable d’interroger les données et de rendre les données de polygone et de point ensemble dans une vue sur le Web est motivant.

ArcGIS online n’est évidemment pas le seul outil qui a profité de la cartographie web et des avancées de l’informatique « en nuage » pour permettre aux utilisateurs de créer leurs propres applications de cartographie web. Les produits tels que Mapbox augmentent également en popularité en raison de leur facilité d’utilisation, de leurs fonctionnalités puissantes et personnalisables ainsi que de l’attrait du produit cartographique final.

La cartographie Web existe depuis les années 1990, mais avec de nouvelles technologies avancées de cartographie Web comme ArcGIS online et Mapbox, il est peut-être temps pour de nombreux autres ensembles de données SIGH inactifs ou longtemps oubliés d’être retirés des disques durs et des clés USB et leur redonner une nouvelle vie en les affichant dans des cartes Web créées facilement. Je suis ravi de penser à voir éventuellement les données de Montréal Avenir du Passé, par exemple, rendues disponibles en les affichant sur une carte Web pour que tout le monde puisse interagir avec elles.

Le Partenariat canadien SIGH étudie de nombreux outils de cartographie Web et des méthodes de visualisation. Nous travaillons également avec Esri Canada, dans le cadre du projet GeoHist, pour fournir des exigences SIGH spécifiques aux outils de cartographie en ligne. Avec les composants puissants déjà disponibles dans ArcGIS online, Mapbox et d’autres outils de cartographie web, l’avenir de la cartographie web pour les SIGH est très intéressant et accessible à toute personne intéressée à les développer sans avoir à coder.

Références :

Gregory, Ian., et Paul S. Ell. Historical GIS: Technologies, Methodologies, and Scholarship. New York: Cambridge University Press, 2007.

Comment retrouver et relier toute cette information géohistorique?

Outils SIGH en ligne, Projets SIGH

Le volume de données géohistoriques disponible sur le web et entreposé dans différentes bases de données augmente rapidement alors que le tournant géospatial prend de l’ampleur et que les outils de cartographie en ligne devienne plus accessibles. Les cartes historiques peuvent être localisées avec un bounding box ou géoréférencées avec précision. Les photographies aériennes sont assemblées et géoréférencées pour permettre l’analyse d’une région ou la localisation d’une planche particulière. Les cartes statiques, interactives ou animées sont de plus en plus utilisées pour visualiser des phénomènes qui ont eu un impact sur l’histoire à différentes échelles : locale (Don Valley Historical Mapping Project), régionale (Carte de l’impact de la peste noire sur l’Angleterre médiévale), nationale (American Panorama. An Atlas of United States History), continentale (Mapping the Republic of Letters), trans-atlantique (The Trans-Atlantic Slave Trade Database) ou mondiale (Time-Lapse Map of Every Nuclear Explosion, 1945-1998).

Face à ces masses de données, les chercheurs ne tente pas seulement de trouver une aiguille dans une botte de foin. Ils doivent retrouver plusieurs aiguilles réparties à travers plusieurs bottes de foin. Plusieurs initiatives ont été lancées, incluant par cette équipe, pour développer des solutions qui amélioreraient l’accessibilité aux données géohistoriques. Les portails sont généralement perçus comme une solution qui permet de rassembler les données relatives à un lieu ou aux intérêts d’un groupe ou d’une institution. Consciemment ou non, ces portails sont aussi conçus pour mettre en valeur le travail d’une groupe ou d’une institution. Nous aurons besoin de portails comme infrastructure permettant d’héberger et de distribuer les données géospatiales. Mais ils ne peuvent pas, seuls, résoudre les problèmes de découverte de données, d’ouverture et d’interopérabilité.

Selon les compétences des développeurs en optimisation du portail pour les moteurs de recherche, un portail sera plus ou moins facile à retrouver sur le web. L’usager aboutira généralement sur la page d’accueil du portail de devra ensuite utiliser les outils spécifiques au portail pour retrouver le ou les items pertinents pour sa recherche. Certains systèmes, tels que GeoIndex+, associent la recherche par facettes à une vue cartographique pour faciliter la découverte de données. D’autres s’en remettent encore à des outils de recherche découlant d’anciens catalogues.

Que les données souhaitées puissent être retracées ou non, elles ne seront peut-être pas disponible pour le téléchargement. Hormis les enjeux de licences commerciales, plusieurs chercheurs sont encore réticents à rendre leurs données disponibles pour téléchargement, un enjeu pour un autre billet. Les différents paliers de gouvernement rendent graduellement leurs données disponibles gratuitement, mais il est encore possible qu’un chercheur finisse par numériser et géoréférencer des données qui existent déjà en ce format. L’utilisation d’un format de fichier incompatible avec le logiciel préféré du chercheur devient alors un inconvénient mineur.

Même lorsque les développeurs d’un portail ont les meilleurs intentions pour rendre les données disponibles et téléchargeables, le manque d’interopérabilité des systèmes rend les recherches trans-portail difficiles à moins d’ouvrir des API ou de rendre les données disponibles dans un format ouvert et lié. Bien que les API pourraient résoudre les problèmes immédiats, il resterait à résoudre des problèmes à plus long terme de sécurité, d’entretien et de renouvellement des systèmes. Je mettrai donc l’accent sur les données ouvertes et liées en tant que solution à long terme pour ce problème.

Les données liées, ou le web des données « est une initiative du W3C (Consortium World Wide Web) visant à favoriser la publication de données structurées sur le Web, non pas sous la forme de silos de données isolés les uns des autres, mais en les reliant entre elles pour constituer un réseau global d’informations. Il s’appuie sur les standards du Web, tels que HTTP et URI – mais plutôt qu’utiliser ces standards uniquement pour faciliter la navigation par les êtres humains, le Web des données les étend pour partager l’information également entre machines. Cela permet d’interroger automatiquement les données, quels que soient leurs lieux de stockage, et sans avoir à les dupliquer. » [Source] Ce standard du W3C est à la base du web sémantique tel que défini par Tim Berners-Lee.

Les données liées reposent sur le Resource Description Framework (RDF), lequel utilise une grammaire sujet → prédicat → objet pour définir des déclarations à propos des ressources. Ces triplets, qui peuvent aussi être conçus comme des structure entité → attribut → valeur (le document X → est une → carte) peuvent être lus par les machines et utilisent des Uniform Resource Identifiers (URIs) pour relier les différents éléments. Les données liées sont déjà utilisées pour rendre l’information disponible et connectée dans des projets tels que DBpedia.

Les structures de données présentées en tant que déclarations rdf sont définies par des ontologies. Le Spatial Data on the Web Working Group a été mis sur pied par le W3C afin de

  • to determine how spatial information can best be integrated with other data on the Web;
  • to determine how machines and people can discover that different facts in different datasets relate to the same place, especially when ‘place’ is expressed in different ways and at different levels of granularity;
  • to identify and assess existing methods and tools and then create a set of best practices for their use;
    where desirable, to complete the standardization of informal technologies already in widespread use.
    [SDWWG Mission Statement]

Une telle initiative offrira les outils et l’infrastructure à partir de laquelle nous pourront rendre les données géohistoriques découvrables et accessibles.

Malheureusement, les données liées et ouvertes ne sont pas simple à mettre sur pied. Des ontologies concurrentes pourraient émerger, ce qui limiterait l’interopérabilité à moins de définir des équivalences. Certaines institutions insisteront pour définir leurs propres URIs, pour les toponymes par exemple, sans les reliées à d’autres listes d’autorité, recréant ainsi les silos que nous souhaitons éviter. Plusieurs parties prenantes devront ouvrir et offrir leurs données de recherche en triplets rdf pour que le web de données géohistoriques puisse émerger, comme c’est déjà le cas avec DBpedia, Geonames et le World Factbook. Conçu comme une infrastructure, les données ouvertes et liées n’ont pas un très grand effet « wow » qui apporterait de la visibilité et des investissements. Un projet pilote avec une vitrine sophistiquée sera nécessaire pour que les gens comprennent le potentiel des données ouvertes et liées et investissent les ressources nécessaires pour publier les données géohistoriques en triplets rdf.

Certains enjeux devront être résolus, dont l’approbation d’une ontologie standard ou d’un ensemble d’ontologies compatibles. Le SDWWG met de l’avant la compatibilité avec les ontologies supérieures plutôt que la dépendance sur une approche particulière des données liées. [SDWWG Best Practices Statement]. Nous devons aussi nous attendre à ce que différentes équipes publient leurs données à divers niveaux de granularité. Certains fourniront au minimum les métadonnées qui permettront d’indiquer qu’un jeu de données comprend de l’information sociale et économique à propos de Montréal en 1825 alors qu’un autre pourrait publier chaque donnée individuelle des maisonnées. Si on se penche sur les enjeux de la carrière des chercheurs, comment ce type de publication sera-t-il reconnu pour l’embauche, la promotion ou l’obtention de subventions? Le Collaborative for Historical Information and Analysis  a étudié les pratiques des dépôts de données qui pourraient être utiles alors que nous avançons vers les données ouvertes et liées. Enfin, comment signalerons-nous des données qui sont peu recommandables pour la recherche académique? Nous aurons à définir un mécanisme d’évaluation par les pairs pour un monde de données ouvertes et liées.

En ce moment, les questions sont plus nombreuses que les réponses, mais les données ouvertes et liées offrent une solution à long terme pour la découverte et l’accès. Une telle solution devrait être intégrée dans la conception de portails à l’avenir.

Pour aller plus loin, le SDWWG énumère quelques publications et présentations sur le sujet. L’ouvrage de Catherine Dolbear et Glen Hart, Linked Data: A Geographic Perspective (CRC Press, 2013) offre aussi une approche pour l’utilisation des données liées dans une perspective géographique. Toute recherche sur les données liées ou le web sémantique donnera aussi plusieurs résultats de lectures utiles pour se lancer dans l’aventure. Pour les historiens, le mémoire de maîtrise de Philippe Michon, « Vers une nouvelle architecture de l’information historique : L’impact du Web sémantique sur l’organisation du Répertoire du patrimoine culturel du Québec », est fortement recommandé.

Léon Robichaud
Professeur agrégé
Département d’histoire
Université de Sherbrooke