Je me suis longuement demandé ce qu’on pouvait faire d’intelligent avec un téléphone portable, autre que de casser des briques/bulles/billes, d’échanger des messages stériles en moins de 200 caractères ou de faire défiler des images en moins de temps que le cerveau n’en a besoin pour les visualiser. Qu’est-ce qui justifie un calculateur puissant, autonome et fonctionnant sur batterie, idéalement géolocalisé en recevant les signaux de satellites équipés d’horloges atomiques (GPS/Galileo/GLONASS/Beidou), et capable d’accéder à une base de données ? Finalement au cours des missions de terrain, la révélation se trouva dans QField, l’outil embarqué pour téléphone portable et tablette sous Android, permettant de visualiser un projet QGIS afin d’emporter partout sa base de données géoréférencées et de la mettre à jour avec les nouvelles observations.
1. Introduction
Quantum GIS – QGIS [1] – est un outil de gestion d’informations spatialisées (Geographic Information System) dans lequel nous fusionnons cartes et informations contenant une notion de position (grandeurs scalaires telles que l’épaisseur de glace ou du manteau neigeux, ou matricielles telles qu’une photographie [2] ou une carte de réflectivité RADAR) en vue d’un traitement ultérieur. QGIS fonctionne fort bien sur ordinateur portable, qu’il n’est pas toujours très pratique de sortir sur le terrain. Vient donc QField (https://github.com/opengisch/QField), un outil sous Android permettant d’importer et d’éditer un projet QGIS sur son téléphone mobile. Nous allons nous intéresser à deux problématiques : accéder aux données d’un projet QGIS depuis son téléphone mobile, et diffuser ces informations sur une interface web pour des interlocuteurs qui ne posséderaient pas QGIS – fonction fournie par le greffon qgis2web. Cette approche se distinguera quelque peu de celle que nous avions promue auparavant avec le stockage de données sur serveur WMTS [3] : ici, les utilisateurs n’auront pas vocation à accéder aux données brutes pour éventuellement les modifier et les exploiter sur leur propre système de gestion d’informations géographiques, mais uniquement les visualiser. Ainsi, même un destinataire qui n’est pas équipé de QGIS (ou équivalent propriétaire) pourra visualiser les cartes superposées des données acquises sur le terrain. Exporter un projet QGIS statique vers un site web est relativement trivial et ne mériterait pas cette discussion. Notre objectif est de rendre le site interactif en permettant à l’utilisateur d’accéder à des données géoréférencées – dans notre cas, des photographies numériques – lorsque la souris survole le site de l’acquisition.
Toutes les expériences proposées dans cet article sont basées sur des données acquises avec un Sony Xperia Z5 Compact, un téléphone approprié pour une utilisation en extérieur par son indice de protection IP68 qui lui permet de résister à la pluie ou de tomber dans l’eau ou dans la neige, voire de s’arrêter juste à temps alors qu’il glisse vers une crevasse (ne jamais laisser tomber son téléphone à proximité des crevasses, qui par définition sont toujours dans une zone de pente importante d’un glacier). Les versions de QGIS considérées iront de 3.6.3-Noosa à 3.16.10-Hannover, bien que nous mentionnerons la version QGIS2 encore active dans Debian/oldstable, et la version de qgis2web sera 3.16.0 tandis que QField sera en version 2.0.5. OSMTracker n’a que peu évolué et nous ne voyons pas de différence entre les versions 0.6 utilisées et l’actuelle 1.x.
2. Acquisition de données géoréférencées et dissémination sur le Web
Nos acquisitions de traces, voire éventuellement de photographies numériques, se font par OSMTracker (https://wiki.openstreetmap.org/wiki/FR:OSMTracker_(Android)), disponible par F-Droid, exécuté sur téléphone portable. Ce logiciel non seulement acquiert la trace GPS du parcours, mais aussi des points remarquables tels que photographies ou notes prises le long du parcours.
2.1 QGIS 2 et 3.10
Avant la version 3.14 de QGIS, l’insertion de ces traces et points géoréférencés se fait au moyen du greffon GPS Tools qui permet la lecture de fichiers au format GPX, format XML standardisé dans lequel OSMTracker exporte ses données. Nous sélectionnons comme fond de carte la base de données OpenStreetMap qui est accessible depuis QGIS 3 dans la liste des couches sous « XYZ Tiles ». Alternativement, bien que cela rompe probablement l’accord d’utilisation des fonds de carte de Google, nous pouvons introduire ces dernières en ajoutant sous « XYZ Tiles » l’URL http://mt0.google.com/vt/lyrs=s&hl=en&x={x}&y={y}&z={z}. Si le récepteur GPS utilisé n’exporte pas au format XML, mais uniquement des trames NMEA comme ce fut le cas de nombre de récepteurs embarqués – par exemple ceux de u-blox supportent ce standard nativement – alors GPSBabel se chargera de la conversion de NMEA vers GPX.
2.2 QGIS 3.16
La version SID de Debian propose actuellement QGIS 3.16, et les progrès face à 3.10 sont significatifs. En effet, l’ajout de couches vectorielles (Layer -> Add Layer -> Add Vector Layer...) reconnaît désormais le format GPX et ne nécessite plus de passer par le greffon GPS Tools.
Dans tous les cas, nous commençons par assembler un projet QGIS contenant toutes les informations à partager, par exemple dans le cas de la Fig. 1 en incluant les traces sur le fond de carte, ainsi qu’une photographie de plan touristique déformée par la fonction Georeferencer permettant d’ajuster l’image à la carte sous-jacente, fonction disponible sous le menu Raster – après installation du greffon externe dans QGIS 3.10. Une fois la carte et ses informations additionnelles complétées, le greffon qgis2web (https://github.com/tomchadwin/qgis2web) permet, depuis le menu Web de QGIS, de trivialement générer une page web diffusable. Pour produire la Fig. 1 accessible à http://jmfriedt.org/qgis2web_2021_12_05-16_11_59_796508/ qui reprend le trajet parcouru pour les mesures décrites dans [4], nous avons activé Appearance -> Add layers list -> Expanded qui permet à l’utilisateur d’activer ou de désactiver certaines couches, à l’exception du fond de carte. L’utilisation des infrastructures OpenLayers ou Leaflet propose un rendu sensiblement identique : qgis2web se charge de générer les requêtes QGIS dans ces infrastructures de présentation de données géoréférencées sur une page web, incluant l’activation ou la désactivation dynamique de couches ou la mesure de distances et de surfaces sur la carte.
Attention : la présence d’une ou plusieurs couches non initialisées se traduit par un message d’erreur quelque peu cryptique « AttributeError: NoneType object has no attribute Type ». Ce message traduit le fait que qgis2web ne sait pas gérer des couches non initialisées, que ce soient des couches virtuelles issues d’un calcul antérieur au chargement du projet qui n’avaient pas été sauvegardées ou le chargement d’un projet avec des couches inexistantes, mais que nous avons forcé à ouvrir par Keep unavailable layers.
Si certaines traces ne s’affichent pas en téléchargeant le projet vers le serveur web disséminant les informations, on prendra soin de vérifier dans les propriétés du projet (Project -> Properties) que les chemins vers les fichiers sont relatifs et non absolus (Save paths: Relative).
Attention : lors de l’analyse quantitative de données issues du GPS, notamment la longueur de la trace ou la surface du polygone détouré par une trace, on pensera à passer dans un mode projeté cartésien (geodesie.ign.fr/index.php?page=srt) pour représenter les données (UTM, Lambert) et ne pas tenter le calcul dans une projection sphérique (WGS84) qui donne un résultat erroné, ou tout au moins dont les unités ne sont pas des mètres tels que décrits à osgeo-org.1560.x6.nabble.com/Can-we-make-QGIS-stop-lying-td5321803.html.
3. Insertion de photographies géoréférencées
Nous avons pu insérer des traces de nos déplacements sur un fond de carte disséminé sur le Web, mais nous désirons compléter ces informations scalaires avec les données collectées sur le terrain, qu’il s’agisse de photographies ou de mesures acquises sur les divers sites remarquables, dans notre cas hauteur de neige et de glace au niveau de balises d’ablation sur un glacier. Afin de ne pas surcharger la carte de toutes ces informations, nous désirons que lorsque la souris passe sur un point d’intérêt associé à une photographie, celle-ci s’affiche. L’intérêt de cette approche est de placer les photographies dans leur contexte géographique, tel que nous l’illustrons par exemple à http://jmfriedt.free.fr/qgis2web_2018_01_06-18_53_48_709753/#9/38.3438/140.9821 qui avait été produit avec QGIS2 et que nous régénérons avec la version courante de QGIS 3.16 à http://jmfriedt.org/qgis2web_2021_12_21-09_52_23_718022/#9/38.3438/140.9821 pour un rendu un peu plus élégant, le premier exemple permettant par ailleurs d’illustrer qu’aucune fonctionnalité d’Apache n’est nécessaire, puisque ce site est hébergé sur le site de free.fr. Ces données ont été acquises au cours d’une visite des sites dévastés par le tsunami autour de Sendai (Japon) dans la bande d’une quinzaine de kilomètres entre le front de mer et les premières élévations (Fig. 2), zone densément peuplée – 20000 morts sont répertoriés – sans point surélevé pour se protéger de la montée du niveau de la mer. La construction actuelle de quelques points surélevés tels des miradors vise à protéger la population en fournissant une protection locale... jusqu’à ce que le risque de tsunami soit oublié et que la pression urbaine induise à détruire ces points surélevés artificiels. Ces cartes exportées en 2017 ont été réalisées au moyen de QGIS 2.0, mais le résultat et les techniques restent sensiblement identiques jusqu’à QGIS 3.14, justifiant une description séparée pour QGIS 3.16 actuel.
3.1 QGIS 2 et 3.10
Un greffon de QGIS, ImportPhotos, est spécifiquement conçu pour charger toutes les photographies contenant une information de localisation sous forme de champs GPS dans l’entête EXIF. Cependant, il se peut que des photographies ne comportent pas d’information de géoréférencement – aussi surprenant que cela paraisse, l’entête EXIF des photographies prises par le téléphone ne contient pas d’information de position, tel qu’en atteste exiftool *.jpg | grep GPS. Alternativement, le photographe expert qui ne peut se contenter de la qualité médiocre des prises de vues par téléphone portable désire utiliser son appareil reflex numérique muni d’une optique d’excellente qualité, mais sans capacité de géoréférencement : dans tous les cas, nous devrons coordonner les informations d’horaire de prises de vues et de géoréférencement sur la trace acquise lors du déplacement. Étant donné que le téléphone portable sert à la fois à l’acquisition des traces GPS et des prises de vues, et que l’horloge du téléphone est cadencée sur l’information venant de GPS, nous pouvons retrouver dans la trace la position de la prise de vue. Alternativement, prendre en photo l’écran du téléphone pendant qu’il affiche une application du type SatStat sous Android (avec l’heure GPS à la seconde près) permet de mesurer l’écart entre l’horloge de l’appareil photo et du téléphone qui a acquis la trace GPS. La synchronisation entre la trace et les photographies est prise en charge par exiftool avec son option -geotag décrite à https://sno.phy.queensu.ca/~phil/exiftool/geotag.html. Pour ce faire, exiftool -geotag="fichier.gpx" . ajoute les informations de position de toutes les images dans le répertoire courant (.) en associant position et date de prise de vue indiquée dans la trace au format GPX fichier.gpx en tenant compte d’un écart supposé fixe entre l’horloge de l’appareil photo et du récepteur GPS par l’option -geosync= si nécessaire.
En résumé, nous exécutons dans chaque répertoire contenant les photographies horodatées la commande exiftool -geotag=*.gpx . qui fait appel au fichier GPX issu de OSMTracker, puis sous QGIS au moyen de ImportPhotos chargeons chaque photographie. Finalement, toutes ces couches individuelles peuvent être fusionnées en une unique couche par Vector -> Data Management Tools -> Merge Vector Layers. Nous constatons dans la table attributaire de la couche nouvellement créée les champs RelPath contenant le nom du répertoire et de la photographie par rapport au répertoire du projet QGIS, ainsi que le champ Images qui contient déjà l’instruction HTML sous forme de balise img src prête à être incluse dans une page web qui s’ouvre lors du survol du point par la souris. Au pire, si les coordonnées des photos n’ont été que manuellement notées et ne sont pas accessibles dans un fichier GPX, la position de chaque photographie peut être renseignée par :
Nous avons par ailleurs pris l’habitude de réduire la taille des images, souvent excessivement volumineuses pour une dissémination fluide sur le Web, par un script d’une ligne de la forme for i in *.jpg; do convert $i -scale 50\% tmp.jpg;mv tmp.jpg $i;done en supposant ImageMagick installé.
Afin de faciliter la prévisualisation dans QGIS, voire de fournir déjà dans cet outil un certain confort d’accès aux photographies, nous activons leur affichage grâce à la « bulle » Show Map Tips (avant-dernière icône de l’Attribute Toolbar).
L’activation de l’affichage de la photographie en survolant le point d’intérêt sous QGIS s’active en ouvrant les propriétés de la couche contenant les points d’intérêt (bouton de droite dans la liste des couches et Properties... et en recherchant la bulle de bande dessinée jaune (12e icône dans le menu des propriétés). Dans ce menu, nous activons sous HTML Map Tips l’ouverture de la photographie en ajoutant les instructions Python (cliquer sur ε sur le menu du bas) concat('<img src=file://',@project_home,'/gps/',RelPath,' width=320>') et Insert (à droite du ε). QGIS sait qu’il doit évaluer cette expression Python en l’encadrant de [% ... %], et nous avons inséré le sous-répertoire gps pour indiquer que nos traces OSMTracker se trouvent dans ce sous-répertoire par rapport au projet QGIS dans notre arborescence (Fig. 3), que le lecteur adaptera évidemment à son environnement de travail. Lors de la rédaction de l’expression, le résultat de l’évaluation s’affiche en bas de la fenêtre et on vérifiera la cohérence de l’emplacement avec son arborescence, source la plus commune d’erreurs. Les versions successives de QGIS ont fait évoluer les dépendances – la référence explicite à la nature de l’URL en file:// ou http:// n’a été ajoutée que tardivement, 3.8 pour file:// – et il faudra parfois tâtonner un peu pour trouver la bonne combinaison selon sa version de QGIS.
On notera que cette méthode ne se limite pas à des photographies, mais permet aussi d’ouvrir des fichiers contenant des mesures afin d’y accéder lorsque le point d’intérêt est survolé par la souris. À titre d’exemple, supposons qu’un fichier CSV contient la liste des positions des points remarquables, et pour chaque point le nom d’un fichier de mesures, de la forme :
Avec les coordonnées X et Y la longitude et latitude respectivement, ici en coordonnées sphériques WGS84 à proximité de Besançon. Chaque fichier de mesure contient les grandeurs acquises respectivement sur chaque site, dans notre exemple le fichier mesure1.txt contient ceci est une première mesure et le fichier mesure2.txt contient ceci est une deuxième mesure respectivement. Afin d’afficher le contenu de chaque fichier, l’instruction HTML déclenchée par le survol du point par la souris est, dans le menu de la bulle, [% concat('<iframe src="file://',@project_home,'/',filename,'"></iframe>') %] qui crée une page web dont le contenu est extrait de filename, dernier attribut du fichier associant position et mesures, dans le répertoire contenant le projet QGIS (variable d’environnement @project_home), en indiquant que l’expression Python n’est pas statique, mais doit être évaluée en l’encadrant entre [% ... %]. Le résultat est visible en Fig. 4.
3.2 QGIS 3.16
La situation est bien plus simple avec les nouvelles moutures de QGIS qui ne nécessitent plus un greffon externe. Le fichier GPX importé par le gestionnaire de couches vectorielles de QGIS 3.16 contient l’information des points remarquables (waypoints) associant nom de photographie et position de prise de vue dans le champ link1_href visible dans la table attributaire. Ainsi, il n’est pas nécessaire de passer par ImportPhotos pour inclure des photographies prises depuis l’application OSMTracker dans la carte. Néanmoins, la technique précédente de synchronisation et d’ajout de l’entête de position reste valable si les photographies sont prises avec un appareil photo autre que le téléphone.
Néanmoins, une fois le traitement de géoréférencement des images finalisé et l’entête EXIF de chaque photographie complété de sa position GPS, il devient aisé de rechercher le contenu de ce répertoire par la boîte à outils (Toolbox) nommée Import geotagged photos. Ce principe est illustré en Fig. 5 qui démontre l’intérêt de comparer deux photographies prises à 4 ans d’intervalle – septembre 2015 et septembre 2019 – depuis le même point, mais avec un glacier qui a perdu 6 mètres d’épaisseur de glace, libérant de la moraine cachée depuis au moins le petit âge glaciaire du Moyen-Âge sous le glacier, et déstabilisant les blocs de glace cachés sous les sédiments [5], induisant des écoulements de débris morainiques et d’alluvions vers le fjord. Noter que le retrait du glacier, l’aspect le plus visuel de sa fonte, n’est que la conséquence au travers de l’angle de sa langue de l’ablation suite aux absences répétées d’accumulation qui compenserait la fonte et des bilans de masse négatifs qui s’en suivent. Avec un angle de la langue de 10 à 15° d’après le modèle numérique de terrain (fonction Slope de GDAL dans la série de Toolbox de QGIS), une ablation de 6 m se traduit par un recul de 25 à 35 m, en accord avec les mesures sur le terrain et les images optiques satellitaires. La zone du cañon visible au premier plan était sous le glacier il y a moins de 15 ans lorsque cette étude a débuté.
4. Exporter un projet sur le Web : qgis2web
Nous avions déjà décrit dans ces pages comment configurer un serveur QGIS [3] par qgis-server pour donner accès au travers de services WMS (Web Map Service)/WMTS (Web Map Tile Service)/WFS (Web Feature Service) aux données géoréférencées que nous avions acquises ou traitées. Les interlocuteurs se limitent dans ce cas aux autres utilisateurs de QGIS (ou sa version propriétaire ArcGIS) et excluent les simples butineurs du web sans compétence en gestion d’informations géographiques. L’approche est donc ici un peu différente, car nous proposons de générer une page web statique représentant les données géoréférencées sans s’appuyer sur un serveur WMTS, mais sans prétendre donner accès aux informations autrement que par leur représentation graphique.
4.1 QGIS 2
L’insertion d’images qui s’affichent lors du survol des points remarquables est décrite à https://gis.stackexchange.com/questions/154608/popup-with-images-with-qgis2web : cette ancienne version de qgis2web attend un champ attributaire nommé html_exp qui contient la commande HTML à exécuter lors du survol du point. On observe une arborescence limpide des sous-répertoires du projet qgis2web généré, avec un sous-répertoire images qui pourra accueillir les illustrations à afficher sur le fond de carte. Pour ce faire (Fig. 6), il faudra remplacer les répertoires absolus par une arborescence relative et copier les photographies à afficher dans le sous-répertoire approprié. Ceci pourra se faire en important la couche contenant les photographies au format CSV (ASCII éditable) et en créant une nouvelle colonne de la table attributaire nommée html_exp, de format String de 200 caractères de long, et rempli par concat('<img src="images/'+name+'" width="400">'). Finalement, nous devrons manuellement peupler le contenu de images/ sur le serveur web avec les illustrations qui ne sont pas placées par défaut dans ce répertoire au moment de sa création sur l’ordinateur local.
Le résultat de ce traitement est visible en Fig. 2 dans lequel on pensera à activer l’option Show popups on hover de qgis2web pour que les photographies s’affichent dynamiquement sur la page web lors du survol du point d’intérêt par la souris (menu surligné sur la capture d’écran du milieu).
Dans cette ancienne version de qgis2web, les images s’affichaient par ailleurs en pleine résolution. https://gis.stackexchange.com/questions/296778/restricting-photo-size-for-attributes-displayed-in-qgis2web explique comment ajuster la largeur des images bien trop grandes pour être élégamment affichées sur le fond de carte de l’interface web en réduisant leur largeur. Pour ce faire, il faut éditer la charte graphique CSS dans ./resources/qgis2web.css en ajoutant #popup-content img {max-width: 200px;} pour imposer la largeur de l’image affichée. L’utilisateur aura toujours loisir de télécharger explicitement l’image en pleine résolution s’il le désire pour la traiter localement.
4.2 QGIS 3.16
La situation a considérablement évolué entre QGIS2 et les premières versions de QGIS3 et la version actuelle. Nous profitons désormais des attributs très riches d’un point remarquable que sont Attributes Form, 9e icône à partir du haut dans la liste des propriétés de la couche contenant les photographies. Désormais, qgis2web est informé de la présence des images à afficher en cliquant sur le nom du champ contenant le nom de la photographie – dans notre cas link1_href, et en précisant que Widget Type est Attachement. Ainsi, un fichier externe sera chargé, et nous précisons qu’il s’agit d’une photographie en descendant dans le menu Widget Type jusqu’à atteindre Integrated Document Viewer et en activant Type : Image. L’opération est peu intuitive sur l’écran 10" d’un ordinateur portable CF-19, mais se déroule mieux sur un écran plus grand, même si moins approprié pour être emporté sur le terrain.
Cette fois encore, l’affichage dynamique des images lors du survol du point remarquable par la souris s’active dans qgis2web par Appearance -> Highlight on hover et Show popups on hover (Fig. 7) avec le site original disponible à http://jmfriedt.org/qgis2web_2020_09_30-17_55_34_645120/#11/78.8764/12.1476 sur lequel on cliquera sur les points pour afficher les images, au lieu d’attendre leur ouverture automatique en le survolant. Le résultat est agréable à visualiser et parfaitement fonctionnel (Fig. 8) tel que le lecteur pourra s’en convaincre en visitant http://jmfriedt.org/qgis2web_2021_09_27-23_37_20_573888/. Le premier jeu de données a été acquis au cours de la campagne de mesures au Spitzberg en septembre 2020, le second en septembre 2021, démontrant la pérennité de la méthode de travail malgré les évolutions de QGIS et de ses dépendances, que l’on pourra compléter avec le résultat de la mission de 2019 à http://jmfriedt.free.fr/qgis2web_2019_10_06-09_53_58_705235/#11/78.8764/12.1476 qui illustre l’utilisation d’un modèle numérique de terrain, au lieu d’images aériennes comme fond de carte.
Pour conclure cette présentation de qgis2web, il peut être quelque peu fastidieux de transférer tous les sous-répertoires produits par qgis2web vers son hébergeur : nous utilisons pour cela une commande du type lftp -e "mirror -R . /qgis2web_date" -u jmfriedt,XXXXXXXX ftpperso.free.fr pour exporter le site web produit localement (.) vers qgis2web_date, ici de l’hébergeur free.fr et son service FTP de mise à jour du contenu. Les utilisateurs d’outils graphiques pourront par ailleurs bénéficier des fonctionnalités de FileZilla qui permettent aussi de transférer les sous-répertoires d’un projet vers un serveur FTP.
5. Exploitation de QField
La page web permet de disséminer les informations aux utilisateurs non avertis de la puissance d’un outil de gestion d’informations spatialisées, mais ne nous aide pas pour emporter le projet sur le terrain pour le consulter sur site ou le modifier en fonction des observations. Certes, nombre d’utilisateurs ont désormais une connexion internet permanente et pourraient se contenter d’accéder à la page web, mais cette fonctionnalité n’est par exemple pas disponible autour de Ny-Ålesund au Spitzberg, zone de silence radio pour le bon fonctionnement des radiotélescopes et récepteurs satellites proches du site de nos activités de recherche. Exploiter un projet QGIS sur une plateforme portable autonome est possible grâce à QField (Fig. 9) qui ne nécessite aucune manipulation du projet QGIS autre que de transférer le projet qgs ou maintenant en format compressé qgz et ses sous-répertoires vers la plateforme mobile, en ayant pris soin de configurer l’arborescence relative à l’emplacement du projet QGIS et non absolue (Project -> Properties -> Save Paths: relative).
Prenons un exemple concret d’utilisation d’informations géoréférencées sur le terrain : nous désirons, saison après saison, prendre des clichés depuis les mêmes points de prise de vue pour observer les évolutions géomorphologiques [6, 7, 8, 9]. Pour ce faire, nous pouvons nous déplacer avec la base de données des photographies sur le téléphone portable, retrouver les points de prise de vue et ainsi enrichir la collecte d’informations. Nous désirons importer le projet QGIS contenant nos traces, fonds de carte et points significatifs dans le téléphone portable que nous emmènerons sur le terrain pour reproduire les mesures. QField répond à ce besoin : il s’installe sur plateforme mobile exécutant le système Android, et ce, sans devoir ouvrir de compte chez Google puisque l’archive APK est disponible (https://github.com/opengisch/QField/releases). Nos études ont évolué au cours des générations de QField pour finalement finir à la date de rédaction de cet article sur 1.0.4 Matterhorn.
Une fois sur le terrain, rien ne ressemble plus à un piquet sortant de la glace dans le brouillard qu’un autre piquet une centaine de mètres plus loin. Ici encore, QField avec son positionnement en temps réel de l’utilisateur s’avère inestimable (Fig. 10).
Même en milieu urbain, QField peut s’avérer fort pratique pour (re)trouver son chemin, ici sur un fond de carte OpenStreeMaps en superposant un trajet (Fig. 11). La carte originale de cette capture d’écran se trouve à http://jmfriedt.free.fr/qgis2web_2019_06_09-09_28_45_379036.
Conclusion
Nous nous sommes efforcés d’illustrer la dissémination d’informations géoréférencées scalaires ou matricielles au travers de pages web facilement accessibles par tout utilisateur, même sans compétence de gestion d’informations spatialisées. Pour ce faire, le greffon qgis2web de QGIS s’est chargé de produire l’arborescence des pages web exploitant Leaflet ou OpenLayers pour l’affichage de fonds de cartes et les informations que nous désirons attribuer à chaque point remarquable. Diverses illustrations visent à proposer des contextes d’utilisation en milieu naturel ou urbain, pour partager les informations ou les exploiter sur site.
Nous avons commencé cette prose en questionnant l’utilité d’un téléphone portable, en particulier pour les interactions sociales superficielles, pour identifier la capacité de gestion d’informations spatialisées comme justifiant les périphériques de prise de vue ou de localisation. Ces divers aspects du téléphone portable ne sont finalement pas indissociés, tel qu’en atteste le numéro spécial de Proc. IEEE intitulé « Spatial Technology and Social Media » pour leur édition d’octobre 2017 (volume 105, numéro 10).
Remerciements
Les voyages au Spitzberg ont été financés par la Région Franche-Comté, l’Institut polaire Paul-Émile Victor (IPEV) et l’Agence Nationale de la Recherche (ANR). Le séjour à Sendai a été financé par une position de chercheur invité par l’Université de Tohoku au Japon.
Références
[1] A. Cutts & A. Graser, Learn QGIS: Your Step-by-step Guide to the Fundamental of QGIS #3.4, 4th Ed. Packt (2018).
[2] J.-M. Friedt, Géolocalistion de photographies numériques, GNU/Linux Magazine France n°96 (2007).
[3] J.-M. Friedt, É. Carry, Dissémination de données géoréférencées – qgis-server et openlayers, GNU/Linux Magazine France n°200 pp.12–22 (2017) https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-200/dissemination-de-donnees-georeferencees-qgis-server-et-openlayers
[4] J.-M. Friedt, Décodage par radio logicielle du VOR pour le positionnement sans GPS, Hackable n°36 (2021) https://connect.ed-diamond.com/Hackable/hk-036/decodage-par-radio-logicielle-du-vor-pour-le-positionnement-sans-gps
[5] N.G. Midgley, S.J. Cook, D.J. Graham & T.N. Tonkin, Origin, evolution and dynamic context of a Neoglacial lateral-frontal moraine at Austre Lovénbreen, Svalbard Geomorphology 198 pp. 96–106 (2013).
[6] H. Dumoulin, A. Zryd, N. Crispini, Glaciers : Passé-présent du Rhône au Mont-Blanc, Ed. Slatkine (2010).
[7] P. René, Glaciers des Pyrénées. Le réchauffement climatique en images, Ed. Cairn (2013).
[8] S. Coutterand, Atlas des glaciers disparus Guérin (2018).
[9] É. Bernard, J.-M. Friedt, S. Schiavone, F. Tolle, M. Griselin, Assessment of periglacial response to increased runoff. An Arctic hydrosystem bears witness, Land Degradation and Development 19 (10) pp. 3709–3720 (2018) et en particulier sa Fig. 2.
