2616 lines
262 KiB
TeX
2616 lines
262 KiB
TeX
\documentclass[12pt,a4paper,twoside]{scrartcl}
|
||
|
||
\usepackage{OCI}
|
||
|
||
\author{Clément Jeanguenat et Vincent Guyot}
|
||
|
||
\title{Cartographie et informatique}
|
||
|
||
\begin{document}
|
||
\maketitle
|
||
\tableofcontents
|
||
|
||
\section{Introduction}
|
||
Le travail présenté ici est un exemple de réflexion sur un projet d'enseignement de l'informatique à travers la cartographie. Il s'agit d'illustrer ce qui pourrait être réalisé au lycée en deuxième année de Discipline Obligatoire d'informatique dans le canton de Neuchâtel.
|
||
|
||
La démarche adoptée pour cette seconde année d'informatique, par la réunion d'un enseignant d'informatique associé à un enseignant d'une autre discipline, est en effet assez innovatrice pour qu'une réflexion approfondie sur un ou plusieurs cas concrets présente un intérêt.
|
||
|
||
D'autre part, au lycée Blaise-Cendrars, l'expérience de séminaires interdisciplinaires ayant montré que cette réflexion pouvait donner lieu à des discussions de préparation conséquentes, il nous a semblé nécessaire de les envisager et de les présenter ici pour tenter de percevoir ce qui est envisageable ou pas.
|
||
|
||
\medskip
|
||
Tant sur la forme que pour le fond, cette présentation est critiquable et doit l'être. Car c'est de cette critique que chaque duo d'enseignants va faire naître sa propre vision du contenu de cette seconde année.
|
||
|
||
Sur la forme, par exemple, le choix d'un article en pdf pour rendre compte du présent travail a été imposé par la dynamique des travaux de la commission DOIGT qui en est à l'origine. Comme la forme papier se prêtait mieux au rendu d'un rapport, c'est celle-ci qui a été choisie.
|
||
|
||
Mais, il est évident que l'utilisation d'un système d'enseignement à distance comme Moodle, adopté par un très grand nombre d'Universités et par les deux Écoles Polytechniques, permet une forme bien plus appropriée de transmission d'un savoir informatique que tout document purement papier. Nous avons donc réalisé parallement une construction de cours fictif sur \url{https://learn.s2.rpn.ch}, le moodle du canton de Neuchâtel. Mais, si cette construction, dans sa structure temporelle, permet surtout une bonne vision du temps disponible pour les projets, elle rend aussi plus difficile l'expression de critiques qui seules peuvent amener une richesse de perspective aboutissant à de véritables choix. C'est la raison d'être de ce texte.
|
||
|
||
\medskip
|
||
Il ne faut donc surtout pas voir ce travail comme un exemple plus ou moins abouti de ce qu'on pourrait faire, mais comme un exemple des difficultés rencontrées en envisageant sa réalisation. Les multiples questions qui se sont posées à cette occasion s'étant révélées d'une immense fécondité quant aux thèmes envisageables pour cette année interdisciplinaire, ce sont sur celles-ci que nous allons nous focaliser.
|
||
|
||
Vous ne finirez donc pas ce travail avec un cours clé en mains, mais nous espérons qu'il saura vous mettre sur un chemin constructif pour assumer vos propres intérêts.
|
||
|
||
\section{Interdisciplinarité}
|
||
Une vraie rencontre est une démarche vers l'autre et le c\oe ur de l'interdisciplinarité ne tient pas dans la question \og Peux-tu faire cela ? \fg{}, mais \og Comment fais-tu cela ? \fg{}.
|
||
|
||
C'est un point de vue.
|
||
|
||
On peut prétendre le contraire et dire que l'interdisciplinarité consiste à faire appel à des spécialistes qui vont seuls faire ce qu'ils savent faire pour construire ensemble un projet. On pourrait donc imaginer deux élèves, l'un cartographe et l'autre informaticien, qui réalisent un projet ensemble, chacun dans leur domaine.
|
||
|
||
Dans le cadre d'un cours de discipline obligatoire, on ne peut se satisfaire d'une telle acception du terme d'interdisciplinarité. Ici, c'est du \og Comment fais-tu cela ? \fg{} qu'il s'agit et cela sera dans deux disciplines différentes : la géographie et l'informatique.
|
||
|
||
\section{Projet}
|
||
Suivant en cela l'expérience acquise au Lycée Blaise-Cendrars de multiples séminaires interdisciplinaires, nous avons choisi de nous focaliser à l'intérieur de la géographie sur la cartographie et plus précisément sur les mensonges des cartes. L'espoir était d'obtenir de l'information par l'intermédiaire de l'ouvrage \og Comment faire mentir les cartes \fg{} \cite{MM2019} consacré au sujet\footnote{Dans \cite[p. 129]{NL2017}, se trouve un commentaire de l'ouvrage de \cite{MM2019} qui minimise le mensonge des cartes : \begin{quotation}
|
||
\textit{\og [\dots] Alors les cartes mentent-elles vraiment ? En tout cas, si c'est le cas, il est possible de mentir avec honnêteté. Les cartes doivent être conçues comme des miroirs grossissants plutôt que comme des miroirs déformants [NDLR : sic]. Leur rôle est d'éclairer, de mettre en lumière une facette de la réalité et non de tordre la réalité pour en montrer une image erronée. Néanmoins, l'exercice est délicat. À grossir certains traits et en en réduisant d'autres, la mise en carte ne peut produire qu'une image partiale du monde. Le but est donc d'effectuer des déformations qui ont du sens, basées sur un raisonnement scientifique et des faits avérés. Les cartes ne mentent que si le cartographe déforme sciemment la réalité pour donner à voir quelque chose qu'il sait erroné. Dans le cas contraire, les cartes sont des contributions partielles et subjectives à la compréhension d'une réalité complexe, plurielle et parfois en contradiction avec d'autres propositions.
|
||
\\Le but de la cartographie n'est donc pas de déformer la réalité, mais de la rendre intelligible par des simplifications inéluctables.\fg{}}
|
||
\end{quotation}
|
||
Le point de vue est intéressant, pourrait servir d'introduction à la problématique et pourrait mener à une interrogation philosophique sur le sujet.}.
|
||
|
||
Relevons que le choix du sujet s'est porté sur la géographie et non l'informatique. Nous aurions pu choisir par exemple \og les petites bases de données \fg{} et envisager ensuite d'en illustrer l'utilisation à travers la géographie. C'est l'inverse que nous avons choisi et cela a certainement été une conséquence du fait que l'enseignant d'informatique est aussi physicien et que son point de vue sur l'informatique est en premier lieu qu'elle est un service. Ainsi , d'entrée de jeu, il lui a paru plus intéressant de considérer ce que l'informatique peut apporter à la cartographie et non ce que la géographie peut apporter à l'informatique\footnote{Par exemple, il aurait pu être intéressant de travailler autour de la représentation des objets cartographiques dans les bases de données. Pour de petites bases en mode texte (non SQL), d'utilisation aisée, comment parvenir à stocker une information dont la nature est celle d'une image, mais qui doit être zoomable (ce qui introduit le questionnement du bitmap et du vectoriel) et ayant de fortes contraintes d'échelle (puisqu'en fonction de celle-ci la taille et le placement des objets peuvent être très complexes, voir nécessairement erronés).
|
||
|
||
Les petites bases de données sous forme de fichiers permettant de travailler sur diverses structures de données, des problématiques orientées informatiques auraient vu le jour de manière plus spécifique. Mais auraient nécessité de la programmation incluant la manipulation de fichiers, ce qui n'est pas toujours évident.
|
||
|
||
\smallskip
|
||
Cela dit, nous verrons que les bases de données, sous forme de fichiers texte, tableur ou nécessitant SQL, seront présentes par la suite, pas selon la problématique du stockage d'une information géographique, mais dans leur utilisation avec des connecteurs spécifiques et par quelques modifications simples.}.
|
||
|
||
\section{Cartographie}
|
||
\subsection{Préalable}
|
||
Au préalable, il nous semble important de souligner que la création d’une carte est d’abord une affaire d’intuition, de création et d’inventivité. En effet, comme le confirment plusieurs auteurs, malgré les progrès de l’informatique qui permettent un traitement aisé des données puis une cartographie quasi automatisée à l’aide de logiciels spécifiques, \og la carte est plus que jamais une création ou la compétence, le savoir-faire et l’imagination de l’auteur sont à l’œuvre\fg{} \cite{LFA00}. Nous partageons cette position et cette dernière influencera clairement nos choix en matière de création de cartes et de logiciels pour les réaliser.
|
||
|
||
Il est en effet intéressant de relever que la cartographie n’est pas seulement un exercice assuré par la machine et ses logiciels. Cartographier, c’est faire des choix et mobiliser son imagination. Du point de l’utilisation de l’informatique, cela implique que l’exercice cartographique ne mobilisera pas seulement des logiciels de cartographie spécifiques afin d’automatiser la réalisation des cartes mais aussi des logiciels de dessin qui dans certains cas seront plus adaptés.
|
||
|
||
D’ailleurs, au début des années 1990, certains auteurs comme Harley \cite{HJB95} mettaient en garde contre le risque de la cartographie assistée par ordinateur : \og Je ne plaide pas ici pour une forme d’anarchie du dessin, mais je prétends que la cartographie risque d’être réduite à une série de règles détachées des conséquences de la représentation. Avec le développement de nouvelles technologies institutionnelles telles que les systèmes d’information géographiques et la cartographie automatique, la probabilité de cette dérive augmente. L’effort de standardisation devient toujours plus crucial afin de faciliter les échanges entre systèmes et de réduire les conclusions technologiques\fg.
|
||
|
||
Avec la cartographie assistée par ordinateur, on voit donc apparaître le risque de productions cartographiques erronées ou du moins discutables. Les plus grosses lacunes se trouvent souvent dans les choix graphiques. On note ainsi \og une contradiction grandissante entre le niveau de sophistication de la cartographie théorique, mathématique et automatique et l’ignorance des principes élémentaires de la graphique\fg \cite{PD}.
|
||
|
||
Ce point de vue, que nous partageons, nous incite à envisager non seulement des projets de cartographie menés avec des logiciels spécifiques mais aussi avec des logiciels de dessin. Comme l’évoquait en effet déjà Le Fur au début des années 2000 \cite{LFA00}, deux types de logiciels sont susceptibles d’aider le cartographe dans sa tâche. D’une part, les logiciels de cartographie automatique (CAO) et les logiciels de dessin (DAO).
|
||
|
||
\subsection{Découverte}
|
||
Cette orientation d'une informatique au service de la cartographie a donc amené l'enseignant d'informatique à la rencontre de la géographie. Cela s'est fait, après discussion avec le géographe, par l'intermédiaire de deux logiciels spécifiques : l'un de cartographie pure, QGIS\footnote{Système d'Information Géographique Libre et Open Source. Voir~: \url{https://www.qgis.org/fr/site/}}, et l'autre de statistiques, R\footnote{R est un langage de programmation et un logiciel libre destiné aux statistiques et à la science des données. Voir~: \url{https://fr.wikipedia.org/wiki/R_(langage_de_programmation_et_environnement_statistique)}}.
|
||
|
||
L'objectif était de montrer que les modes de représentation des cartes étaient par essence mensongers et l'un des premiers exemples mentionnés était lié à l'enclassement des données. Celui-ci n'est pas en lui-même spécifique à la cartographie, mais il implique des problèmes de représentations cartographiques qui peuvent être mensongers.
|
||
|
||
\smallskip
|
||
Plus précisément, pour un projet concret, on peut s'imaginer les objectifs suivants.
|
||
\begin{itemize}
|
||
\item Les étudiants seraient conscients que \og une carte donnée, quelle qu’elle soit, n’est jamais que l’une des innombrables cartes que l’on pourrait dresser à partir de la même situation et des mêmes paramètres \fg{} \cite{MM2019}, et que donc, on peut faire \og mentir \fg{} les cartes.
|
||
\item Les étudiants seraient capables de produire un certain nombre de cartes à l’aide d’un logiciel de cartographie (R), de l’extraction des données nécessaires à la réalisation de la carte.
|
||
\item Les étudiants seraient capables d’analyser et de porter un regard critique sur leur production cartographique.
|
||
\item Les étudiants seraient capables d’organiser leur travail afin d’atteindre dans les délais fixés (maîtrise du calendrier) les objectifs définis par les enseignants.
|
||
\item Les étudiants seraient capables de présenter à d’autres le résultat de leur travail (par écrit et par oral).
|
||
\end{itemize}
|
||
|
||
Toujours dans une optique de service, le rôle de l'informatique serait ici de faciliter la variation des représentations pour mettre en évidence les défauts d'analyse.
|
||
|
||
\medskip
|
||
Ainsi, par exemple, le projet pourrait être d'utiliser un logiciel de statistiques (R) pour réaliser différents enclassements et le mappage de résultats de votations dans différents cantons ou différentes communes suisses, pour montrer que ceux-ci peuvent mener à des erreurs d'interprétation.
|
||
|
||
\medskip
|
||
Pour de tels projets, plusieurs questions se sont alors posées.
|
||
\begin{itemize}
|
||
\item Si la représentation est bien cartographique, le fond du problème n'est-il pas essentiellement mathématique ? Est-il bien souhaitable de confronter les élèves à un problème mathématique ?
|
||
\item D'un point de vue informatique, R étant à l'origine un logiciel en ligne de commande, est-il envisageable de l'utiliser ainsi ? Si une interface graphique est préférable, existe-t-elle et quelle est-elle ?
|
||
\item L'exigence d'un logiciel multi-plateforme, nécessaire pour une utilisation à la maison ou sur l'ordinateur personnel des élèves, est-elle alors réalisée ?
|
||
\end{itemize}
|
||
|
||
\smallskip
|
||
La réponse au troisième point a été résolue par des recherches sur internet. Mais, ne nous mentons pas, il existe plusieurs logiciels pour le même usage et la complexité de l'installation sur toutes les plateformes ne peut pas être testée systématiquement. Cela constitue une interrogation persistante que de savoir si celle-ci doit être gérée par l'enseignant, les services techniques ou l'élève lui-même, suivant les machines utilisées.
|
||
|
||
\smallskip
|
||
Pour le second point, l'expérience acquise pendant les OC d'informatique montre que la ligne de commande n'est pas contre-indiquée. Dans le cas de l'utilisation de shell distants par l'intermédiaire de ssh (shell sécurisé) ou pour tester de petits bouts de code Python dans l'éditeur natif, cela ne pose pas de problème. Mais, utiliser régulièrement un shell, demandant un minimum de configuration, elle ne peut être envisagée en DO sans passer par une phase d'apprentissage pas toujours très facile. Elle semble donc déconseillée.
|
||
|
||
Par contre, l'utilisation de logiciels spécifiques en mode graphique, mais orienté ligne de commande, ce qu'on nomme un environnement de développement (IDE : integrated development environment), est appréciée (par exemple, l'utilisation de \LaTeX{} dans un éditeur comme Texmaker, de la programmation en Python avec Geany ou autre IDE, ou même du code HTML, CSS ou javascript dans un éditeur comme bluefish) et appréciable pour faire comprendre la notion de code. Généralement les élèves l'acceptent bien, pour autant que cela reste relativement simple.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.48\textwidth}
|
||
\centering
|
||
\includegraphics[height=4.2cm]{images/RStudio.eps}
|
||
\caption[RStudio]{L'interface graphique en ligne de commande de RStudio (Source : Wikipedia)}\label{RStudio}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.48\textwidth}
|
||
\centering
|
||
\includegraphics[height=4.2cm]{images/RKward.eps}
|
||
\caption[RKward]{L'interface graphique en ligne de commande de RKward}\label{RKward}
|
||
\end{subfigure}
|
||
\caption[R]{Interfaces graphiques du logiciel R}\label{R}
|
||
\end{figure}
|
||
|
||
\subsection{Les logiciels R, RStudio et RKward}
|
||
Dans le cas de R (moteur des analyses statistiques), en dehors de la ligne de commande pure, le logiciel graphique en mode ligne de commande (voir figure \ref{RStudio}) le plus connu est incontestablement RStudio. C'est un logiciel libre et multi-plateforme\footnote{Cependant, il ne se trouve pas dans les dépôts de certaines grandes distribution linux, mais est uniquement disponible sous forme de paquet dédiés. Avec Windows et Mac, qui n'assurent pas la stabilité du système par la cohérence de dépôts officiels, l'installation ne pose généralement pas de problèmes pour autant que les services techniques l'autorisent. Si on accepte les mêmes risques d'instabilité, sur Linux, cela ne pose pas non plus de problèmes. Si, par contre, on veut se tenir au référentiel des distributions, il peut être nécessaire d'utiliser RKward (voir figure \ref{RKward}) au lieu de Rstudio, car il se trouve dans les dépôts de Debian, par exemple, ce qui est le gage d'une grande stabilité. Suivant les exigences des services techniques, on peut donc être amené à utiliser différents logiciels en fonction de la plateforme, ce qui peut poser problème dans le cadre d'une utilisation avec des machines personnelles ayant des systèmes d'exploitation différents. Par ailleurs, les dernières versions de RStudio ne sont plus disponibles en architecture 32 bits et pour une installation sur Raspberrypi, il faut passer par une compilation puisque RStudio n'existe pas sur processeur ARM. Enfin, la gestion des modules de R n'est pas simple, car leur installation passe par une compilation à la volée en C++ et sur différentes machines cela peut être difficile. Pour cela, l'une des solution à l'avenir serait l'utilisation de packages Docker.} qui est utilisé jusqu'à l'Université. Il dispose d'un module de cartographie\footnote{Nommé \emph{Cartography}. Voir \url{https://rgeomatic.hypotheses.org/659} ou \url{https://neocarto.hypotheses.org/1859}} associé aux statistiques qui permet de réaliser des cartes thématiques basées sur des enclassements. Mais si R est particulièrement efficace et adapté pour ce type de traitement, cette adaptation a pour corollaire une période de prise en main qui peut être importante autant pour les enseignants que pour les élèves.
|
||
|
||
Dans ces conditions, le premier point se pose de manière insistante. En somme, le jeu en vaut-il la chandelle ? La réponse va dépendre des connaissances des enseignants et des capacités des élèves.
|
||
|
||
Dans \cite{HC2014}, l'un des principaux ouvrages (ouvrage libre, c'est à signaler) sur R et la cartographie, les auteurs donnent plusieurs justifications à l'utilisation de R en cartographie.
|
||
|
||
\begin{quotation}
|
||
\textit{\og L’utilisation de R pour la cartographie n’est pas un choix évident. L’utilisateur qui souhaite faire une simple carte choroplèthe aura plus vite fait de la produire avec un logiciel de cartographie classique. L’utilisation de R pour faire de la cartographie se justifie si on envisage l’ensemble du flux de travail (workflow), c’est-à-dire l’intégration de la cartographie dans une chaîne de traitements.
|
||
\\
|
||
On peut envisager (au moins) quatre situations dans lesquelles R s’avèrera avantageux. D’abord, pour obtenir rapidement des sorties massives : les logiciels de cartographie et de SIG sont des logiciels à interface graphique (même si certains permettent d’automatiser les traitements) et il devient rapidement coûteux de produire manuellement des ensembles de nombreuses cartes.
|
||
\\
|
||
Ensuite, il sera intéressant d’utiliser R pour la cartographie dans le cadre d’un flux de travail unifié, c’est-à-dire pour intégrer la cartographie dans un flux de travail « classique » (analyse de données classiques, i.e. non
|
||
spatiales) entièrement fait avec R et se passer ainsi d’importations et d’exportations parfois plus nombreuses que prévues, et qui sont source d’erreurs. En effet, il arrive fréquemment de faire des calculs dans un logiciel de traitement de données, puis d’exporter les résultats pour les cartographier sur un autre logiciel, puis de refaire les calculs suite à une erreur ou
|
||
une modification, puis de réexporter les résultats à cartographier, etc.
|
||
\\
|
||
Unifier la chaîne de traitement est d’autant plus utile dans un flux de travail qui mobilise des fonctions d’analyse spatiale implémentées sous R. En effet, R dispose de plusieurs packages d’analyse spatiale et d’analyse de graphes (dont certaines sont abordées dans ce manuel) et il est très pratique de pouvoir manipuler des tableaux de données classiques, des objets spatiaux et/ou des graphes dans un flux de travail unifié.
|
||
\\
|
||
Enfin, dans certains cas, l’utilisateur cherche à combiner les traitements et l’écriture des contenus : il s’agit d’intégrer des sorties numériques, graphiques et cartographiques dans des supports qui sont également écrits avec R. Dans ce cas, la cartographie, comme le reste des traitements, s’intégrera dans la production d’ensemble.
|
||
\fg \cite[pp. 178-9]{HC2014}}
|
||
\end{quotation}
|
||
|
||
\smallskip
|
||
La valeur de l'exercice est cependant incontestable. Il permet de se familiariser avec une autre manière d'interagir avec un logiciel que par une interface graphique. Il permet de comprendre la nécessité de séparer le moteur d'un logiciel de son interface graphique et de se rendre compte que celui-ci peut être plus puissant qu'elle ne le laisse penser. Il permet aussi de comprendre qu'une interaction en mode texte peut s'avérer plus efficace que graphiquement, surtout dans un contexte d'action à distance. Enfin, il permet de ne plus avoir peur d'entrer en relation avec un ordinateur d'une autre manière qu'avec une souris ou un écran tactile.
|
||
|
||
Cependant, même s'il est souhaitable d'initier les élèves à cette manière d'utiliser un logiciel, une bonne introduction aux avantages de ce mode d'interaction est certainement nécessaire. Pour exemple, l'import d'un fond de carte, d'une couche de données, l'affichage du fond et des données avec le module cartography de R s'écrit de la manière suivante\footnote{Voir \url{https://neocarto.hypotheses.org/1859}} :
|
||
|
||
\begin{verbatim}
|
||
# Import du fond de carte
|
||
monFondDeCarte <-readOGR(dsn ="/repertoire-de-travail",layer = "nom-de-
|
||
la-couche")
|
||
|
||
# Import des données
|
||
mesDonnees <-read.csv( "/repertoire-de-travai/nom-de-mon-fichier.csv",
|
||
header=TRUE,sep=";",dec=",",encoding="latin1",)
|
||
|
||
# Affichage du fond de carte
|
||
plot(monFondDeCarte, col = "grey60",border = "grey20")
|
||
|
||
# Affichage des cercles proportionnels
|
||
propSymbolsLayer(spdf = monFondDeCarte, df = mesDonnees, var = "nom-de-
|
||
la-variable")
|
||
\end{verbatim}
|
||
|
||
Pour des personnes habituées à l'utilisation de la ligne de commande, la lecture de ce code ne posera pas de problème. Si l'efficacité de cette méthode est incontestable, la pédagogie nécessaire au traitement des différentes étapes en souffre, du moins auprès des plus visuels. De plus, la structure des données y est peu explicite. Ici le fichier les contenant est au format CSV et il est certainement nécessaire d'en expliciter le contenu préalablement. Évidemment R permet de le faire en donnant accès à une représentation tabulaire de celles-ci, mais l'appel textuel des procédures pour les traiter nécessite des connaissances préalables.
|
||
|
||
\smallskip
|
||
La situation est très comparable à celle de l'utilisation de \LaTeX. Car, s'il est tout-à-fait possible de convaincre des élèves des multiples avantages de l'utilisation d'un tel traitement de texte, une période d'apprentissage est nécessaire. Mais finalement, pour \LaTeX{} comme pour R, l'expérience d'une autre manière de gérer des données est profitable puisque très répandue dans les études supérieures et par la suite dans le monde scientifique.
|
||
|
||
Ainsi, un exemple de projet basé sur le logiciel R pourrait présenter les étapes suivantes.
|
||
|
||
\paragraph{Amorce}
|
||
Introduction à l’aide d’exemples de cartes qui mentent. On utilisera des exemples dans des domaines variés (analyse spatiale de divers phénomènes~; publicité~; domaine militaire~; propagande~; etc.)
|
||
|
||
\paragraph{Introduction aux bases de la cartographie du point de vue du géographe}
|
||
Présentation des règles de base de la cartographie
|
||
\begin{itemize}
|
||
\item Fonds de carte (projection)
|
||
\item Échelle
|
||
\item Langage cartographique (trois types de symboles et 6 variables visuelles)
|
||
\end{itemize}
|
||
\paragraph{Introduction aux logiciels de cartographie du point de vue de l’informaticien}
|
||
Les principales fonctionnalités de R et ses relations aux données. Par exemple, une introduction au logiciel\footnote{Voir~: \url{https://juba.github.io/tidyverse/02-prise_en_main.html} ou \url{http://wukan.ums-riate.fr/r2016/}} en créant une carte avec R par~:
|
||
\begin{enumerate}
|
||
\item l’import des données (fond de carte – readShapeSpatial – et données – read.table)~;
|
||
\item la jonction des deux fichiers (merge) grâce à un identifiant commun~;
|
||
\item si besoin la discrétisation d'une variable (classIntervals)~;
|
||
\item si besoin, le choix d'une gamme de couleurs (brewer.pal)~;
|
||
\item la création de la carte (plot)~;
|
||
\item la création de la légende (legend)~;
|
||
\item la mise en page la carte (échelle – SpatialPolygonsRescale -, titre, auteur, source etc.)\footnote{Voir~: \url{https://quanti.hypotheses.org/795/}}
|
||
\end{enumerate}
|
||
|
||
Cette phase introductive fait l’objet d’une évaluation classique (note 1)
|
||
|
||
\paragraph{Choix du projet}
|
||
Les étudiants définissent ensuite leur sujet par~:
|
||
\begin{itemize}
|
||
\item le choix d’une problématique et
|
||
\item le choix d’un territoire.
|
||
\end{itemize}
|
||
|
||
Suivraient la réalisation de cartes à l’aide d’un logiciel sur diverses thématiques à définir (population, habitat, fiscalité, environnement, politique, etc.), dont les données sont disponibles.
|
||
|
||
Le groupe devrait proposer des cartes qui, sur le même sujet et à partir des mêmes données, mettent en évidence de manière différente le phénomène.
|
||
|
||
Il s’agirait de faire varier l’échelle et surtout le langage cartographique afin de montrer que ce dernier n’est pas neutre et qu’il peut produire des représentations variées d’un même phénomène.
|
||
|
||
Chaque carte construite ferait l’objet d’une analyse. Les cartes seraient comparées afin de mettre en évidence ce que les choix cartographiques induisent comme représentations différentes d’un même phénomène.
|
||
|
||
Ce processus de recherche à deux pourrait faire l’objet d’une note (note 2). L’évaluation porterait ici sur les compétences suivantes : esprit d’initiative, créativité, autonomie, organisation, collaboration, gestion du temps, application, etc.
|
||
|
||
Ces cartes et leur commentaire, précédées d’une introduction et suivies d’une synthèse- conclusion, seraient présentées dans un dossier (note 3).
|
||
|
||
\paragraph{Présentation des projets}
|
||
Chaque groupe présenterait le résultat de son travail en plénum en choisissant la forme la plus appropriée pour ce travail (note 4)
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=12cm]{images/TableRKward.eps}
|
||
\caption{Les données dans RKward}\label{tablerkward}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
Comme dit précédemment, l'utilisation de R, si elle offre de grandes possibilités statistiques, n'est pas évidente au premier abord. Sur la figure \ref{tablerkward}, on voit un fichier shapefile de certains cantons suisses ouvert dans RKward par la commande :
|
||
\begin{verbatim}
|
||
library("rgdal")
|
||
cantons <- readOGR(dsn = path.expand("/home/vincent/Documents/
|
||
Cartographie/CantonsSuisse/data/SHAPEFILE_LV95_LN02/
|
||
swissBOUNDARIES3D_1_3_TLM_BEZIRKSGEBIET.shp"),
|
||
layer = "swissBOUNDARIES3D_1_3_TLM_BEZIRKSGEBIET", verbose = TRUE)
|
||
\end{verbatim}
|
||
On voit que l'accès aux données de shapefile est relativement aisé pour autant qu'on comprenne bien ce qu'on fait. On verra par la suite que QGIS permet un accès tout aussi aisé, sans pour autant disposer des fonctionnalités statistiques de R.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=7cm]{images/RKWardCantons.eps}
|
||
\caption[Réflexions]{La carte brute.}\label{rkwardcantons}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=7cm]{images/RKWardCantonsCoul.eps}
|
||
\caption[Tatouages]{Autre forme de carte.}\label{rkwardcantonscoul}
|
||
\end{subfigure}\\
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=7cm]{images/SuisseContours.eps}
|
||
\caption[Réflexions]{Fusion et recouvrement.}\label{suissecontours}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=7cm]{images/SuisseContoursVide.eps}
|
||
\caption[Tatouages]{Fusion simple.}\label{suissecontoursvide}
|
||
\end{subfigure}
|
||
\caption[Cartes]{Cartes}\label{rkwardcan}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
L'affichage de la carte correspondante se fait alors aisément par la commande \verb|plot()|. Le résultat est celui de la figure \ref{rkwardcan} où pour la figure \ref{rkwardcantonscoul} des options de couleurs ont été spécifiées.
|
||
|
||
Le traitement statistique des données ne sera pas traité ici. Mais une fois l'importation des données réalisées et les commandes d'impression testées, le travail d'analyse se fait directement en ligne de commande et l'affichage est traité par la commande \verb|plot|.
|
||
|
||
Par exemple, les figures \ref{suissecontours} et \ref{suissecontoursvide} ont été obtenues à l'aide du code suivant~:
|
||
\begin{verbatim}
|
||
library("sp")
|
||
library("rgdal")
|
||
library("rgeos")
|
||
|
||
cantons <- readOGR(dsn = path.expand("/home/vincent/Documents/
|
||
Cartographie/CantonsSuisse/data/SHAPEFILE_LV95_LN02/
|
||
swissBOUNDARIES3D_1_3_TLM_BEZIRKSGEBIET.shp"),
|
||
layer = "swissBOUNDARIES3D_1_3_TLM_BEZIRKSGEBIET", verbose = TRUE)
|
||
|
||
suisse <- gUnaryUnion(spgeom = cantons)
|
||
plot(cantons, lwd = 0.5)
|
||
plot(suisse, lwd = 2, border = "red", add = T)
|
||
#plot(suisse, lwd = 2, border = "red")
|
||
\end{verbatim}
|
||
On constate que pour obtenir ces résultats, il est nécessaire d'importer des librairies, notamment \emph{rgeos} qui permet, par exemple, la fusion des entités d'une couche de shapefile. Or, pour cela, on utilise la méthode \verb|gUnaryUnion(spgeom = cantons)| sur la variable de shapefile suisse. Non seulement cette méthode doit être trouvée ou connue de l'enseignant qui doit s'intéresser de près à la librairie, mais ses arguments lui doivent aussi être connus.
|
||
|
||
Ce n'est pas une mauvaise chose. On est ici dans le cas comparable de l'utilisation du grapheur Gnuplot à l'intérieur de \LaTeX. Celui-ci est beaucoup utilisé en OS physique et application des mathématiques au lycée Blaise-Cendrars en raison non seulement d'une qualité de rendu indéniable, mais aussi parce qu'une grande majorité d'articles de physique l'utilisent. Si ce choix est parfaitement justifiable, il faut reconnaître que même avec des classes motivées par ce genre d'exercice, il n'est pas simple de changer les habitudes.
|
||
|
||
Et là est bien le problème pour des classes peu habituées à cette manière de procéder~: il faut souvent rechercher de l'information sur les commandes et leurs arguments pour les rendre fonctionnelles. C'est très positif pour certaines classes, mais il faut admettre que d'autres solutions comme celles fournies par QGIS (voir ci-dessous) existent et il est important de reconnaître qu'elles peuvent être utilisées suivant les cas.
|
||
|
||
\subsection{Le logiciel QGIS}
|
||
Un autre axe de travail se situe au niveau des mensonges liés au graphisme des représentations cartographiques. Plus simple que des enclassements statistiques, le choix de la présence ou de l'absence d'une représentation graphique ou d'une nomenclature peut tromper.
|
||
|
||
Le problème est très général. En effet, ce n'est pas seulement le choix de la nomenclature adéquate qui est en jeu ici, mais aussi par exemple les simplifications d'échelle. En réalité, ce sont tous les modes de représentation graphique qu'on interpelle.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=13cm]{images/BEJUNE_GNU.eps}
|
||
\caption[Qgis]{Le logiciel QGIS}\label{bejunegnu}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
Pour permettre aux élèves de réaliser des projets dans ce cadre là, ce n'est plus un outil statistique qui est nécessaire, mais un outil graphique. Spécifiquement destiné à la cartographie, QGIS est le logiciel de la situation (mais il en existe d'autres comme GRASS GIS\footnote{Logiciel multi-plateforme, libre et gratuit. Voir~: \url{https://grass.osgeo.org/}}), car il permet tout type de modification des éléments vectoriels tels que frontières, légendes, éléments de paysage comme les arbres, etc.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=13cm]{images/SwissTopoCHXFDS.eps}
|
||
\caption[Qgis]{Les données fournies par Swisstopo}\label{swisstopochxfds}
|
||
\end{figure}
|
||
|
||
Sur la figure \ref{bejunegnu}, on peut voir l'interface graphique de QGIS pour un projet de présentation de l'espace BEJUNE. Les frontières des cantons de Berne, du Jura et de Neuchâtel ont été importées à partir du site de Swisstopo\footnote{Il faut mentionner le fait que Swisstopo recommande l'utilisation de QGIS (voir : \url{https://shop.swisstopo.admin.ch/fr/products/maps/national/digital/smv1000} et fournit même un PDF (Swiss Map Vector Shape avec QGIS Instructions) pour expliquer comment l'utiliser pour afficher des données. Dans ce PDF se trouve un lien vers ces données, mais, comme on peut le voir sur la figure \ref{swisstopochxfds}, celles-ci sont payantes !} sous le format geojson. QGIS gérant ce type de fichier, il a été possible de superposer les éléments vectoriels correspondant aux surfaces de ces cantons contenus dans le fichier adéquat à la carte de fond importée dynamiquement d'OpenStreetMap. Puis, des éléments de texte y ont été placés et, pour montrer l'une des possibilités intéressantes de QGIS, un fichier SVG (issu du logiciel Inkscape) contenant l'image vectorielle d'un GNU a été intégré à la carte. Outre les qualités d'importations d'éléments cartographiques comme les fonds de cartes, cela montre la puissance graphique dont est capable QGIS dans la représentation des symboles. En effet, la bordure, le fond et le symbole du cadre pouvant être rendu totalement transparent, on a la possibilité de superposer à tout fond de carte n'importe quelle image vectorielle svg, ce qui fait de QGIS un outil graphique pratiquement illimité. De plus, il est possible d'importer dans les cadres des formulaires QTdesigner, ce qui rend possible une édition de symboles normalisés en très grand nombre. Là encore la puissance de l'outil est à souligner\footnote{Il convient ici de citer \cite[pp. 203-4]{NL2017} (ingénieur de recherche au CNRS en cartographie à l'UMS RIATE, enseigne la cartographie et les SIG à l'université Paris Diderot7) qui décrit les systèmes d'information géographiques (SIG) de la manière suivante : \begin{quotation}
|
||
\textit{\og Le terme SIG est ambigu. Il désigne à la fois le logiciel dit SIG mais également un ensemble de données géographiques cohérentes stockées dans une base de donnée. [\dots] Les grandes fonctions du SIG sont les suivantes : abstraire (1), saisir (2), gérer et stocker (3), analyser (4) et représenter (5) le données géographiques. Assez peu performants dans la représentation de l'information géographique, les SIG sont des outils pertinents pour la réalisation des fonds de cartes. Ils permettent de \textbf{digitaliser} un fond de carte, de le \textbf{généraliser} et d'en changer la projection. Permettant d'évoluer dans un \textbf{système géoréférencé}, ils rendent aussi possible l'affichage et la superposition de différentes couches d'information de sources et de formats différents. [\dots] Quantum GIS (QGIS) est un SIG \emph{open source} [NDLR : il est en réalité libre] multiplateforme. Convivial et performant, il permettra au cartographe de réaliser toutes les opérations relatives à la conception cartographique. \url{www.gqis.org}\fg{} }
|
||
\end{quotation}
|
||
}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=13cm]{images/QgisHistogramme.eps}
|
||
\caption[QgisHisto]{Histogramme simple dans QGIS}\label{QgisHistogramme}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
La figure \ref{QgisHistogramme} présente l'utilisation d'un histogramme simple à une colonne pour la représentation de communes françaises. La table attributaire de la couche disposant de cette grandeur est utilisée directement ici. C'est la raison pour laquelle une seule couche de données est présente sur la figure.
|
||
|
||
\medskip
|
||
QGIS permet une autre utilisation très intéressante. Il s'agit de l'intégration de données tabulaires d'une autre origine que spécifiquement géographique. Évidemment, les couches vectorielles sont en réalité des données tabulaires. Mais on peut les croire uniquement liées à la cartographie en raison de leurs formats spécifiques. Il n'en est rien. QGIS gère en réalité une multitude de bases de données comme des fichiers texte (CSV par exemple), tableur (ODS par exemple) ou base relationnelle SQL (MariaDB par exemple). Ainsi, à travers les connecteurs présents, on peut accéder à une infinité de données tabulaires. En permettant de réaliser des opérations de jointure de tables géographiques avec d'autres types de tables, QGIS permet de représenter des données structurées par ailleurs.
|
||
|
||
Pour des élèves ne maîtrisant pas nécessairement bien les tables, l'utilisation de bases relationnelles SQL est évidemment difficile. La représentation issue d'un tableur, comme LibreOffice ou Gnumeric par exemple, permet une meilleure visualisation des données et même de les construire soi-même, ce qui est un avantage pédagogique. La structuration simple mais très pédagogique de données dans un fichier CSV, avec des séparateurs différents, l'est aussi. QGIS permet ensuite de réaliser des imports de ce type de fichiers très simplement dans une couche vectorielle et de les utiliser graphiquement.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/Tables.eps}
|
||
\caption[Tables]{Tables géographiques et statistiques}\label{Tables}
|
||
\end{figure}
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=13cm]{images/Jointure.eps}
|
||
\caption[Jointure]{Jointure dans QGIS}\label{Jointure}
|
||
\end{figure}
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/Communes.eps}
|
||
\caption[PietonVelo]{Nombre de piétons, vélos et voitures}\label{QgisCamembert}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
La figure \ref{Tables} montre les données tabulaires d'une couche géographique et par dessus celles de données préparées dans un tableur Gnumeric. Puis, la figure \ref{Jointure} montre ce qu'elles sont devenues après export au format ODS depuis Gnumeric, puis import dans QGIS et jointes par l'intermédiaire de leur CODE\_INSEE. Enfin, la figure \ref{QgisCamembert} montre la représentation graphique des données sur le fond de carte sous la forme de camembert.
|
||
|
||
Remarquez aussi les mensonges qui figurent dans cette carte pour alimenter le projet évoqué ci-dessus.
|
||
|
||
\smallskip
|
||
Il faut finalement souligner que, suivant les versions de QGIS, la manipulation de certains éléments comme les légendes par exemple, sera plus ou moins simple. Pour parvenir à relier la taille des cercles proportionnellement au nombre d'habitants, il a fallu avoir recours à un plugin dont le fonctionnement était complexe. Par ailleurs, la légende liée au véhicules ne fut pas simple à mettre en place. Il faut donc considérer que l'apprentissage de l'outil peut être chronophage, non seulement pour les légendes, mais pour la mise en place des diagrammes.
|
||
|
||
L'exercice a cependant l'avantage de forcer la construction de données tabulaires et d'être un bel exemple de jointure entre deux tables, l'utilité de ce type d'opération n'étant pas évidente quand on travaille sur des tables déjà structurées dans une base de données unique.
|
||
|
||
\medskip
|
||
Comme autre exemple d'utilisation de QGIS, dans sa raison d'être et dans le cadre du projet sur le mensonge, on peut mentionner ici la réalisation, pour une activité d'apprentissage de l'utilisation de carte par des élèves de l'école primaire, d'un plan de la cour du collège de l'Ouest, à la Chaux-de-Fonds.
|
||
|
||
On peut envisager un tel exercice, ici réellement réalisé au début de l'année scolaire 2019, pour des élèves dont l'intérêt est l'enseignement et qui se destinent à la Haute École Pédagogique (HEP).
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=13cm]{images/Sitn.eps}
|
||
\caption[PietonVelo]{Le géoportail du canton de Neuchâtel}\label{sitn}
|
||
\end{figure}
|
||
|
||
Au départ, l'idée est de réaliser une carte de la cour du collège pour y placer des éléments sous forme d'étiquettes que les élèves devront trouver en se référant à la carte. On va ici parler de carte plutôt que de schéma de la cour, l'idée étant de récupérer une carte préalablement réalisée sur le site du Géoportail du système d'information du territoire neuchâtelois (SITN)\footnote{Voir~: \url{https://sitn.ne.ch/}. Faire une recherche sur \emph{Cour du collège de l'Ouest}}. Le placement des étiquettes devait se faire à partir du fond de carte présenté à la figure \ref{sitn}.
|
||
|
||
Or, pour récupérer des données sur le site du SITN, il faut passer par Géoshop, \og une solution permettant de demander un devis et commander des données cartographiques \fg{}\footnote{Voir~: \url{https://sitn.ne.ch/geoshop/}}. La nécessité d'une inscription et l'éventualité de devoir payer a été rédhibitoire et même si la représentation des bâtiments est agréable, comme nous allons le voir, elle est évidemment fausse.
|
||
|
||
En arrière plan de la couche fournie par le SITN se trouve OpenStreetMap (OSM) dont la carte est aussi disponible. Mais aucune indication ne se trouve sur le site pour récupérer les données relatives à la cour du collège de l'Ouest.
|
||
|
||
Outre le fait que les données d'OpenStreetMap sont libres, il se trouve que QGIS en gère parfaitement l'importation directe grâce au plugin \emph{QuickMapServices} qui dispose d'une entrée OpenStreetMap.
|
||
|
||
Mais ce n'est pas suffisant. L'utilisation d'une couche de fond OSM en parallèle avec UMAP\footnote{Voir~: \url{https://umap.openstreetmap.fr/fr/}} qui \og permet de créer des cartes personnalisées sur des fonds OpenStreetMap en un instant \fg{} aurait alors été suffisante. Le problème vient du fait que s'appuyer sur un fond de carte ne permet pas d'en isoler une partie du contenu, à moins de le redessiner au-dessus du fond. Ainsi, il est impossible d'isoler la cour du collège des bâtiments environnants.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/OSMexport.eps}
|
||
\caption[PietonVelo]{Exportation de données OSM}\label{osmexport}
|
||
\end{figure}
|
||
|
||
Pour cela, il était nécessaire de récupérer les données relatives à cette cour à partir d'OpenStreetMap. Pour un système cartographique libre, c'est évidemment possible, mais aussi très instructif quant à la structure de données sur laquelle repose ce système. On voit à la figure \ref{osmexport} que le bouton \emph{Exporter} d'OSM propose d'extraire les données d'une région suivant ses coordonnées et il fournit pour cela un fichier propre à OSM d'extension éponyme. Ce fichier peut alors être importé par QGIS, mais doit être converti en fichier shapefile (shp) pour être utilisable. Il faut pour cela enregistrer la couche correspondant au fichier d'extension osm au format \emph{ESRI shapefile}. Puis, dans la table d'attributs de cette nouvelle couche, en sélectionnant successivement chacun de ses éléments, visualiser ceux qu'on ne désire pas et les effacer (en mode édition de la table). On obtient ainsi uniquement les données relatives à la cour du collège. Cela permet, en supprimant l'affichage de la carte OSM de fond, de se rapprocher d'un schéma de la cour.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=6cm]{images/tableattributs.eps}
|
||
\caption[TableAttributs]{Couches et table d'attributs}\label{tableattributs}
|
||
\end{figure}
|
||
|
||
La différence avec un schéma, réalisé avec un logiciel de dessin vectoriel, outre le géo-positionnement des éléments, est que ceux-ci sont des éléments tabulaires en arrière plan. Ainsi, au contraire d'un logiciel de dessin vectoriel où les éléments sont enregistrés dans un langage balisé comme XML pour Inkscape par exemple, les éléments des couches vectorielles shp sont enregistrés dans des tables d'attributs. La figure \ref{tableattributs} présente les cinq couches du projet de l'école de l'Ouest, une couche osm et quatre shapefiles. En regard se trouve la table d'attributs de la couche \emph{Installations} qu'il est possible de manipuler directement.
|
||
|
||
Ce mode de fonctionnement est très puissant puisque, comme nous l'avons vu précédemment, des couches de données provenant de diverses sources (fichier ou base de données) peuvent ainsi être jointes aux couches cartographiques à proprement parlé. Mais, il est plus rigide que celui d'un logiciel de dessin vectoriel, car les attributs graphiques, comme la couleur de remplissage par exemple, sont par défaut donnés à l'ensemble des éléments d'une couche. Pour la différencier, il faut créer des catégories qui rendent difficile la gestion individuelle de chaque entité. C'est bien entendu un mode de fonctionnement particulièrement efficace dans le domaine de la cartographie, mais il peut être déroutant au premier abord pour des élèves habitués à ne pas penser en terme de groupes d'éléments symboliques, mais désireux d'appliquer successivement des attributs particulier à chaque élément. La situation s'apparente à celle de l'utilisation par les élèves des éléments typographiques dans un traitement de texte où l'utilisation des styles est peu répandue.
|
||
|
||
\smallskip
|
||
Par contre, une utilisation statistique des données est possible alors qu'avec un schéma ce n'est pas le cas. Même si QGIS n'a pas été prévu pour cela, il existe maintenant des modules permettant d'y utiliser R directement. L'import de tables LibreOffice ou autre tableur est aussi un grand avantage, car il permet un pré-traitement des données dans ce type de logiciels normalement bien connu des élèves.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/CollegeOuestFinal.eps}
|
||
\caption[CollegeOuest]{La cour du college de l'Ouest}\label{collegeouestfinal}
|
||
\end{figure}
|
||
|
||
Sur la figure \ref{collegeouestfinal} se trouve la carte utilisée par les élèves (de quatrième HARMOS) du collège de l'Ouest pour leur travail de sensibilisation à la cartographie. Il s'agissait bien de cartographie puisque les deux cartes présentées à la figure \ref{collegeouestfinal} et \ref{sitn}, respectivement réalisées sous QGIS et récupérée sur le site du SITN, ont été utilisées pour une discussion critique quant aux éléments représentés. Par exemple, la place de jeu ne figure pas sur la carte du SITN, les arbres sont partiellement représentés et une grosse erreur d'ombrage vers le SUD s'y trouve, non seulement sur le collège, mais sur l'ensemble des habitations de la ville et sans vouloir préjuger de la raison de cette erreur, on peut certainement affirmer qu'il s'agit d'un bel exemple de mensonge cartographique, puisque cet ombrage (et il ne s'agit pas d'une mauvaise représentation de bâtiments en 3D, puisque l'image satellitaire correspondant présente des façades qui ne sont pas dans l'ombre ; tout au plus peut-il s'agir d'une décision arbitraire de donner du relief par une ombre délibérément choisie vers le Sud, c'est-à-dire d'une convention. Si c'était le cas, elle serait contestable et particulièrement malheureuse) n'est possible que dans l'hémisphère sud.
|
||
|
||
Même dans le cadre d'une activité pour une classe primaire, la réalisation de la carte a permis de mettre particulièrement bien en évidence les difficultés liées aux choix des éléments représentés et à leur modélisation et les erreurs inévitablement présentes dans chaque représentation. Elle a aussi permis de comprendre les difficultés d'utilisation de logiciels spécifiquement destinés à la liaison entre des données géographiques et leur représentation cartographique (les étiquettes placées ont trouvé une expression géographique tabulaire).
|
||
|
||
\bigskip
|
||
Comme autre exemple de représentation cartographique à la limite de la schématisation, on trouve aussi dans \cite[p. 146, figure 7.7]{MM2019}, l'exemple des prix des taxes d'habitations qui montre que l'utilisation de données tarifaires très locales peuvent permettre de justifier des réclamations par l'intermédiaire de modes de représentation graphique adéquats, comme des histogrammes sur cartes.
|
||
|
||
Comme avec l'exemple de l'école primaire de l'Ouest, on peut dire que QGIS est peu approprié pour de telles fonctionnalités qui impliquent une relation simple avec des quantité numériques non issues d'une base de données, car l'échelle est ici si petite qu'on est au frontières entre un logiciel de cartographie et des logiciels de dessin vectoriels généralistes comme inkscape dont on reparlera plus loin. Avec les premiers, l'impératif de géolocalisation pénalise la facilité de représentation et avec les seconds, cette dernière nuit à la qualité du positionnement.
|
||
|
||
\medskip
|
||
Évidemment, QGIS est un magnifique logiciel de cartographie qui est presque incontournable. Mais, ne négligeons pas le fait que certaines de ses fonctionnalités sont complexes. L'utilisation de fond de cartes peut être ou ne pas être simple, car il existe de nombreuses manières de les obtenir et que leur description est loin d'être évidente. Certes des outils d'importation automatiques existent, mais il faut les connaître et si l'importation directe de fichiers de fond cartographiques est naturellement possible - puisque l'une des raisons d'être de QGIS - les trouver, sélectionner ceux dont les formats lui sont adaptés et les importer réellement nécessite des connaissances préalables à tout travail personnel. Pour aller plus loin avec QGIS, vous pouvez consulter l'ouvrage \og \textit{Apprendre QGIS par l'exemple} \fg{} de \cite{GA15} qui présente de nombreux cas d'utilisations pratiques.
|
||
|
||
Là encore, il faut se demander si le jeu en vaut la chandelle et qui va réaliser le travail de compréhension permettant d'apprendre aux élèves à réaliser ces étapes sans trop de difficultés, vu que l'informatique est ici intimement imbriquée dans la géographie et que la connaissance d'un tel logiciel n'est certainement pas dans le bagage de base d'un informaticien. Quoi qu'il en soit, QGIS dispose d'une aide en ligne directement disponible depuis le menu d'aide et celle-ci est non seulement très fournie, mais disponible en français.
|
||
|
||
\subsection{Le logiciel MAGRIT}
|
||
L'utilisation d'un logicil comme QGIS passe par son installation. C'est un logiciel très connu et sa présence sur internet a tendance à masquer d'autres projets très intéressants. Tout le travail réalisé ci-dessus l'a été sans connaître MAGRIT et cela souligne la difficulté des recherches préalables à tout sujet.
|
||
|
||
Magrit est un logiciel remarquable. Voici comment il est décrit sur \emph{Géo confluences}, site français de \emph{Ressources géographiques pour les enseignants}\footnote{Voir~: \url{http://geoconfluences.ens-lyon.fr/actualites/veille/liens/magrit-outils-carto}}~:
|
||
\begin{quotation}
|
||
\textit{\og L'UMS RIATE est une unité mixte de service qui a pour objet le soutien aux recherches portant sur l'aménagement du territoire européen et qui est sous la cotutelle du CNRS, de l'Université Paris Diderot et du Cget.
|
||
\\
|
||
Dans le cadre de ses activités, le pôle géomatique de l'UMS Riate a développé une application de cartographie en ligne Magrit, cet outil permet de réaliser des cartes statistiques directement dans un navigateur web, quel que soit le système d'exploitation (Mac OS, Windows, Linux \dots), et cela à partir des propres données de l'utilisateur. La plupart des modes de représentation classiques sont proposés (cartes en proportion, cartes choroplèthes, typologies, etc.). D'autres modes de représentation plus innovants sont également disponibles (anamorphoses, lissages, discontinuités, carroyages, etc.).
|
||
\\
|
||
Le projet est entièrement libre (code sous licence CeCILL, compatible avec la GNU GPL). Il repose sur une suite moderne de technologies libres et open-source et il est possible de déployer sa propre instance de l'application (notamment via Docker). Le code de Magrit est hébergé sur GitHub. \fg}
|
||
\end{quotation}
|
||
|
||
On trouvera aussi la présentation de MAGRIT sur le site du CNRS\footnote{Voir~: \url{http://riate.cnrs.fr/?p=5698}} et on y accède à l'adresse \url{http://magrit.cnrs.fr/}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/Magrit.eps}
|
||
\caption[CollegeOuest]{Le logiciel MAGRIT}\label{magrit}
|
||
\end{figure}
|
||
|
||
L'intérêt de ce logiciel, outre le fait qu'il soit libre et gratuit, est qu'il est disponible directement en ligne. Son utilisation est aisée, même si les possibilités d'intégration de cartes de fond OpenStreetMap par exemple ne sont pas automatique, comme cela est le cas avec QGIS. L'import du fond se fait via les traditionnels fichiers Geojson ou shapefile, par exemple. Des couches de données peuvent ensuite être intégrées pour permettre leur intégration dans la carte.
|
||
|
||
Sur la figure \ref{magrit}, on peut voir l'utilisation des mêmes données que celles utilisées avec QGIS pour les figure \ref{QgisHistogramme}, \ref{Tables}, \ref{Jointure} et \ref{QgisCamembert}, mais avec MAGRIT. On y voit l'interface principale de MAGRIT dont les onglets spécifient assez clairement le fonctionnement jusqu'à l'export en SVG. On y voit aussi qu'il est possible de spécifier différentes projections.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/Anamorphose.eps}
|
||
\caption[CollegeOuest]{Un cartogramme du nombre d'oiseaux}\label{anamorphose}
|
||
\end{figure}
|
||
|
||
On est évidemment pas là dans le cadre d'un logiciel aussi complet que QGIS, mais sa disponibilité sur le réseau et sa simplicité d'utilisation en font un outil à ne pas négliger même si tout n'y est pas simple. Par exemple, la figure \ref{anamorphose} présente une carte en anamorphose d'une étude du nombre d'oiseaux dans les différents cantons réalisée sous MAGRIT avec le fond de carte des cantons de Swisstopo\footnote{Relevons que la Confédération met à disposition des données dites \emph{Opendata}, notamment dans le domaine de la cartographie à l'adresse \url{https://opendata.swiss/fr/organization/bundesamt-fur-landestopografie-swisstopo}. D'autres domaines y figurent et pour obtenir des données relativement facilement, il ne faut pas hésiter à s'y rendre.}. Si l'accès au données tabulaires est possible, leur édition n'est pas possible. Pour ajouter un champ contenant le nombre d'oiseaux, il a été nécessaire d'utiliser le fichier d'extension dbf de swissBOUNDARIES3D contenant la base de donnée pour l'éditer. En en supprimant tous les champs sauf l'UUID des cantons et en y ajoutant le nombre d'oiseaux, on peut alors importer ces données dans MAGRIT et y réaliser une fusion avec les données du fond de carte. Seulement alors il est possible d'y accéder pour réaliser la carte. Mais les possibilités offertes pour son choix et la manipulation de ses éléments sont relativement peu nombreux (comme le placement des étiquettes numériques qui est prédéfini sans aucune possibilité de changement, contrairement à ce que permet QGIS), ce qui est pédagogiquement à la fois un avantage et un désavantage, suivant le niveau de connaissances techniques des élèves.
|
||
|
||
Évidemment, cette carte (figure \ref{anamorphose}) illustre encore une fois un mensonge, puisque le nombre d'oiseaux a été délibérément choisi pour être faible en Suisse romande, MAGRIT proposant un type de carte dit de \emph{discontinuités}. L'idée était de l'utiliser pour inventer un \og r\oe stigraben \fg{} des extinctions et le mettre en évidence cartographiquement. Mais, le résultat ne fut pas à la hauteur de nos espérances.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/Khartis1.eps}
|
||
\caption[Khartis 1]{Le logiciel Khartis}\label{khartis1}
|
||
\end{figure}
|
||
|
||
\subsection{Le logiciel KHARTIS}
|
||
KHARTIS\footnote{Voir : \url{http://www.sciencespo.fr/cartographie/khartis/}} a été développé par l’Atelier de cartographie de Science-Po (France). Il permet la réalisation de cartes thématiques assez facilement. Il met à disposition plusieurs types de projections cartographiques, plusieurs séries de données et différents moyens de visualisations comme on peut le voir dans les figures \ref{khartis1}, \ref{khartis2}, \ref{khartis3} et \ref{khartis4}, pages \pageref{khartis1}, \pageref{khartisdonnees} et \pageref{khartis4}. Il permet aussi d’importer ses propres fonds de cartes et séries de données. Les cartes produites peuvent ensuite être exportées sans problème.
|
||
|
||
C'est un logiciel libre disponible directement en ligne\footnote{Malheureusement avec le traçeur Google Analytics.} ou en téléchargement pour Macintosh, Windows et Linux. Malheureusement, il n'est ni disponible en version 32 bits, ni en version ARM, ce qui l'exclut des raspberrypi, notamment.
|
||
|
||
Ce logiciel permettrait par exemple de réaliser un travail de production cartes en faisant varier les différents paramètres qui entrent en jeu dans la construction des cartes. Dans l’exemple de la figure \ref{khartisdonnees}, les deux cartes ont été produites avec les mêmes données mais avec des méthodes de discrétisation différentes.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/Khartis2.eps}
|
||
\caption[Réflexions]{Une première discrétisation}\label{khartis2}
|
||
\end{subfigure}
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/Khartis3.eps}
|
||
\caption[Réflexions]{Une première discrétisation}\label{khartis3}
|
||
\end{subfigure}
|
||
\caption[Cartes]{Traitement des données dans Khartis}\label{khartisdonnees}
|
||
\end{figure}
|
||
|
||
Quant à la carte de la figure \ref{khartis4}, la série de données est la même que dans les cartes précédentes, mais c’est la
|
||
projection qui est différente.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=14.5cm]{images/Khartis4.eps}
|
||
\caption[Khartis 1]{Projections dans Khartis}\label{khartis4}
|
||
\end{figure}
|
||
|
||
\section{Changement de paradigme}
|
||
Jusqu'ici, la recherche de logiciels permettant de traiter le thème proposé a été orientée vers des logiciels relativement pointus en statistiques et cartographie. Pour un géographe, cela paraît autant évident de procéder ainsi que pour un physicien d'utiliser \LaTeX{} pour un rapport d'expérience. Mais, malgré cette évidence, c'est un paradigme contestable.
|
||
|
||
Est-ce donc vraiment une bonne idée ? Ou est-ce un défaut inhérent à la réunion de deux spécialistes qui voient dans le projet de DO l'occasion de présenter certains aspects de leur discipline que leur cours de base ne permet pas d'aborder ?
|
||
|
||
\medskip
|
||
La découverte du livre \emph{Terra forma, manuel de cartographie potentielles} de \cite{FA2019}, va nous permettre d'envisager un changement total de paradigme. Jusqu'ici, nous nous étions focalisé sur des logiciels spécifiquement orienté sur la cartographie (même R l'était par l'intermédiaire de son module \emph{cartography}) et la spécialisation de ceux-ci permettant d'aller très loin dans une représentation aux canons actuels de cette discipline (canons, car il s'agit toujours de représentations forcément erronées), nous nous sommes focalisés sur des représentations d'un haut niveau technique fort intéressantes et certainement très adaptées à des étudiants en géographie, mais plus difficilement exploitable pour des élèves d'autres horizons.
|
||
|
||
\bigskip
|
||
\emph{Terra Forma} est un ouvrage assez exceptionnel. Il porte le sous titre de \emph{Manuel de cartorgaphies potentielles}. Tout les mots comptent. Il s'agit d'abord d'un manuel, en ce sens qu'il se veut une incitation à la réalisation de cartes, et non seulement à leur analyse. Ensuite, il envisage \emph{des cartographies} plurielles. Contrairement à ce dans quoi la nature des logiciels cartographiques nous enferme, et en cela la nature même des logiciels tout court, c'est-à-dire ici l'utilisation de fonds de cartes prédéfinies, les auteures de \emph{Terra Forma} partent d'une réflexion épistémologique qui s'en dégage très clairement en revisitant radicalement la notion même de cartes.
|
||
|
||
\medskip
|
||
\emph {Le constat est intéressant, car cela montre que l'abord d'une discipline par l'informatique, dans le sens de promouvoir l'informatique par l'utilisation de logiciels adaptés à une discipline, constitue une réelle limitation de l'éclairage que l'informatique elle-même peut donner à cette discipline, comme on le verra plus loin.}
|
||
|
||
\medskip
|
||
Il ne faut pourtant pas aller trop loin en considérant par exemple que les connaissances informatiques peuvent faire obstacle à la compréhension profonde d'une discipline en ce qu'elle lui met des ornières. On pourrait le penser en considérant la note de \cite[p. 4]{FA2019} :
|
||
|
||
\begin{quotation}
|
||
\emph{\dots{} Il faut mentionner en outre le système d'information géographique utilisé par le institutions de l'État (collectivités et autres), outils professionnel qui se revendique comme participant à l'open source (QGIS, logiciel gratuit), mais dont les données sont souvent sécurisées et la manipulation complexe. C'est un système d'accumulation de données fondé sur les coordonnées géographiques -- véritable encodage des territoires. À une époque de démocratisation des cartes et de développement de l'open data, le problème n'est plus l'accès à l'information mais l'organisation de celle-ci. L'open source à révolutionné les usages et aussi les pratiques professionnelles. Les architectes, les urbanistes et les paysagistes ne peuvent d'ailleurs plus travailler sans Google Maps.}
|
||
\end{quotation}
|
||
qui est non seulement la seule référence de l'ouvrage à l'informatique, mais est aussi exemplaire par ce qu'elle laisse deviner des connaissances informatiques des auteures. Les deux dernières phrases sont à cet égard éclairantes, puisque Google Maps n'est pas open source et, même s'il l'était, ce n'est pas l'open source qui a révolutionné les usages, mais les logiciels libres (L'open source est une notion récemment récupérée par des entreprises qui n'ont pas l'objectif de libérer les connaissances. Pour l'illustrer, Richard Stalmann disait lors de l'une de ses conférences à l'EPFL : \og Je ne suis pas open source, mais libre ! \fg{}).
|
||
|
||
Cela dit, on trouve aussi une position intéressante sur QGIS dont \og \dots{} la manipulation [est] complexe \fg{} et, serait-on tenté d'ajouter étant donné l'incroyable originalité des auteures en terme de cartographie, limitante.
|
||
|
||
Car les auteures, qui ne sont pas géographes, il faut le relever, mais architectes et historienne des sciences, peut-être parce qu'elles sont parties sans aucun à priori informatique montrent dans cet ouvrage l'importance d'une réflexion préalable à toute utilisation de l'outil informatique.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.49\textwidth}
|
||
\centering
|
||
\includegraphics[width=7.8cm]{images/terreGlissements2.eps}
|
||
\caption[Réflexions]{Premières réflexions classiques \cite[p. 26]{FA2019}}\label{carte1}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.49\textwidth}
|
||
\centering
|
||
\includegraphics[width=6.1cm]{images/mines.eps}
|
||
\caption[Tatouages]{Tatouages territoriaux : les mines \cite[p. 35]{FA2019}}\label{carte2}
|
||
\end{subfigure}
|
||
\caption[Cartes]{Cartes}\label{cartes}
|
||
\end{figure}
|
||
|
||
Préalable, mais certainement pas indépendante, car, il est simplement évident que \emph{Terra Forma} n'aurait simplement pas pu exister sans l'informatique (considérez pour vous en rendre compte la structure des cartes présentées dans les figures \ref{carte1}, \ref{carte2}, \dots). Et c'est précisément ce qui nous intéresse ici.
|
||
|
||
\medskip
|
||
La citation ci-dessus contient le programme d'une démarche novatrice :
|
||
\begin{quote}
|
||
\emph{À une époque de démocratisation des cartes et de développement de l'open data, le problème n'est plus l'accès à l'information mais l'organisation de celle-ci.}
|
||
\end{quote}
|
||
On touche là l'essence même de la cartographie et les auteures insistent sur le fait que cette organisation peut être très variée : elles parlent non de manuel de cartographie, mais de manuel de cartographies. Le pluriel est ici essentiel. Or, à priori, l'utilisation exclusive de logiciels purement cartographiques restreint fortement ce pluriel et en même temps la diversité des outils informatiques potentiellement utilisables en cartographie. C'est là la révélation qu'on peut en tirer. Les cartes présentées dans \emph{Terra Forma} sont potentielles. Elles vont constituer des cartes possibles, extrêmement originales pour lesquelles l'utilisation de logiciels spécifiques ne convient pas.
|
||
|
||
La clé du changement de paradigme est donc qu'il ne faut surtout pas se laisser enfermer par des solutions informatiques répondant à des problèmes particuliers, comme \og un système d'accumulation de données fondé sur les coordonnées géographiques \fg, car la cartographie ne se limite bien heureusement pas à cela.
|
||
|
||
\medskip
|
||
\emph{La conséquence de ce changement de paradigme est qu'il existe de nombreux logiciels généraux parfaitement adaptés à la cartographie pour autant qu'on ne la considère pas que sous l'angle des \og coordonnées géographiques \fg{} et que cela peut permettre aux étudiants de réaliser des travaux de cartographie beaucoup plus personnels, plus libres et pour les enseignants certainement plus facilement gérables.}
|
||
|
||
\subsection{Révolutions}
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/modeleSol.eps}
|
||
\caption{Modèle sol \cite[pp. 42-43]{FA2019}}\label{modelesol}
|
||
\end{subfigure}
|
||
|
||
\medskip
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/carteSol.eps}
|
||
\caption{Carte sol \cite[pp. 44-45]{FA2019}}\label{cartesol}
|
||
\end{subfigure}
|
||
\caption[Construction]{Modèle et carte}\label{modelecarte}
|
||
\end{figure}
|
||
|
||
Pour donner une idée du renversement de paradigme cartographique présenté dans \emph{Terra Forma}, sans dévoiler les autres changements amenés par les auteures pour bousculer l'idée traditionnelle de carte, on va esquisser le premier modèle présenté nommé SOL. Voici comment \cite[p. 16]{FA2019} présente le problème.
|
||
|
||
\begin{quotation}
|
||
\emph{La plupart de ces cartes, reconnaissons-le, ne sont pas faciles à lire si l'on ne s'acclimate pas d'abord à leurs codes et à leurs légendes. Tout comme une carte aborigène reste muette si l'on n'est pas instruit par les autochtones de sa signification. Une carte à l'occidentale est justement faite pour se passer des autochtones et de leur manière de conduire l'attention vers un paysage multiple\footnote{Ndlr: elle est donc déjà limitante, comme le logiciel.}. Opter pour des cartes indéchiffrables sans guide, c'est proposer un autre régime de découverte et de proximité. On pourra objecter que ces cartes dépourvues de topographie et de coordonnées ne sont plus des cartes. Si elles ne ressemblent plus à celles que nous connaissons, elles en gardent cependant un des objectifs : se repérer. Se repérer, on croit que c'est isoler des mers stables, des repères physiques immobiles depuis lesquels se situer et trianguler. Mais lorsque le sol même semble se modifier, les repères ne peuvent être identiques : le point fixe autour duquel le reste tourne, c'est l'activité des vivants elle-même.}
|
||
\end{quotation}
|
||
|
||
Puis, plus précisément \cite[p. 25]{FA2019} :
|
||
|
||
\begin{quotation}
|
||
\emph{Le premier référentiel de la carte auquel se fier, c'est la direction. Longtemps nos cartes ont indiqué le nord : le nord magnétique, mais aussi celui de l'hémisphère nord centré sur l'Europe. Cependant un autre référentiel bien plus ambigu fait irruption avec l'intrusion de Gaïa. Ce référentiel est à la fois plus puissant et plus fragile, plus global et plus situé, plus inquiétant et plus rassurant. Il agrège des communautés autant qu'il divise. Ce \og nouvel-ancien \fg{} référentiel, c'est le sol.}
|
||
\end{quotation}
|
||
|
||
L'idée est alors de supprimer le référentiel Nord-Sud-Est-Ouest par la direction haut-bas. La figure \ref{carte2}, en tant que carte classique inconciliable avec ce qu'on peut espérer d'une information en profondeur des différents aspects d'une mine, puis la figure \ref{carte2}, qui constitue le renversement de perspective tout en restant dans le cadre d'une carte des mouvements du sol, vont permettre d'assumer ce changement \og d'horizon \fg. Mais les auteures ne vont pas en rester là.
|
||
|
||
Le second changement va être de donner à l'atmosphère une finitude graphique éblouissante et aux différentes strates du sol une importance qui ne lui est jamais donnée.
|
||
|
||
\begin{quotation}
|
||
\emph{Le modèle permet de visualiser ces couches en supprimant les échelles et en scannant horizontalement les strates, puis en les replaçant concentriquement autour d'un vide, le rond central, notre atmosphère. Un fossile peut y être aussi visible qu'une mine, un volcan qu'une cuve, un réseau de pipelines que l'eau qui s'écoule entre les roches, car leurs effets en surface sont devenus aussi importants les uns que les autres. [\dots] Le sol, comme une peau retournée, laisse apparaître ce qui se passe directement sous sa surface et le fait vivre, ou mourir. Voilà notre \emph{terra incongnita} : le sol sous nos pieds.} \cite[p. 37]{FA2019}
|
||
\end{quotation}
|
||
|
||
Après une présentation du plan de renversement, les auteures présentent le modèle de la figure \ref{modelesol}, puis la carte elle-même à laquelle la figure \ref{modelecarte}, ne rend que modestement hommage.
|
||
|
||
\bigskip
|
||
En quoi ces deux révolutions sont elles importantes dans le cadre des travaux personnels de la DO d'informatique ?
|
||
|
||
\subsection{Pistes}
|
||
Tout d'abord, on constate que les cartes présentées ne sont certainement pas issues de logiciels de cartographie classiques. Évidemment, puisque leur originalité est de n'être pas fondées sur les \og coordonnées géographiques \fg. La notion de coordonnée n'est donc pas constitutive de celle de carte.
|
||
|
||
Comment ces cartes ont-elle donc été réalisées ?
|
||
|
||
Ce qui manque, on peut presque dire bien heureusement, dans l'ouvrage de \cite{FA2019}, c'est précisément l'informatique nécessaire à leur réalisation. Pourtant, quand on observe attentivement les figures \ref{modelesol} et \ref{cartesol}, on y perçoit incontestablement un logiciel de dessin vectoriel. Et c'est par là que la première révolution cartographique de \cite{FA2019} va permettre le changement de paradigme annoncé :
|
||
|
||
\medskip
|
||
\emph{Il n'est pas nécessaire d'utiliser un logiciel de cartographie pour faire des cartes.}
|
||
|
||
\medskip
|
||
Il ne faut surtout pas sous-estimer l'importance de ce changement de paradigme. Il affirme clairement que la première étape de la réalisation de cartes n'est pas de choisir le logiciel, mais de savoir quel type de carte on veut réaliser. Du point de vue de la géographie même, faire le contraire est une erreur.
|
||
|
||
\medskip
|
||
La seconde révolution cartographique évoquée ci-dessus, soit le retournement de la position de l'atmosphère pour la mettre au centre d'une carte à symétrie sphérique, de par sa radicalité, va permettre d'oser un autre changement complet de la notion de carte. Car, au fond, la question fondamentale qu'il aurait fallu se poser d'entrée est~: qu'est-ce qu'une carte.
|
||
|
||
Clairement, l'ouvrage de \cite{FA2019} répond qu'une carte est un repère dans \og l'activité des vivants elle-même \fg{}. Une carte est donc un repère non au sein d'un territoire, mais d'un mouvant complexe. La limiter au système d'axes d'un repère physique, comme le font la plupart des logiciels de cartographie constitue donc une limitation très dommageable.
|
||
|
||
Et à bien y penser, les expressions \og carte du génome \fg, \og carte du développement embryonnaire \fg, \og carte synoptique \fg{} \dots, montrent la diversité des manières d'établir des repères dans des situations très différentes. Plus même, une cartographie des connaissances sur un sujet, une carte des pages d'un site internet, une carte des descendants d'une famille, une carte d'une grotte \dots, sont réellement autant de véritables cartes et celles-ci nécessitent des outils informatiques très différents, ici respectivement, un wiki, une structure HTML, un logiciel de généalogie et un logiciel 3D.
|
||
|
||
\bigskip
|
||
Ainsi, si nos premières idées pour réaliser des projets sur la base du mensonge des cartes ont été de parcourir les outils informatiques permettant de se focaliser sur un aspect particulier, mais très généralement utilisé, de la cartographie (comme R pour l'associer aux statistiques), il faut maintenant bien reconnaître que des outils moins spécifiques peuvent tout aussi bien répondre à la problématique.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=13cm]{images/inkscape.eps}
|
||
\caption{Inkscape et XML}\label{inkscape}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
Par exemple, Inkscape\footnote{Outil libre de dessin vectoriel. Voir~: \url{https://inkscape.org/fr/}} (voir figure \ref{inkscape}) dans le monde libre ou Illustrator dans le monde propriétaire (même s'il est disponible, il n'est pas recommandé car il n'est ni multi-plateforme, ni libre, ni gratuit), qui sont des logiciels de dessin vectoriels, doivent non seulement être considéré comme parfaitement adapté à des projets de cartographie, mais aussi comme particulièrement intéressants pour des élèves pour lesquels les représentations graphiques sont à priori intéressantes, comme ceux des arts visuels. Ces logiciels sont par ailleurs assez multi-usages pour que tout le monde y trouve son compte. En effet, ils permettent une introduction au dessin vectoriel (logos, schémas ou évidemment cartes de toute nature) avec une gestion très intéressante des calques mais aussi de l'animation vectorielle et sont aussi une entrée dans le monde du codage balisé et des DOM (Document Object Model) qui constituent l'un des aspects des langages XML, dont HTML fait partie.
|
||
|
||
Or, par sa capacité de gestion balisée de l'information et donc de structuration complexe ainsi que par son immense popularité, le trio HTML, CSS et Javascript, est aussi un candidat sérieux à la création de cartes. Y sont disponibles les calques (dont le sous-projet UMAP\footnote{uMap permet de créer des cartes personnalisées sur des fonds OpenStreetMap. Voir~: \url{https://umap.openstreetmap.fr/fr/}} permet une introduction), la gestion de fonds de cartes bitmap et vectorielles, la manipulation de la forme indépendamment du contenu avec CSS, toutes choses qui permettent de comprendre ce que sont des tuiles, des légendes, des échelles, \dots{} tous éléments constitutifs des cartes d'Openstreetmap, ou autre logiciel équivalent. De plus, l'utilisation de logiciels graphiques en mode ligne de commande comme Bluefish\footnote{Éditeur HTML multi-plateforme, libre et gratuit. Voir~: \url{http://bluefish.openoffice.nl/index.html}} ou autre pour en apprendre le codage étant très bien acceptée et permettant simultanément d'introduire les élèves au outils du web, il serait dommage de ne pas en envisager l'utilisation, même partielle, sous prétexte d'outils généralistes qui n'ont pas été spécifiquement prévu pour la cartographie.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=12cm]{images/peters.eps}
|
||
\caption{Projection de Peters de Médecins sans frontières}\label{peters}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
Un autre exemple, vient de l'utilisation de plus en plus fréquente de l'espace au lieu du plan.
|
||
|
||
À la cartographie traditionnelle est attachée la notion de projection et donc à des formes mathématiques certainement intéressantes puisque trompeuses, mais certainement aussi assez complexes pour ne pouvoir être utilisées avec tous les élèves. L'exemple bien connu est la projection de Peters que présente \cite[pp. 159-160]{MM2019} et encore utilisée aujourd'hui par Médecins sans frontières (voir figure \ref{peters}).
|
||
|
||
Les systèmes de projection sont sans conteste un facteur de mensonge. Cela est connu depuis longtemps puisque~:
|
||
\begin{quotation}\label{reclus}
|
||
\emph{Élisée Reclus (1830-1905), un des pionniers de la géographie moderne, était très critique envers les cartes qui, par construction, déforment la réalité. Selon lui, les cartes planes, projetées, ne pouvaient qu'induire les élèves en erreur en leur inculquant une fausse représentation du monde. En plus de militer pour leur interdiction dans les salles de classe, il se lança dans le projet fou de construire un globe de plus de 127,5 mètres de diamètre pour l'exposition universelle de 1900. Trop coûteux, ce globe qui était selon lui le seul moyen de représenter fidèlement la terre, ne sera finalement jamais construit.} \cite[p. 36]{NL2017}
|
||
\end{quotation}
|
||
|
||
Aujourd'hui, l'une des réponses à ce problème est celle de l'utilisation de logiciels 3D. Or, ceux-ci sont aujourd'hui disponibles facilement. Le plus connu, multi-plateforme, libre et gratuit est Blender.
|
||
|
||
Sous condition de l'utilisation de machines d'une puissance raisonnable, il est tout-à-fait envisageable de réaliser des cartes 3D grâce à lui, comme des cartes de grottes, des cartes d'étoiles, de circuits électroniques, de villes, à l'instar de cartes comme celles de l'intérieur des pyramides, sans toutefois passer par une muographie\footnote{Voir~: \url{http://www.laradioactivite.com/site/pages/Muographie_Pyramides.htm}}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=12cm]{images/sweetHome3D.eps}
|
||
\caption{Sweet Home 3D}\label{sweethome3d}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
De la même manière, pour la représentation des bâtiments, des logiciels d'architecture, comme le logiciel multi-plateforme libre et gratuit Sweet Home 3D (voir figure \ref{sweethome3d}), existent. Les utiliser en tant que producteurs de cartes 3D est parfaitement envisageable. Avec Sweet Home 3D, il est alors possible de s'initier à la modélisation 3D, à l'instar de Blender, pour la construction de meubles ou autres objets.
|
||
|
||
\subsection{Les logiciels de desssin assisté par ordinateur (DAO)}
|
||
Ces derniers ne permettent pas un traitement statistique de l‘information mais sont très efficaces au niveau du dessin. Selon Didier Poidevin \cite{PD}, ils sont notamment très utiles dans les cas suivants~:
|
||
\begin{itemize}
|
||
\item lorsque le cartographe privilégie le travail graphique, voire artistique pour sa carte,
|
||
\item lorsque le cartographe veut retoucher les cartes produites avec un logiciel de cartographie ou
|
||
\item Lorsque le cartographe conçoit sa carte manuellement.
|
||
\end{itemize}
|
||
|
||
\subsection{Créer des cartes-modèles avec le DAO}
|
||
Les cartes modèles et la chorématique ont été présentées dans les années 1980 par une équipe de chercheurs français. Ce type de carte, que nous présentons ci-dessous, pourraient à notre avis convenir pour la réalisation d’un projet cartographique orienté sur l’utilisation du DAO.
|
||
|
||
La carte-modèle est notamment proposée parle géographie Roger Brunet. Elle consiste à utiliser la notion de modèle pour créer des cartes. Ce modèle de carte utilise ce que Brunet appelle des chorèmes qu’il définit comme des \og structure élémentaire de l’espace qui se représente par un modèle graphique \fg{} \cite{BR86}.
|
||
|
||
Le travail proposé consiste à tenter de modéliser un espace, ce qui n’est pas, pour Brunet, une opération qui se contenterait de résumer ou de généraliser et encore moins de caricaturer. Il s’agit plutôt de montrer quels sont les principes en jeu dans l’espace étudié. En ce sens, elle est différente d’une carte classique qui cherche à être le reflet précis de la réalité car la carte-modèle ne respectera plus les coordonnées géographiques des lieux, les contours des circonscriptions et États ou les linéaments (routes, cours d’eau,...). \cite{DDF92} définit ainsi la carte modèle : \og représentation schématique de la réalité élaborée en vue de l’expliquer, ou encore de la comprendre au faire comprendre \fg.
|
||
|
||
Brunet ajoute que toutes les configurations spatiales sont la combinaison de mécanismes simples qui correspondent aux solutions que les sociétés trouvent pour maîtriser l’espace et aux forces physiques qu’elles doivent maîtriser (pente, climat, etc.).
|
||
|
||
Ces configurations se comprennent par le jeu des structures élémentaires évoquées ci-dessus. Graphiquement elles sont toutes constituées de points, lignes et surfaces, comme toutes les représentations cartographiques. Au total, Brunet propose 28 chorèmes pour créer ses cartes-modèles. Chacun d’eux signifie car il est signe (avec une forme) et propose un signifié (le mécanisme qu’on cherche à représenter). Brunet précise à ce sujet que « le langage de la carte est dans la forme, l’arrangement et la signification des distributions qu’elle montre. Les formes élémentaires sont les sèmes de ce langage, la syntaxe est dans leurs relations ». Les chorèmes peuvent exprimer des choses très différentes, parfois totalement abstraites comme l’aire d’influence d’une ville, ou très concrètes comme une frontière.
|
||
|
||
Les chorèmes (voir figure \ref{choremes}) sont classés en sept catégories \cite{BR87} :
|
||
\begin{itemize}
|
||
\item les chorèmes de maillage (pour l’attribution des territoires) ;
|
||
\item les chorèmes de quadrillage (pour la desserte des territoires) ;
|
||
\item les chorèmes de contact (pour signifier les lieux de rupture ou d’osmose) ;
|
||
\item les chorèmes de gravité (pour signifier les attractions, les influences) ;
|
||
\item les chorèmes directionnels (pour montrer les dissymétries par exemple) ;
|
||
\item les chorèmes de mouvement (pour traduire les conquêtes ou replis) ;
|
||
\item les chorèmes de hiérarchies.
|
||
\end{itemize}
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=9cm]{images/Choremes.eps}
|
||
\caption[Chorèmes]{Structures élémentaires de l’espace ou socle de la chorématique}\label{choremes}
|
||
\end{figure}
|
||
|
||
Cette modélisation s’applique à toutes les échelles du territoire. On peut très bien évoquer avec elle la distribution spatiale d’un phénomène particulier ou l’organisation spatiale particulière d’une ville par exemple.
|
||
|
||
Selon \cite{BR87}, il existe trois catégories de carte-modèle~:
|
||
\begin{itemize}
|
||
\item la carte-modèle générale qui rend compte d’une forme d’organisation particulière, répétée à la surface du monde (exemple : la carte-modèle de la ville arabe),
|
||
\item la carte modèle d’un espace particulier, peu importe son échelle (exemple : La Pologne) et
|
||
\item la carte-modèle d’un phénomène particulier (exemple : les migrations européennes au XXI\ieme{} siècle).
|
||
\end{itemize}
|
||
|
||
Brunet présente les étapes de réalisation d’un modèle comme suit~:
|
||
\begin{enumerate}
|
||
\item On choisit une surface de travail. Le plus généralement un cercle, parfois un carré ou un hexagone. Les autres formes sont plus complexes à utiliser car elles induisent immédiatement des biais.
|
||
\item On recherche les principes de base du fonctionnement de l’espace qui sont en jeu. Cette étape nécessite l’étude de l’espace que l’on souhaite représenter, notamment avec la documentation cartographique à disposition. On traduit ensuite les principes repérés avec des chorèmes pour obtenir une représentation suffisante de la réalité. Il faut aller ici à l’essentiel.
|
||
\end{enumerate}
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=9cm]{images/Pologne.eps}
|
||
\caption[Pologne]{Exemple de la Pologne}\label{pologne}
|
||
\end{figure}
|
||
|
||
Toute la difficulté des cartes-modèles consiste à modéliser l’espace et utiliser les chorèmes les mieux adaptés aux distributions observées.
|
||
|
||
En conclusion de l’article paru dans la revue \og Mappemonde \fg{} Brunet dit ceci à propos de ses modèles cartographiques : \og La carte-modèle n’est évidemment pas une nouvelle panacée. Elle est un instrument de plus de l’analyse géographique, qui commence à prouver son efficacité. Outil de recherche et de communication, elle aide à entendre le langage même de la carte. Il n’y faut que du sérieux, et de l’imagination \fg{} \cite{BR86}.
|
||
|
||
\medskip
|
||
En tous les cas, dans le cadre de la 2\ieme{} année de la DO informatique, la possibilité de créer un projet \og carte-modèle \fg{} nous paraît riche en perspective, notamment pour les étudiants qui souhaiteraient s’éloigner d’une cartographie par trop quantitative. Ce type de projet comme nous l’avons relevé ci-dessus nécessiterait l’utilisation de logiciels de dessin pour créer les chorèmes et réaliser les cartes.
|
||
|
||
\subsection{Les anamorphoses cartographiques (ou cartogrammes)}
|
||
Un autre type de cartes s’éloigne aussi des repères classiques qu’on leur attribue habituellement. Il s’agit des anamorphoses cartographiques qu’on nomme aussi parfois cartogrammes. L’idée est ici de produire des cartes qui s’affranchissent des contraintes des distances réelles et de la réalité du fond de carte. On ignore la réalité des coordonnées géographiques, de même que celles des contours des espaces.
|
||
|
||
Selon le dictionnaire de géographie \og Les mots de la géographie \fg{} \cite{BR93} : \og L’anamorphose classique est une représentation des États (ou de mailles quelconques) par des rectangles ou des polygones quelconques en fonction d’une quantité qui leur est rattaché \fg.
|
||
|
||
\subsubsection*{La déformation des distances}
|
||
La proposition consiste à représenter des distances non plus kilométriques par exemple, mais des distances perçues, des distances-temps ou des distances-coûts. Ces cartes déforment les distances pour mieux les représenter \cite{BR87}. De ce fait, les lieux peuvent changer de place, se rapprocher ou s’éloigner.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=11cm]{images/Zelande.eps}
|
||
\caption[Nouvelle-Zélande]{La Nouvelle-Zélande se rétrécit}\label{zelande}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
Sur la figure \ref{zelande}, on peut voir trois cartes dont l’échelle est le temps de trajet aérien. On voit qu’entre 1947 et 1970, l’espace national s’est rétréci avec le développement du transport aérien.
|
||
|
||
\subsubsection*{La déformation des fonds de carte}
|
||
Dans ce cas, \og l’idée de base est d’attribuer aux portions d’espace une superficie sur le papier qui soit proportionnelle à une autre donnée \fg{} \cite{BR87}. Il s’agit de rendre proportionnel par exemple un État à une des données qui lui sont liées, par exemple le produit intérieur brut. Ainsi on aperçoit les masses différemment.
|
||
|
||
Les espaces peuvent par exemple être préalablement schématisés par des polygones plus ou moins simples, arrangés de telle manière qu’ils rappellent les contours des continents, comme dans l’exemple de la figure \ref{pib}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=14cm]{images/pib.eps}
|
||
\caption[Pib/État]{Anamorphose Pib/État en 2011}\label{pib}
|
||
\end{figure}
|
||
|
||
Il existe d’autres procédés pour déformer le fond de carte. L’un d’entre eux \og consiste à déformer de proche en proche une grille régulière correspondant à la surface de départ en affectant à chaque unité spatiale la valeur qui lui revient \fg{} \cite{BR93}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=14cm]{images/Nobel.eps}
|
||
\caption[Nobel]{Anamorphose - le nombre de prix Nobel par État entre 1901 et 2018}\label{nobel}
|
||
\end{figure}
|
||
|
||
Plusieurs logiciels permettent la création d’anamorphoses cartographiques. Nicolas Lambert, à la fin d’une présentation très complète\footnote{Voir : \url{https://neocarto.hypotheses.org/files/2013/11/Anamorphosis_M2_2013-14.pdf}} présente un grand nombre de logiciels susceptibles d’être utilisés pour la réalisation de ce type de cartes, dont QGis que nous avons déjà évoqué. Cependant, sa préférence semble aller au logiciel Scapetoad (voir figure \ref{scapetoad}, page \pageref{scapetoad}) qu’il décrit comme \og meilleur logiciel, performant, efficace \fg. Il est multi-plateforme, gratuit et libre (licence GPL), et a été développé par le laboratoire CHOROS de l’EPFL. On le trouvera à l’adresse suivante : \url{http://scapetoad.choros.place/download.php} et un tutoriel présentant la réalisation d’un cartogramme à l’aide de Scapetoad ici : \url{https://www.fbotutos.com/creer-des-cartogrammes-avec-scapetoad.html}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=12cm]{images/Scapetoad.eps}
|
||
\caption[Scapetoad]{Le logiciel Scapetoad}\label{scapetoad}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
Ce type de logiciel offre beaucoup de perspectives et permet une cartographie originale qui pourrait plaire aux élèves. Cependant une évaluation plus approfondie de la prise en main du logiciel est nécessaire avant d’envisager son utilisation en classe.
|
||
|
||
\section{Pédagogie}
|
||
Il existe quelques étapes importantes dans la construction des projets.
|
||
|
||
Il vaut mieux, nous semble-t-il, imposer le thème. Le choisir avec les élèves empêcherait en effet certainement les enseignants d'avoir une réflexion du type de celle présentée ici, du moins dans des délais raisonnables, alors qu'autrement il est possible d'y réfléchir préalablement.
|
||
|
||
Par contre, il nous semble aussi important de permettre aux élèves de choisir eux-même le sujet de leur travail personnel, dans le cadre du thème s'entend. L'originalité des travaux réalisés est pour nous le gage de l'évocation nécessaire des nombreux problèmes liés tant à l'informatique qu'à la discipline associée aux projets.
|
||
|
||
Pour cela, il est nécessaire de présenter préalablement quelques pistes de réalisations dans la discipline, indépendamment de son approche informatique. Il s'agit ici de l'approche en terme de services, évoquées ci-dessus.
|
||
|
||
\medskip
|
||
Dans le cadre de projets sous le thème de \og Faire mentir les cartes \fg{}, les pistes évoquées ci-dessus peuvent servir de point de départ. L'essentiel est de rester extrêmement ouvert sur la notion de cartes\footnote{\og \emph{La cartographie radicale\\Loin du giron des experts et des universitaires, existe une cartographie insolite. Mélange d'art, de science et d'activisme social, cette cartographie est le domaine des artistes, des architectes et des géographes engagés. Cartographie radicale, critique, contestataire, militante, hétérodoxe, ou citoyenne, elle porte de nombreux noms. Mais ce qui la caractérise avant tout est l'idée centrale que le citoyen doit se réapproprier le pouvoir des cartes~! Pour ces cartographes, l'heure est venue de remplacer la propagande officielle par la protestation. Révéler des structures invisibles de l'ordre dominant et utiliser la carte pour les dénoncer. C'est une cartographie qui vise à ébranler les structures de pouvoir et de domination.\\Dans cette contre-cartographie, les règles de la sémiologie graphique on finalement peu d'importance. Ce qui compte, c'est l'expression artistique et la portée symbolique de la carte. Les représentations peuvent être iconoclastes ou se référer strictement aux règles de la sémiologie graphique. Le but n'est pas là. La cartographie radicale est une forme d'expression libre où seule compte la force du message. Car bien plus qu'un façon particulière de dessiner des cartes, cette cartographie critique se reconnaît avant tout à sa finalité. La carte radicale n'est jamais une fin en soi. Elle sert de point d'appui, d'argument, pour l'action concrète. Elle joue le rôle d'alerte ou de déclencheur pour mener une action politique, une action de terrain ou porter des revendications. C'est une cartographie de combat au service des dominés, c'est un outil de contestation et de reconquête d'un pouvoir confisqué.} \fg{} \cite[p. 197]{NL2017}}.
|
||
|
||
Cela permet ensuite, après une définition des propriétés nécessaires pour la réalisation de chaque projet, de rechercher et de choisir un ou plusieurs logiciels permettant de le réaliser au mieux. Cette étape est très importante et peut permettre une discussion étroite sur la nécessité et les possibilités techniques des logiciels, ainsi que sur leurs coûts et licences et permettre une évaluation préalable de leurs limites. Dans le cadre d'un projet sous le thème du mensonge des cartes, par exemple, il peut mener à une analyse du mensonge inhérent ou non aux fonctionnalités logicielles elles-même. Le rôle de l'informatique dans les disciplines peut par là être interrogé en relation avec sa nécessité.
|
||
|
||
Passé l'étape de l'adéquation du choix des outils logiciels, une importante période d'autoformation et de réalisation des projets doit impérativement prendre place. Cela peut constituer une difficulté pour les enseignants qui estiment devoir avoir des connaissances préalables plus importantes que leurs élèves dans tous les cas. Nous pensons quant à nous qu'il est tout-à-fait possible d'apprendre à utiliser un logiciel parallèlement au travail des étudiants, pour autant que ce travail d'autoformation fait par les élèves soit reconnu par les enseignants et valorisé dans leurs évaluations.
|
||
|
||
Parallèlement, mais probablement pas immédiatement, la définition de la forme et des moyens informatiques pour réaliser le compte rendu écrit et oral de chaque projet, doit être faite selon les cas en collaboration ou pas avec les élèves.
|
||
|
||
Dans le cas de la cartographie, divers traitements de texte, tels LibreOffice (multi-plateforme, libre et gratuit), \LaTeX{} (multi-plateforme, libre et gratuit) ou autres peuvent être utilisés. Pour la présentation orale, des dias peuvent être réalisés avec Libre Office ou \LaTeX{} et présenté à l'aide du logiciel lui-même ou en PDF. Pour \LaTeX, le package Beamer est particulièrement adéquat. Reste qu'il ne semble pas nécessaire de réaliser à tout prix une présentation de ce type quand, oralement, on peut tout aussi bien rendre compte de son travail en présentant directement les outils utilisés pour le réaliser.
|
||
|
||
\medskip
|
||
En ce qui concerne les objectifs, il nous semble préférable d'être très modeste, mais de permettre une grande variété d'approches. Dans un premier temps, cela peut permettre aux enseignants d'acquérir l'expérience nécessaire pour envisager par la suite des projets plus pointus. Mais, de manière générale, il nous semble qu'il vaut mieux une réalisation lacunaire, mais permettant une compréhension générale de plusieurs aspects de la discipline et de sa relation avec l'informatique, plutôt que des réalisations dirigées menant à des capacités d'utilisation fortes, mais peu étendues.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=8cm]{images/autoportraitClassique.eps}
|
||
\caption{Autoportrait classique}\label{autoportraitclassique}
|
||
\end{figure}
|
||
|
||
Là encore, l'utilisation de logiciels spécifiques à la cartographie peut être un réel frein à la compréhension de ceux-ci, car expliquer le fonctionnement en couches de QGIS et réaliser un petit projet en HTML permettant de faire varier les représentations cartographiques par l'action de la molette, sont deux choses très différentes, dont la seconde est incontestablement plus fructueuse pour comprendre les ressorts informatiques des logiciels dynamiques de cartographie.
|
||
|
||
\subsection{Exemple}
|
||
Pour finir et montrer à quel point la cartographie peut aborder des aspects très différents de l'idée d'une carte telle qu'on la conçoit généralement, voyons ce qu'on pourrait faire comme projet très atypique dans le cadre des cartes qui mentent. Il s'agit de tenter l'autoportrait cartographique de l'un des auteurs du présent texte : Vincent Guyot.
|
||
|
||
Comme il s'agit d'un travail personnel, c'est lui qui va en rendre compte, d'où le changement de sujet.
|
||
|
||
\medskip
|
||
Les objectifs sont :
|
||
\begin{enumerate}
|
||
\item de réaliser un autoportrait,
|
||
\item spécifiquement axé sur de la cartographie,
|
||
\item en utilisant des aspects mensongers de celle-ci et
|
||
\item en rendant compte du travail d'une manière informatique.
|
||
\end{enumerate}
|
||
|
||
Le portrait envisagé est celui d'un hacker et fait suite à un autre autoportrait plus classique réalisé précédemment dans le cadre d'un atelier interdisciplinaire. Celui-ci est présenté à la figure \ref{autoportraitclassique}, page \pageref{autoportraitclassique}. Il a été documenté dans un texte qui ne sera pas reproduit ici, mais qui a été donné en exemple de ce qui pourrait être fait comme compte rendu d'un travail interdisciplinaire.
|
||
|
||
Le cadre général du travail a été choisi en fonction de l'histoire de la personne. Celle-ci ayant déjà mené à un autoportrait, le cadre sera le même :
|
||
\begin{itemize}
|
||
\item les dimensions d'une feuille A4,
|
||
\item réalisé en \LaTeX{} et plus précisément en Tikz pour les aspects graphiques.
|
||
\end{itemize}
|
||
Le second point est un élément constitutif de l'autoportrait et a précédemment permis d'atteindre le quatrième point des objectifs. Dans le présent travail, celui-ci sera atteint différemment.
|
||
|
||
\medskip
|
||
Le c\oe ur du travail est la représentation géographique. Or, le travail présenté par \cite{FA2019} est non seulement remarquable, mais aussi fécond. Les idées de cartographie du sol et de ses mouvements que les figures \ref{carte1} et \ref{cartesol} traduisent m'ont fait penser au géoïde de la Terre (voir la figure \ref{geoid}).
|
||
|
||
Cet objet fantastique est une carte des déformations de la surface terrestre dues aux variations de la gravité locale. La représentation qui en est faite est à la fois exacte et évidemment mensongère : les déformations sont réelles mais amplifiées pour mieux les voir. Ce géoïde, par le phénomène qui le produit, est le constat de modifications locales de la pesanteur, c'est-à-dire du poids, de différentes parties de la Terre. Il constitue ainsi le premier élément de mon autoportrait, puisque j'ai vécu dans ma vie de telles variations, certes microscopiques à l'échelle de la terre (environ 200 N), mais amplifiées à la surface de mon corps.
|
||
|
||
Ce géoïde représente la Terre comme une sphère bosselée. Il s'agit de partir d'un ellipsoïde représentant notre planète en rotation et d'y définir une surface de gravité équipotentielle au niveau moyen des océans. Les différences de gravités dues par exemple à des chaînes de montagnes sont ainsi traduites en différences d'altitudes par rapport à l'ellipsoïde.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/Geoids_sm.eps}
|
||
\caption{Le geoïde}\label{geoid}
|
||
\end{figure}
|
||
|
||
Le principal travail à réaliser est donc d'obtenir ce géoïde. La solution de facilité est d'en récupérer une image sur le net. Or, la plupart d'entre elles sont copyrightées. Mon autoportrait ne pouvant se satisfaire d'une licence propriétaire, il est nécessaire d'obtenir moi-même le géoïde (malgré l'existence d'une version sur wikipedia\footnote{Voir~: \url{https://fr.wikipedia.org/wiki/Fichier:Modell.Potsdamer.Kartoffel.jpg}} sans utiliser celle de la NASA\footnote{Voir~: \url{https://commons.wikimedia.org/wiki/File:Geoids_sm.jpg}} (voir figure \ref{geoid}), qui est dans le domaine public).
|
||
|
||
\smallskip
|
||
Cela permet de mentionner un point dont il n'a pas encore été question ici. Il s'agit de l'attention à porter aux copyright des objets (surtout les fonds de cartes, comme l'a dit \cite[p. 4]{FA2019} : \og [QGIS] dont les données sont souvent sécurisées \fg{}, les données elles-même, comme celles des altitudes du géoïde, mais aussi les éventuelles cartes du compte-rendu). Car, ceux-ci ne sont pas souvent libres de droit et en conséquence il faut parfois renoncer à l'utilisation de données pour cette raison. Même si \cite[p. 4]{FA2019} dit que l'accès aux données cartographiques est aujourd'hui grandement facilité par l'Open Data, la cartographie reste un domaine où il faut rester très attentif à la provenance des données et où, même celles qui sont financées par l'impôt ne sont pas dans le domaine public.
|
||
|
||
\smallskip
|
||
Pour obtenir ce géoïde, trois choses ont été nécessaires : des données libres de droits (la NASA en est le principal fournisseur, mais l'ESA, l'agence spatiale européenne, en fournit aussi), un logiciel permettant d'y avoir un accès simplifié (il s'agit ici de la version python de geographiclib, qui est une librairie libre) et un logiciel de rendu 3D (pour le modelage et la texture, Blender est le meilleur logiciel libre correspondant).
|
||
|
||
\medskip
|
||
Évidemment, l'utilisation de Blender n'est pas simple. En réalité, elle s'apparente à celle de R ou de QGIS et il est intéressant de noter que pour obtenir le géoïde désiré, il a fallu non seulement se familiariser avec Blender, mais aussi trouver l'information nécessaire à la réalisation de l'objectif choisi : disposer d'un géoïde 3D. Pour des logiciels spécialisés comme ceux-ci, une phase de formation est absolument nécessaire, qu'on soit informaticien ou pas.
|
||
|
||
\smallskip
|
||
Par ailleurs, avec de tels logiciels, la légitimité d'une approche utilisatrice de l'informatique ne fait plus aucun doute. En effet, comme nous le verrons par la suite, avec Blender par exemple, il est impossible de s'en sortir sans aborder des notions éminemment informatiques telles que le maillage, le traitement des surfaces, le rendu, etc.
|
||
|
||
Enfin, il est aussi important de comprendre que l'expérience technique nécessaire dans l'utilisation de tels logiciels pour des enseignants n'est pas supérieure au saut demandé à des élèves débutants en informatique dans l'acquisition de notions de langages descriptifs tels que HTML ou CSS. Il s'agit donc bien soit de comprendre que des élèves débutants aient de réelles difficultés dans l'utilisation de logiciels comme R, QGIS ou Blender et d'adapter les exigences en conséquence ou de n'orienter que les élèves disposant déjà d'un bon bagage informatique sur leur utilisation. Avoir conscience de cela disqualifie dans une certaine mesure le fait d'imposer des projets uniquement axé sur l'utilisation d'un seul et unique logiciel. Il s'agit là d'une approche pédagogique axée sur l'adaptation des exigences en fonction du parcours des élèves. L'importance des disparités en termes de connaissances informatiques au sein des classes risquant d'être très élevée, c'est une approche qui semble raisonnable pour satisfaire l'intérêt de tous.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=10cm]{images/geoidcard.eps}
|
||
\caption{La carte du geoïde\\Gravity field and Ocean Circulation Explorer (GOCE)}\label{cartegeoidecouleurs}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
L'exemple de la création d'un géoïde sous Blender est très instructive pour la compréhension de la modélisation 3D, mais aussi quant à l'utilisation des données. Si la librairie évoquée ci-dessus (geographiclib) permet bien d'obtenir les hauteurs nécessaires à la création du géoïde, le problème de leur utilisation dans Blender s'est évidemment immédiatement posé. La question était comment faire comprendre ces données au logiciel.
|
||
|
||
Après beaucoup de recherches, il se trouve que le moyen le plus pratique n'est pas d'utiliser un fichier de données brutes, mais précisément une carte colorimétrique des hauteurs du géoîde comme présentée à la figure \ref{cartegeoidecouleurs}\footnote{Voir~: \url{https://earth.esa.int/web/guest/missions/esa-operational-eo-missions/goce}}. En effet, la modélisation 3D utilise deux structures typiques (entre autres) qui sont le maillage 3D et la texture. Les deux manières de faire interagir ces deux éléments sont le \emph{bump}, qui consiste en une texture 3D qu'on place sur l'objet, et le \emph{displacement}, qui consiste en la déformation de l'objet lui-même. Or, ces deux interactions sont chacune intéressantes du point de vue de la cartographie, car la première utilise un matériau 3D de couverture de l'objet, matériau construit en 3D à partir de la carte colorimétrique, alors que la seconde déforme l'objet lui-même, toujours selon la carte colorimétrique. Dans le premier cas, évidemment, la superposition peut se faire de plusieurs manières et implique l'ellipsoïde de référence sur lequel est construit le géoïde. Dans le second cas, c'est réellement la structure de l'objet entier qui est affectée et on a là une approche bien plus physique, moins cartographique de la représentation, mais peut-être moins mensongère selon Élisée Reclus (voir la citation page \pageref{reclus}).
|
||
|
||
Informatiquement parlant, ces deux méthodes ne sont pas équivalentes, puisque le placement d'un matériau (même 3D) sur une surface demande bien moins de ressources que la déformation d'un objet. La notion de maillage intervient ici de manière \dots{} constructive.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=14cm]{images/terre1erTop.eps}
|
||
\caption[BlenderGeoid]{Le geoïde avec Blender}\label{terre1erTop}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
Après bien des essais, le premier résultat acceptable fut celui présenté à la figure \ref{terre1erTop}. Il a été obtenu par displacement et n'est pas acceptable du point de vue de l'éclairage.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=14cm]{images/TerreIndeBlender.eps}
|
||
\caption[BlenderGeoid]{Le geoïde \og indien \fg{} avec Blender}\label{TerreIndeBlender}
|
||
\end{figure}
|
||
|
||
L'utilisation de Blender permet un grand nombre de réglages et sa pratique va évidemment améliorer le résultat. Vous pouvez voir à la figure \ref{TerreIndeBlender} le géoïde qui va servir pour l'autoportrait cartographique. Il est critiquable sur bien des aspects. Notamment, il a été réalisé à partir d'une carte dont la projection sur la sphère n'est pas vraiment maîtrisée. La rotation 3D de celle-ci fait en effet apparaître une jointure bord à bord de l'image et resurgit ici le problème de la projection d'une carte plane sur une sphère et cela de manière très intéressante puisque Blender tente littéralement de la \emph{coller} sur la sphère en la déformant au mieux. Pour obtenir un résultat plus correct, il devient donc nécessaire de s'intéresser au méthodes de projections de ce logiciel. Celles-ci sont-elles comparables à celles utilisées en cartographie, en existe-il différents types, comment sont-elles paramétrables, autant de question qui interrogeront la cartographie informatique.
|
||
|
||
C'est ici aussi qu'apparaît un point clé de la modélisation informatique. En effet, c'est d'abord l'objectif de l'autoportrait informatique qui va s'imposer dans l'utilisation de Blender, car le rendu obtenu est déjà satisfaisant de ce point de vue, même s'il ne l'est pas totalement géographiquement parlant. Bien qu'on puisse en discuter. Car, il constitue indéniablement une carte porteuse d'informations tout en étant trompeuse et, pour prendre conscience de l'existence d'un géoïde, et même de certaines de ses propriétés, celle-ci est certainement suffisante.
|
||
|
||
\medskip
|
||
Restait à mettre en place les autres éléments de cet autoportrait cartographique. Il s'agissait de quatre éléments différents~:
|
||
\begin{itemize}
|
||
\item une déformation du géoïde pour s'adapter à l'image sous-jascente,
|
||
\item un astrolabe déformé pour s'adapter à la capuche,
|
||
\item un élément de géodésie présentant un aspect de la relativité générale et
|
||
\item une lentille gravitationnelle.
|
||
\end{itemize}
|
||
|
||
Les raisons du choix de ces éléments sont multiples. Dans les trois cas, un rapport à la cartographie existe. Il s'agit cependant de cartographie céleste. Ces éléments sont aussi consubstantiels de l'autoportrait et sont particulièrement mensongers.
|
||
\begin{itemize}
|
||
\item Le géoïde a non seulement mal été appliqué sur la sphère terrestre, qui devrait par ailleurs être un ellipsoïde, mais il a été déformé pour s'adapter à une partie de l'astrolabe sousjascent. Les mensonges sont donc particulièrement présents.
|
||
\item L'astrolabe constitue une véritable carte du ciel dont la fonction peut paraître être le repérage céleste, mais se trouve en réalité donner la mesure de l'heure. La construction d'un tel astrolabe nécessite évidemment une grande maîtrise de la cartographie céleste et de son mouvement horaire mais aussi de différentes techniques de gravure et fut l'objet d'une réelle passion de l'auteur de l'autoportrait, autant pour l'objet que pour les connaissances historiques qu'il représente. Enfin, cet astrolabe a aussi été déformé en raison d'une parallaxe de l'image initiale\footnote{Voir~: \url{https://commons.wikimedia.org/wiki/File:Astrolabe-Persian-18C.jpg}}, mais aussi pour s'adapter à la capuche.
|
||
\item La théorie de la relativité est au c\oe ur de la passion pour la physique de l'auteur. La structure de l'espace lui-même et les problèmes cartographiques qui s'y posent sont similaires à ceux que posent la cartographie terrestre. De plus, la déformation de l'espace liée aux masses évoque les déformations présentées sur le géoïde. L'intégration de cette structure\footnote{Voir~: \url{https://commons.wikimedia.org/wiki/File:Geodesiques.svg}} entre le géoïde et l'astrolabe prend donc tout son sens.
|
||
\item Enfin, un effet de lentille gravitationnelle sur fond de Voie Lactée a été intégré au bas de l'image, autant pour des raisons graphiques que pour le mensonge que représente cet effet qui, tout en n'étant pas une carte, est à l'origine d'une interrogation sur l'idée même de cartographie céleste. En effet, c'est dans le cadre de la cartographie du ciel profond, composé de parties de galaxies fantômes créées par de telles lentilles, que les déformations de l'espace sont apparues problématiques. Et en fin de compte, bien avant le mensonge cartographique, n'est-ce pas la lentille de notre \oe uil qu'il faudrait interroger au sujet des altérations de représentations dont elle peut être à l'origine ?
|
||
\end{itemize}
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=8cm]{images/MaCapuche5.eps}
|
||
\caption[AutoPortraitFinal]{L'autoportrait final}\label{autoportraitfinal}
|
||
\end{figure}
|
||
|
||
Voici donc sur la figure \ref{autoportraitfinal} l'autoportrait final que vous pouvez comparer à la figure \ref{autoportraitclassique}, page \pageref{autoportraitclassique}, pour y voir les éléments qui ont disparu et qui, cependant, constituaient certainement une carte mentale de son auteur.
|
||
|
||
\section{Conclusion}
|
||
Ce travail est à notre avis un bon exemple des recherches préalables nécessaires pour être à l'aise avec des élèves à orienter et suivre dans le cadre d'un projet de DO informatique en cartographie. Cela pour plusieurs raisons.
|
||
|
||
Rappelons d'abord qu'on parle d'un projet et non d'un exercice ou d'une série d'exercices. Un projet est bien un exercice, mais il est d'une autre nature en ce sens que l'enseignant n'a pas à le prévoir entièrement, que celui-ci a plus a accompagner le travail qu'à vérifier sa bonne réalisation et que ce dernier est plus une évolution que la réalisation d'un but. Ainsi, il est parfaitement concevable qu'un outil informatique nécessite un apprentissage non négligeable pour obtenir un résultat relativement modeste. Il est nécessaire de bien le comprendre, car cela illustre le fait que l'apprentissage de l'utilisation d'un logiciel (comme R ou \LaTeX{} par exemples) est une composante informatique tout aussi importante que sa programmation. Par ailleurs, des aspects comme le choix d'un logiciel pertinent (du point du vue de sa disponibilité en fonction du système d'exploitation, en fonction de ses engagements en terme de liberté, de sécurité et de respect de ses utilisateurs et évidemment en fonction de ses coûts immédiats et futurs) ou son évaluation préalable, font partie de la réalisation et doivent être pris en compte dans un projet, alors qu'ils peuvent ne pas l'être lors d'un exercice. Ainsi, la liberté nécessaire à un véritable projet doit-elle être garantie. Pour cela, le travail réalisé ci-dessus montre qu'envisager un sujet en le focalisant sur l'utilisation d'un unique logiciel n'est pas une bonne idée.
|
||
|
||
Ce travail insiste donc sur l'importance des recherches préalables à la réalisation d'un projet dans le sens rappelé ci-dessus. Les connaissances nécessaires à son engagement et son suivi doivent être, si ce n'est acquises par les enseignants, du moins envisagées préalablement afin d'orienter au mieux les élèves. Or, clairement ces connaissances peuvent dépasser celles des deux enseignants, autant parce que l'informatique est généralement très peu intégrée dans les disciplines classiques, que parce que l'informaticien d'aujourd'hui est poussé à ne pas s'intéresser aux autres branches. Il est donc nécessaire de garder une grande ouverture d'esprit autant théorique\footnote{\og \emph{Vous qui êtes doté du pouvoir démiurgique de construire des cartes, prenez part à ce débat. Les cartes ne sont pas des illustrations destinées à agrémenter tel ou tel texte. Elles ne sont pas là pour faire joli. Elles dessinent des arguments. Elles peuvent influencer, alerter, inciter à agir. Alors à vos ordinateurs, à vos crayons, à vos tablettes graphiques, la guerre des cartes est délarée. Créez de l'altérité, polémiquez, contestez, dessinez votre propre vision du monde. Bref, faites des cartes qui font bouger les lignes et menez le combat cartographique} \fg{} \cite[p. 196]{NL2017}} que technique, car \og la cartographie est un sport de combat \fg{} \cite[p. 196]{NL2017} qui impose une diversité de regards et une plasticité des solutions qui les rendent possibles.
|
||
|
||
Reste qu'on peut se demander dans quelle mesure l'investissement doit être fait. Surtout au niveau technique. Car ce type de travail exigeant une souplesse technique certaine, on peut interroger la rigidité des exigences des services techniques qui imposent généralement de prévoir bien à l'avance les logiciels nécessaires aux projets. Cela pousse à un gros travail préalable de réflexion extrêmement difficile à réaliser si on admet des projets très divers. De ce point de vue, une indépendance d'installation de logiciels devrait être donnée aux enseignants pour leur permettre de mieux s'adapter aux différentes situations. Cela n'est clairement pas l'orientation envisagée aujourd'hui et c'est dommage. Mais cela relève l'intérêt de l'utilisation d'ordinateurs personnels dont la gestion est attribuée aux élèves eux-mêmes et non verrouillés par les écoles.
|
||
|
||
\nocite{*}
|
||
%\printbibliography[heading=bibintoc]{geographie-informatique}
|
||
\printbibheading[heading=bibintoc]
|
||
\sloppy % pour une meilleures césure des url dans les références biblio. Retirez si nécessaire.
|
||
\printbibliography[nottype=online,heading=subbibliography,heading=subbibintoc,
|
||
title={Livres}]
|
||
\printbibliography[type=online,heading=subbibliography,heading=subbibintoc,
|
||
title={Ressources en ligne}]
|
||
|
||
\newpage
|
||
\appendix
|
||
|
||
\section{Construction de cartes}
|
||
À l'origine de cette annexe se trouve le projet \emph{OSMdata : visualiser et télécharger les données d'OSM}\footnote{Voir le site du projet~: \url{https://www.openstreetmap.fr/telecharger-donnees-osmdata/} et la carte interactive~: \url{https://demo.openstreetmap.fr/map}}.
|
||
Décrit sur le site comme \emph{Véritable démonstrateur et visualiseur interactif des données OSM}, ce projet appelle à la création de cartes. Dans beaucoup de cas, la cartographie ne se limite pas aux données purement géographiques, mais doit permettre une relation de compréhension du territoire.
|
||
|
||
Le dire est une chose, le faire en est une autre. Cette annexe propose de s'intéresser aux arbres des parcs Gallet et des Crêtets pour en établir la carte. Une thématique est donc ici choisie pour faire la distinction entre le fond de carte et les informations liées à celle-ci.
|
||
|
||
Au préalable de la construction d'une carte particulière attachée à cette problématique des arbres, il faut déterminer ce qu'OSM lui-même peut fournir comme information à ce propos. En d'autres termes, quels sont les objets dont il dispose pour représenter les arbres.
|
||
|
||
Ensuite, pour construire une carte particulière à partir du fond de carte d'OpenStreetMap (OSM), il faut se demander si l'objectif est de réaliser un atlas ou une carte en ligne. Pour illustrer le premier cas, nous allons utiliser QGis. Cela nous permettra aussi de nous familiariser avec la base de donnée d'OSM. Pour illustrer le second cas, nous allons utiliser Openstreetmap lui-même, puis Umap\footnote{Voir~: \url{https://umap.osm.ch/fr/}}. Il s'agit d'une surcouche à OSM sur laquelle on peut travailler librement, c'est-à-dire réaliser une carte thématique sur les arbres de ces deux parcs.
|
||
|
||
\subsection{Fond de carte OSM}
|
||
L'utilisation de QGIS pour construire une carte se fait en deux temps : la construction de la carte elle-même avec l'utilisation de toute une série de couches et l'ajout d'éléments de composition comme un titre, une échelle, une légende \dots
|
||
|
||
La construction de la carte peut reposer sur plusieurs éléments de provenance différente. Par exemple, sur la figure \ref{figure:neigeuxcouches}, on peut voir des couches provenant de quatre origines :
|
||
\begin{description}
|
||
\item[OSM Standard] Cette couche provient du serveur de fond de carte d'OSM via l'extension QGIS QuickMapService. Ce n'est pas une couche vectorielle. Il s'agit de données raster (des pixels) sur lesquelles il n'est pas possible d'intervenir.
|
||
\item[N47E006] Cette couche contient des courbes de niveau qui ne sont pas fournies par OSM, mais par Opendem\footnote{Opendem.info est un fournisseur de modèle d'élévation digitale (Open Digital Elevation Model) à l'adresse \url{https://opendem.info/opendem_client.html}. Il permet de créer des cartes topographiques sur la base d'un fond de cartes OSM comme le fait OpenTopoMap.}. C'est une couche vectorielle (shp) qu'il est possible de modifier.
|
||
\item[OpenTopoMap] Cette couche est l'équivalent topographique d'OSM Standard. C'est un couche raster, elle-même construite autour d'un fond OSM et des courbes de niveau d'Opendem. Elle est de très bonne qualité et comprend des ombres intéressantes\footnote{Voir le site : \url{https://opentopomap.org/\#map=14/47.03840/6.82843}}.
|
||
\item[Neigeux\_lines et Neigeux\_points] Ces deux couches sont issues d'un export des données OSM grâce à l'extension QGIS \emph{Download OSM Data by rectangle selection}. Il s'agit de deux couches (.osm) vectorielles contenant pour la première les chemins (lignes) et pour la seconde les points d'intérêt. Relevons que ces couches (osm) ne sont pas éditables directement. Pour cela, il est nécessaire de les enregistrer en shapefile (shp). L'ensemble de leurs données devient alors accessible dans QGIS.
|
||
\end{description}
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/NeigeuxCouches.eps}
|
||
\caption{Couches de différentes provenances}
|
||
\label{figure:neigeuxcouches}
|
||
\end{figure}
|
||
|
||
Évidemment, les deux types d'éléments compostant le fond de carte sont intéressants. Comme dit ci-dessus, les données raster permettent des ombrages par exemple et les données vectorielles permettent des opérations mathématiques sur la longueur des chemins, comme on va le voir plus loin ou un travail sur des étiquettes. Par exemple, l'élément du fond de carte OSM pour les arbres est simplement un tag \og arbres \fg{} qui pourrait permettre un recensement.
|
||
|
||
\subsection{QGis}
|
||
\subsubsection{Le composeur}
|
||
L'utilisation de QGis a déjà été décrite dans le corps de ce document. Commençons par rappeler les possibilités du composeur d'impression. On le trouve dans le menu « Projet » sous « Nouveau composeur d'impression ». Une fenêtre spéciale permettant de composer ses cartes apparaît. L'idée n'est pas de créer des éléments de carte sur OSM, mais d'incruster une carte OSM en arrière plan sur laquelle on va disposer des objets permettant de la particulariser. La figure \ref{figure:arbresepo} permet de voir le résultat d'une composition simple réalisée au sujet des arbres de l'École primaire de l'Ouest.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ArbresEPO.eps}
|
||
\caption{Les arbres de l'École primaire de l'Ouest}
|
||
\label{figure:arbresepo}
|
||
\end{figure}
|
||
|
||
D'apparence complexe, l'interface graphique est relativement simple pour autant que la barre d'outil \og Boite à outil \fg{} soit présente. Cette boite est présente verticalement sur la gauche de la figure \ref{figure:arbresepo}. Si elle n'est pas présente, passez par le menu \emph{Vue}, puis \emph{Barres d'outils} pour l'afficher. Cette boite à outil dispose comme élément principal correspondant au sixième élément depuis le haut sur la figure, d'un bouton \og Ajouter une nouvelle carte \fg. Ce bouton permet, en tirant un rectangle sur la zone de travail, de placer la carte d'OSM précédemment sélectionnée dans QGIS via le menu \emph{Internet}, sous \emph{QuickMapServices}\footnote{Si \emph{QuickMapService} n'apparaît pas, c'est que son module n'est pas présent. Pour l'installer, passez par le menu \emph{Extensions}, \emph{Installer, gérer les exensions}.}, \emph{OSM} et \emph{OSM Standard}, comme fond de carte de composition. Le quatrième élément de la boite à outil permet de \og Déplacer le contenu de l'objet \fg{}, soit de déplacer la carte de fond dans son cadre pour mieux la positionner. Il faut alors remarquer que le bandeau latéral de droite propose alors dans son onglet \emph{Propriétés de l'objet} diverses options pour la carte, dont celle de réaliser une rotation de celle-ci. Cela a permis sur la figure \ref{figure:arbresepo} de mieux couvrir la cours du collège (on aurait pu mettre celle-ci parallèlement aux côtés de du cadre, mais une petite inclinaison a été maintenue pour signaler que le nord n'est pas perpendiculaire à la cours).
|
||
|
||
Ensuite, à l'aide des outils de la boite à outils, divers éléments ont été placés, comme le titre, la zone de texte \og Tilleuls \fg{} et les deux images. À chaque fois, la configuration de ces éléments est réalisable dans l'onglet \og Propriétés de l'objet \fg{} du panneau de droite.
|
||
|
||
Sur la figure, on voit notamment les propriétés de l'objet \emph{Barre d'échelle} qui est la barre en bas à gauche qui donne les dimensions de la carte. Cet élément est entièrement configurable. Notamment son nombre de segment de 10 qui se trouve dans la section \og Segments \fg{} sous \emph{droite 10}.
|
||
|
||
\smallskip
|
||
Enfin, dans le menu \og Composeur \fg{}, se trouve la possibilité d'enregistrer le projet, c'est-à-dire le composeur. On peut ainsi réaliser plusieurs cartes différentes avec les mêmes éléments. Plusieurs exports sont aussi possibles : jpg, pdf et même SVG, pour une utilisation avec Inkscape.
|
||
|
||
\subsubsection{La base}
|
||
Les possibilités du composeur sont intéressantes, mais l'action sur le fond de carte lui-même n'y est pas possible. Nous allons ici voir comment agir sur celui-ci maintenant. Notamment, cela nous permettra de mieux comprendre comment n'utiliser que certains éléments des cartes OSM, à l'exception d'autres.
|
||
|
||
\smallskip
|
||
Pour commencer, il faut savoir que les objets graphiques d'OSM peuvent être de trois types : des points, des lignes ou multi-segments et des surfaces ou polygones. La structure permettant à un humain de mémoriser de tels éléments n'est pas encore connue. Pour le faire de manière artificielle, on peut utiliser une feuille de papier sur laquelle on trace les figures. Pour un ordinateur, c'est impossible.
|
||
|
||
Une machine utilise essentiellement du texte (des caractères codés à partir de chiffres binaires, eux-mêmes physiquement présents sous forme de tension électrique) et c'est donc sous cette forme que doivent être représentés les objets graphiques d'OSM. On parle de base de données. De quoi s'agit-il ?
|
||
|
||
\smallskip
|
||
On peut s'imaginer un ensemble de tableaux ordonnés et de relations entre eux. Pourquoi des tableaux ? Si on ne connaît pas la manière dont le cerveau humain procède pour mémoriser des informations, on peut facilement s'imaginer mettre indifféremment dans un sac toute une série d'objet qui vont nous permettre de reconstruire des souvenirs. Au contraire de tableaux ordonnés, ces contenus informes pourraient eux-mêmes être résumés sous forme de liste, à la manière d'un dictionnaire décrivant chaque objet et lui attribuant une étiquette pour le mentionner ou le retrouver. De telles structures existent en informatique, mais le langage numérique des machines se prête mieux à des liste d'objets identiques et ordonnés qu'on nomme tableaux ou table. Comme, de plus, les méthodes de catégorisation des machines sont très inférieures à celles des humains\footnote{Rappelons que même la meilleure intelligence artificielle \fg{} ne peut aujourd'hui se passer de centaine de milliers d'humains, qu'on nomme \emph{tacherons}, sous payés pour l’entraîner à catégoriser (voir \cite[pp. 31-46]{LOW}).}, il leur est bien plus commode d'utiliser des tableaux déjà bien ordonnés.
|
||
|
||
Un tableau ou une table peut être une structure très complexe, surtout si elle doit faire référence à un autre tableau ou table par l'intermédiaire de relations. Comme le propos de ce texte n'est pas de faire une introduction aux bases de données, ce qu'il faut savoir c'est que les objets graphiques d'OSM sont mémorisés à l'intérieur de tables en contenant les principaux attributs. Pour exemple, on peut imaginer qu'un point puisse être décrit par ses deux coordonnées (longitude et latitude), qu'un segment puisse l'être par quatre coordonnées deux-à-deux associées, qu'une ligne soit composées de multiples couples de coordonnées, \dots
|
||
|
||
Mais ce n'est pas suffisant. En effet, il faut encore associer à ces éléments un sens physique : un point peut être un arbre ou une table, une surface peut être une piscine ou un bâtiment, \dots Ainsi, on va encore associer les éléments graphiques à des catégories sémantiques.
|
||
|
||
\smallskip
|
||
Par ailleurs, il faut aussi bien faire la différence entre QGIS et OpenStreetMap. Pour réaliser une carte avec des éléments et une symbologie particulière de l'École primaire de l'Ouest, nous allons utiliser dans QGIS des données provenant d'OSM. Pour les obtenir, on utilise un plugin permettant de faire des requêtes ciblant certains éléments d'OSM associé à certains attributs. Celui-ci se nomme \emph{QuickOSM} et s'installe facilement par \emph{Installer/Gérer les extensions} du menu \og Extension \fg. Une fois cela fait, le plugin apparaît dans le menu \emph{Vecteur} et en cliquant sur celui-ci, on obtient le panneau présenté sur la figure \ref{figure:quickosm}. Il est a l'origine de la requête sur le bâtiment de l'école (building school). Lorsque la requête est exécutée, QGIS crée une couche qui va contenir uniquement le polygone correspondant au collège.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/QuickOSM.eps}
|
||
\caption{Requêtes sur OSM}
|
||
\label{figure:quickosm}
|
||
\end{figure}
|
||
|
||
Sur la figure \ref{figure:arbresepocouches}, on voit que six couches ont été réalisées au dessus de la couche d'OSM. Chacune a été créée par une requête et ensuite renommée plus clairement. On trouve successivement : la cour (amenity school), le collège (building school), la table de ping-pong (leisure pitch), la table (leisure picnic\_table), la place de jeux (leisure playground) et les tilleuls (natural tree).
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ArbresEPOCouches.eps}
|
||
\caption{Les couches du projet Arbres EPO.}
|
||
\label{figure:arbresepocouches}
|
||
\end{figure}
|
||
|
||
La couche de fond, nommée OSM Standard, a été obtenue par \emph{QuickMapService}, du menu \og Internet \fg, en choisissant \og OSM \fg{} et \og OSM Standard \fg.
|
||
|
||
Une fois les couches créées, on peut non seulement le renommer, mais les déplacer pour que la légende réalisée postérieurement les présente dans l'ordre désiré.
|
||
|
||
\medskip
|
||
Les éléments constituant les couches sont enregistrés dans deux tables, comme le montre la figure \ref{figure:arbresepstableattributs}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ArbresEPOTableAttributs.eps}
|
||
\caption{La table de la couche de Tilleuls}
|
||
\label{figure:arbresepstableattributs}
|
||
\end{figure}
|
||
|
||
\subsection{Gestion des données}
|
||
La construction de cartes nécessite un fond de carte. Mais parfois on en veut plus, et on utilise des surcouches, et parfois on en veut moins et il faut envisager une gestion des données du fond de carte lui-même.
|
||
|
||
On a vu qu'OSM, par exemple, était constitué de plusieurs types d'éléments : des points, des lignes et des relations. Les relations permettent de grouper des éléments entre eux soit sous forme graphique (plusieurs lignes formant un polygone par exemple), soit sous forme symbolique (l'ensemble des arbres, par exemple). Ces éléments font partie des données qui peuvent être extraites d'OSM et qu'il est possible de sélectionner indépendamment.
|
||
|
||
\subsubsection{Récupération des données}
|
||
Sur la page d'OSM figure un bouton \emph{Exporter} (voir figure \ref{figure:exporter}).
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/Exporter.eps}
|
||
\caption{L'export d'OSM}\label{figure:exporter}
|
||
\end{figure}
|
||
|
||
Celui-ci permet d'obtenir les données relatives à la zone sélectionnée sous la forme d'un fichier au format osm. Il semble que parfois l'export puisse poser des problèmes et il est conseillé d'utiliser un miroir d'OSM, le site \og \emph{Planète OSM Copies régulièrement mises à jour de la base de données complète d’OpenStreetMap} \fg{} ou le \og \emph{Téléchargements de Geofabrik Extractions régulièrement mises à jour des continents, des pays et des villes sélectionnées} \fg{}.
|
||
|
||
Il est donc possible de télécharger des données d'OSM de plusieurs manières\footnote{Voir~: \url{https://wiki.openstreetmap.org/wiki/Downloading_data}}.
|
||
|
||
\smallskip
|
||
Le fichier téléchargé de la zone des parcs Gallet et des Crêtets depuis OSM a une taille inférieure au Mo. Pour comparaison, celui qu'il est nécessaire de télécharger sur Geofabrik ne peut couvrir une surface plus petite que la Suisse et fait donc quelques centaines de Mo.
|
||
|
||
\smallskip
|
||
Les formats de fichiers contenant les données sont très nombreux. Le format le plus accessible est certainement celui d'OSM\footnote{Voir~: \url{https://wiki.openstreetmap.org/wiki/FR:OSM_XML}}. Nous allons le décrire et voir comment l'utiliser dans Qgis. L'autre format auquel nous allons nous intéresser est le pbf\footnote{Voir~: \url{https://wiki.openstreetmap.org/wiki/FR:Format_PBF}}, un format binaire léger et rapide.
|
||
|
||
\subsubsection{Formats de fichier}
|
||
Il est intéressant de considérer ces deux formats de fichiers essentiellement très différents. Le format osm et un format xml\footnote{Voir~: \url{https://fr.wikipedia.org/wiki/Extensible_Markup_Language}}, soit un format constitué de balises humainement compréhensibles, alors que le pbf étant binaire ne l'est pas. Mais la sémantique du premier l'alourdit et le rend plus lent, alors que le second est plus léger et rapide. Pour comparaison, pour la même zone des parcs Gallet et des Crêtets, le fichier osm a une taille de 420 ko, alors que le fichier pbf fait moins de 25 ko.
|
||
|
||
Ainsi, par nature, le pbf est plus adapté à la récupération d'un grand nombre de données, alors que le format osm l'est plus pour de petites régions.
|
||
|
||
Pour aller plus loin dans la compréhension de ces deux formats, entrevoyons leur structure~:
|
||
\begin{description}
|
||
\item[Format osm] À l'instar d'html ou de gemini, par exemple, ce format est construit autour de balises chevronées. La structure de celles-ci est simple~:
|
||
|
||
\lstinline|<balise attribut="valeurattribut">contenu</balise>|
|
||
|
||
Les trois exemples donnés dans le listing \ref{listing:formatosm}, extrait du fichier couvrant la zone des deux parcs Gallet et des Crêtets impoté d'OSM, présentent successivement les balises \verb|node|, \verb|way| et \verb|relation|. On y voit aussi des attributs comme \verb|visible| ou \verb|user| ainsi que du contenu lui-même formaté en xml comme \verb|tab| ou \verb|member|. Sans aucune connaissance particulière, ces éléments sont déjà naturellement compréhensibles. En connaissant quelque peu le langage, on comprend bien que ce type de fichier est aisément sémantiquement manipulable par un humain.
|
||
|
||
\begin{lstlisting}[float,language=xml,caption={Le format osm},label={listing:formatosm},numbers=right,numberstyle=\tiny,numbersep=6pt]
|
||
<node id="8108491590" visible="true" version="1" changeset="93933826" timestamp="2020-11-11T14:21:48Z" user="guyotv" uid="3731325" lat="47.0957466" lon="6.8269104">
|
||
<tag k="natural" v="tree"/>
|
||
<tag k="species" v="Sequoia pleureur"/>
|
||
</node>
|
||
|
||
<way id="556506855" visible="true" version="5" changeset="93349833" timestamp="2020-10-31T19:26:46Z" user="guyotv" uid="3731325">
|
||
<nd ref="8005863896"/>
|
||
<nd ref="648243604"/>
|
||
<tag k="highway" v="path"/>
|
||
</way>
|
||
|
||
<relation id="11815711" visible="true" version="1" changeset="93327746" timestamp="2020-10-31T08:56:57Z" user="guyotv" uid="3731325">
|
||
<member type="way" ref="864290676" role="inner"/>
|
||
<member type="way" ref="864290677" role="outer"/>
|
||
<tag k="building" v="yes"/>
|
||
<tag k="informal" v="yes"/>
|
||
<tag k="surface" v="compacted"/>
|
||
<tag k="type" v="multipolygon"/>
|
||
</relation>
|
||
\end{lstlisting}
|
||
|
||
\item[Format pbf] Comme tout binaire, il est bien plus difficile de présenter la structure d'un fichier fait de zéros et de uns. Le wiki en anglais d'OSM consacré au format pbf\footnote{Voir~: \url{https://wiki.openstreetmap.org/wiki/PBF_Format}} en présente la structure de manière assez complète. Comme on peut le voir dans l'exemple final, ce fichier peut aussi être représenté sous forme hexadécimale.
|
||
|
||
La manipulation des fichiers pbf peut se faire avec un outil de manipulation des données d'OSM comme \emph{Osmium}\footnote{Voir~: \url{https://osmcode.org/osmium-tool/} ou \url{https://wiki.openstreetmap.org/wiki/Osmium}}. Il s'agit d'un outil en ligne de commande dont nous verrons l'utilisation à la section \ref{subsubsection:Pbf}.
|
||
\end{description}
|
||
|
||
\subsection{Extraction des données}
|
||
\subsubsection{OSM}
|
||
L'extraction est simple. Il suffit de se rendre sur OSM, de cliquer sur \og Exporter \fg, puis \og Sélectionner manuellement une autre zone \fg{} et de dessiner un rectangle sur la zone voulue, comme le montre la figure \ref{figure:exporter}.
|
||
|
||
Ensuite, on peut importer ces données sur QGIS via le menu \og Couche \fg, puis \og Ajouter une couche \fg{} et \og Ajouter une couche vecteur... \fg. En sélectionnant \emph{Fichier} comme type de couche, un codage UTF8 et pour source le fichier extrait d'OSM (d'extension .osm), on crée automatiquement les couches présentées dans la figure \ref{figure:exportparcs}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ExportParcs.eps}
|
||
\caption{Données OSM dans QGIS}\label{figure:exportparcs}
|
||
\end{figure}
|
||
|
||
Elles se trouvent en bas à gauche de la figure et sont notées~:
|
||
\begin{itemize}
|
||
\item Parcs points
|
||
\item Parcs lines
|
||
\item Parcs multilinestrings
|
||
\item Parcs multipolygons
|
||
\item Parcs other relations
|
||
\end{itemize}
|
||
|
||
Il est intéressant de noter les différences entre la représentation d'OSM en haut à gauche et celle des données d'OSM affichées pas QGIS. On pourrait presque penser qu'il ne s'agit pas de la même zone.
|
||
|
||
Plusieurs différences sont significatives.
|
||
\begin{itemize}
|
||
\item Les couleurs de la représentation sont en premier lieu frappantes. Il est évidemment possible de les changer et il ne s'agit pas ici de mentionner l'importance de celles-ci dans un cas comme celui-ci où des bassins d'eau sont présents, aisément identifiables sur OSM et inexistants sur QGIS, mais d'observer que le rendu de QGIS ne distingue pas la couleur des deux bassins en bas à droite des couleurs du sol des parcs et de la piscine.
|
||
\item La zone sélectionnée sur OSM ne correspond pas totalement à celle visible sur QGIS. En particulier, les voies de chemin de fer débordent largement de celle-ci. Il semble que certains objets débordant le cadre sélectionné soient présents parce qu'il aurait fallu les couper, ce que l'export d'OSM ne fait pas.
|
||
\item La géométrie de la zone n'est pas non plus identique. On constate visiblement une déformation qui semble avoir étiré la représentation sur l'axe horizontal.
|
||
\item Les points sont présents autant dans le parc Gallet que dans celui des Crêtets. Or, seul la moitié sud du parc Gallet était cartographiée avec des arbres. L'immense majorité des points figurant dans le parc des Crêtets ne sont donc pas des arbres, mais des lampadaires.
|
||
|
||
Sur OSM, un changement d'échelle permet de voir que seuls huit arbres sont présents, car les lampadaires n'y sont pas représentés malgré un zoom important.
|
||
|
||
Sur QGIS, la représentation prête sérieusement à confusion.
|
||
\item Enfin, chose qui n'apparaît pas sur la figure \ref{figure:exportparcs}, car corrigée pour qu'on voie les points, mais la couche de ceux-ci a été récupérée par QGIS en dessous de toutes les autres. Ainsi, à l'ouverture, aucun arbre ou lampadaire n'étaient visibles.
|
||
\end{itemize}
|
||
|
||
\subsubsection{Pbf}\label{subsubsection:Pbf}
|
||
Nous allons ici voir l'extraction des données des parcs Gallet et des Crêtets à l'aide d'Osmium.
|
||
|
||
L'installation d'Osmium se fait par celle du paquet éponyme \verb|osmium-tool|. Pour son utilisation un \verb|man osmium| donne accès à sa documentation. Son utilisation en ligne de commande est à justifier par l'existence du paquet \verb|python3-pyosmium| qui donne accès à Osmium par l'intermédiaire de python.
|
||
|
||
Osmium installé, on peut extraire du fichier pbf de Geofabrik couvrant toute la Suisse uniquement la région des deux parcs grâce à la commande du listing \ref{listing:osmiumextract} qui utilise un cadre (bounding box : bbox) déterminé avec l'outil d'export d'OSM, la stratégie (-s) d'extraction smart permettant une bonne gestion des éléments aux bords de la zone d'extraction (voir \verb|osmium help extract|) et un fichier de sortie nommé \emph{parcs.pbf}.
|
||
|
||
\begin{lstlisting}[language=bash,caption={Le format osm},label={listing:osmiumextract},numbers=right,numberstyle=\tiny,numbersep=6pt]
|
||
osmium extract --bbox 6.82364,47.09480,6.82859,47.09783 -s smart switzerland-latest.osm.pbf -o parcs.pbf
|
||
\end{lstlisting}
|
||
|
||
L'extraction des données dans cette zone uniquement fait passer la taille du fichier pour la Suisse de 344 Mo à 23 ko.
|
||
|
||
\medskip
|
||
Outre le fait qu'osmium soit un outil en ligne de commande, il permet une gestion fine des limites de l'exportation. En effet, trois options de stratégie (-s) d'exportation sont disponibles et présentées à la figure \ref{figure:limitesosmium}. Le manuel d'Osmium (\verb|osmium -h export|) les décrits précisément.
|
||
\begin{description}
|
||
\item[-s simple] Cette option correspond à la figure \ref{figure:limiteosmiumsimple}. Les calculs se font en un seule passe. Les n\oe uds sont entièrement référencés. Les chemins et les relations traversant la région choisie ne sont pas complètement référencés.
|
||
\item[-s complete] Cette option correspond à la figure \ref{figure:limiteosmiumcompleteway}. Les n\oe uds sont entièrement référencés. Les calculs se font en deux passes. Les chemins sont entièrement référencés, mais pas les relations.
|
||
\item[-s smart] Cette option correspond à la figure \ref{figure:limiteosmiumsmart}. Les n\oe uds sont entièrement référencés. Les calculs se font en trois passes. Les chemins et quasiment toutes les relations sont référencées.
|
||
\end{description}
|
||
|
||
Évidemment, l'extraction des données est une chose complexe. Il faut garder à l'esprit que l'ensemble des opérations réalisées pour extraire une zone de données géographiques doit aboutir non seulement sa représentation visuelle, mais aussi à une structure de base de données. Si cela n'est pas directement visible dans un format comme le pbf, alors qu'on peut directement le constater dans la structure textuelle du format osm, cela reste dans les deux cas une opération de base de données.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.8\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ParcSimple.eps}
|
||
\caption{L'option -s simple}\label{figure:limiteosmiumsimple}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.8\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ParcComplete_ways.eps}
|
||
\caption{L'option -s complete\_ways}\label{figure:limiteosmiumcompleteway}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.8\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/ParcSmart.eps}
|
||
\caption{L'option -s smart}\label{figure:limiteosmiumsmart}
|
||
\end{subfigure}
|
||
\caption{Gestion des limites de l'export sous Osmium}
|
||
\label{figure:limitesosmium}
|
||
\end{figure}
|
||
|
||
\subsection{Filtrage des données}
|
||
Une fois les données extraites, pour pouvoir en faire ce qu'on veut, il faut qu'on puisse les sélectionner. Or, il est parfois malaisé de le faire pour des centaines d'éléments. Par exemple. sur la figure \ref{figure:exportparcs}, page \pageref{figure:exportparcs}, se trouve, comme déjà mentionné, deux types de points. Des arbres et des réverbères. Essentiellement, dans le parc Gallet (au Sud, en bas) se trouvent des arbres et dans le parc des Crêtets (au Nord, en haut) des réverbères. On voit sur l'encadré en haut à gauche, qu'OSM ne présente pas les réverbères. Ainsi, pour permettre une représentation différentes des deux éléments, il serait intéressant de pouvoir sélectionner uniquement les arbres.
|
||
|
||
\subsubsection{QGIS}
|
||
Évidemment, la base de donnée des éléments ayant été récupérée par QGIS, il est possible de l'utiliser pour le filtrage.
|
||
|
||
Un premier type de filtrage est possible en raison de la structure en couche récupérée des données extraites. Toujours sur la figure \ref{figure:exportparcs}, page \pageref{figure:exportparcs}, on voit en bas à droite l'ensemble des couches issues d'OSM. Celles-ci sont sélectionnables et on peut ainsi visualiser uniquement les éléments qui les constituent.
|
||
|
||
Le problème ces couches ne sont pas structurées sémantiquement, mais en fonction de la géométrie des objets (points, lignes, \dots)
|
||
|
||
Pour réaliser la sélection voulue, commençons par \emph{Ouvrir la Table d'Attributs} de la couche des \emph{Points} de la figure \ref{figure:limiteosmiumsimple}. Celle-ci est présentés sur la figure \ref{figure:tableattributsparcsSsimplepoints}. On voit que les réverbères sont des attributs notés \emph{street\_lamp} de la catégorie \emph{highway} et que les arbres se trouvent dans \emph{other\_tags} sous \emph{"natural"=>"tree"}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/tableattributsparcsSsimplepoints.eps}
|
||
\caption{Table d'attributs de la couche des points de la figure \ref{figure:limiteosmiumsimple}}\label{figure:tableattributsparcsSsimplepoints}
|
||
\end{figure}
|
||
|
||
Pour effectuer la sélection, il faut alors utiliser l'outil de sélection \emph{Sélectionner des Entités Par Valeur...} comme le montre la figure \ref{figure:lampadaireselection}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/LampadairesSelection.eps}
|
||
\caption{Sélection des lampadaires uniquement}\label{figure:lampadaireselection}
|
||
\end{figure}
|
||
|
||
En remplissant alors la catégorie \emph{highway} par l'attribut \emph{street\_lamp}, la sélection se fait bien, comme on peut le voir en jaune sur la figure.
|
||
|
||
\subsubsection{Osmium}
|
||
Une autre manière de procéder est d'opérer le filtrage avant l'import dans QGIS, cela en ligne de commande avec Osmium.
|
||
|
||
\fbox{
|
||
\begin{minipage}{0.9\textwidth}
|
||
|
||
Relevons ici de manière générale non seulement l'importance de disposer de multiples manières de réaliser des opérations identiques, mais aussi de pouvoir les réaliser dans un cadre conceptuel différent.
|
||
|
||
Savoir réaliser une sélection d'objets à l'aide de QGIS pourrait sembler suffisant. Cela serait passer un peu vite sur l'histoire qui met en lumière le fait qu'aucun logiciel n'est vraiment pérenne et que si certains peuvent être très efficaces à un moment donné, ils peuvent ne plus l'être à un autre.
|
||
|
||
De plus, si il peut sembler naturel d'utiliser une interface graphique pour réaliser des opération sur des éléments cartographiques, c'est loin d'être le cas pour la manipulation des bases de données. Dans ce dernier contexte, la localisation de bases distantes implique bien souvent une utilisation plus aisée en ligne de commande.
|
||
|
||
Finalement, l'utilisation de la ligne de commande est bien moins énergivore et souvent bien plus complète que celle des interfaces graphiques comme nous avons pu le voir pour l'extraction de données dans l'interface d'OSM et via Osmium sur des fichiers comme ceux de Geofabrik.
|
||
\end{minipage}
|
||
}
|
||
|
||
\bigskip
|
||
Pour procéder au filtrage, il faut connaître la syntaxe d'Osmium pour cela. Voyons donc comment extraire du fichier \emph{parcs.pbf} l'ensemble des lampadaires. Le listing \ref{listing:filtrelampadaires} présente la commande.
|
||
\begin{lstlisting}[language=bash,caption={Filtrage des lampadaires avec Osmium},label={listing:filtrelampadaires},numbers=right,numberstyle=\tiny,numbersep=6pt]
|
||
osmium tags-filter parcs.pbf n/highway=street_lamp --overright -o parc_lampadaires.pbf
|
||
\end{lstlisting}
|
||
|
||
La méthode \emph{tags-filter} d'Osmium est donc celle utilisée sur le fichier précédemment extrait de la base suisse via la commande du listing \ref{listing:osmiumextract}. Le motif de sélection est \textbf{n/highway=street\_lamp}. On y voit évidemment la clé \emph{highway} et sa valeur \emph{street\_lamp}. Mais, ceux-ci sont précédés de \textbf{n/}. De quoi s'agit-il ? Simplement, Osmium permet le filtrage des quatre éléments cartographiques que sont les noeuds (nodes~: n), les chemins (ways~: w), les aires (areas~: a) et les relations (relations~: r). Par défaut, c'est-à-dire si on omet le \emph{n/} par exemple, l'ensemble des éléments est utilisé pour la recherche. Mais si l'un ou l'autre, ou plusieurs simultanément, comme \emph{nw/} par exemple, de ceux-ci sont préciser, la recherche ne se fera que sur eux.
|
||
|
||
Ainsi la commande du listing \ref{listing:filtrelampadaires} filtre les lampadaires uniquement. Mais attention, le mot \emph{filtre} est quelque peu galvaudé, puisqu'il s'agit bel et bien d'une extraction, mais qui peut porter sur de multiples types d'éléments. En effet, avec un fichier de sortie comme \emph{parc\_lampadaires.pbf} par exemple, à l'import dans QGIS, on voit apparaître les quatre couches d'éléments. Mais celles-ci sont toutes vides, à l'exception de celle des points qui sont de lampadaires. Le mot \emph{filtrer} qui laisse supposer qu'on ne présente que certains élément visuellement, comme c'est le cas dans QGIS, puisque le fichier pbf n'y est pas touché, seule la présentation filtre réellement les lampadaires, est donc quelque peu mal choisi, puisque seuls les lampadaires restent présents dans la base pbf filtrée par Osmium. Cela dit, pour de gros fichiers, c'est évidemment un avantage. Tout dépend de ce que l'on veut réaliser.
|
||
|
||
\subsection{Ajouts de données}
|
||
|
||
Une grande quantité de cas différents peuvent se présenter quand on veut ajouter des données. La première question qui se pose est de savoir à quoi on veut ajouter des données.
|
||
|
||
\medskip
|
||
On peut, par exemple, vouloir ajouter des données à un système de cartographie en ligne. Cela peut tout simplement être impossible. Il n'est pas possible d'intervenir sur la cartographie du premier des Gafam ou celle de SwissTopo. Par contre, c'est possible avec OpenStreetMap. L'ajout de données à ce type de système de cartographie peut se faire de différentes manières, avec différents logiciels.
|
||
|
||
On peut aussi vouloir ajouter des données sur un fond de carte pour faire des cartes papier personnalisées ou sur un fond de carte numérique pour publier des cartes particulières sur son site. La encore plusieurs types d'outils informatiques peuvent être utilisés.
|
||
|
||
\medskip
|
||
Différents cas d'ajouts de données vont être présentés ci-dessous. Mais, il faut bien garder à l'esprit que beaucoup d'autres cas peuvent se présenter qui nécessiterons d'autres techniques.
|
||
|
||
\subsection{Openstreetmap}
|
||
|
||
Pour réaliser une carte des arbres des parcs Gallet et des Crêtets en ligne, on peut simplement utiliser directement Openstreetmap. Cependant, ce qu'il faut bien saisir, c'est que comme pour tout projet libre, les options prises par Openstreetmap en matière de symbologie, et qui sont issues de discussions entre les participants au projet, sont relativement simples et difficilement modifiables pour réaliser un projet particulier. Ainsi, un arbre est il représenté très simplement par un cercle vert avec un point rouge au centre. Changer ce symbole n'est évidemment pas possible sans une redéfinition générale de celui-ci sur l'ensemble des cartes d'OSM.
|
||
|
||
Ainsi, plutôt que la symbologie, nous allons voir ici quelles sont les outils directement mis à disposition par OSM pour gérer les informations relatives aux arbres, dans la base de donnée.
|
||
|
||
Les limites à la représentation et à l'identification des arbres à l'intérieur d'OSM seront ainsi mise en évidence, ce qui nous permettra alors de tenter de les dépasser avec Umap.
|
||
|
||
\subsubsection{Merkaartor}
|
||
|
||
ff
|
||
|
||
\subsubsection{Josm}
|
||
|
||
ff
|
||
|
||
\subsubsection{iD}
|
||
|
||
ff
|
||
|
||
\section{Surcouche Umap}
|
||
L'utilisation d'Umap a déjà été présentée dans ce document. Nous allons cependant y revenir parce qu'elle est l'un des meilleurs moyen de produire des cartes thématiques sur la base de différents fond de cartes. Umap offre des possibilités très complètes pour ajouter des éléments qui ne doivent pas figurer sur un fond de carte comme celui d'OSM. Dans l'exemple qui suit, des possibilités étendues de gestion des POI (Points d'Intérêt), représentés sur la carte par des marqueurs, seront présentées.
|
||
|
||
Le cadre est celui de la description d'un parcours pédestre effectué avec un relevé de trace GPS et des photographies d'éléments dignes d'intérêts se trouvant le long du chemin.
|
||
|
||
\subsection{Méthode manuelle}
|
||
Le nombre de POI étant important, utiliser une méthode manuelle pour les reporter est inenvisageable. Cependant, réaliser la mise en place des différents éléments que sont~:
|
||
\begin{enumerate}
|
||
\item le fond de carte,
|
||
\item la trace du parcours,
|
||
\item les POI et
|
||
\item à l'intérieur de ceux-ci une description complétée par une photographie
|
||
\end{enumerate}
|
||
de manière manuelle pour un unique POI permet de se rendre compte de ce qui sera nécessaire de mettre en place automatiquement. C'est pourquoi, nous allons présenter ici la méthode manuelle pour le faire.
|
||
|
||
\medskip
|
||
On voit sur la figure \ref{figure:hautgeneveyspoi1} l'ensemble des éléments nécessaires : le fond de carte est celui d'OpenTopoMap, la trace du parcours est une trace GPS obtenue avec OpenTrack sur un téléphone FairPhone 2 sous le système d'exploitation /e/ et le POI présente un titre, un petit commentaire et une image.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/HautGeneveysPOI_1.eps}
|
||
\caption{Le premier POI sur la trace et le fond de carte.}\label{figure:hautgeneveyspoi1}
|
||
\end{figure}
|
||
|
||
Pour choisir le fond de carte, il suffit de passer en mode édition (petit crayon en haut à droite) et de choisir l'icône des cartes empilées nommé Choisir le fond de carte et de trouver celle correspondant à OpenTopoMap.
|
||
|
||
\smallskip
|
||
Pour récupérer la trace gps, il faut au préalable l'avoir transférée sur son ordinateur au format gpx. Cela est possible directement depuis OSMTracker sur le smartphone pour le transférer ensuite par d'autres moyens sur son ordinateur ou, il est possible de transférer la carte sur OSM depuis OSMTracker, puis de se connecter sur OSM pour en récupérer le fichier. Pour cela, il faut sélectionner Traces GPS en haut au milieu, puis Mes traces. Trouvez alors la trace GPS que vous voulez utiliser et sélectionnez le fichier gpx. Il vous sera alors possible de le télécharger.
|
||
|
||
Une fois cela fait, retournez sur Umap, passez en mode édition et sélectionnez Importer des données (la flèche vers le haut dans un rond blanc). Là, choisissez gpx pour le format de données, en-dessous Importer dans un nouveau calque et Importer. La trace s'affichera alors.
|
||
|
||
\smallskip
|
||
La réalisation du POI est plus complexe, car il est nécessaire de le positionner correctement.
|
||
|
||
Ce sont les coordonnées GPS associées à l'image qui permettent de le faire. Pour les déterminer, il faut utiliser Gimp par exemple, en allant dans le menu Image, puis Métadonnées et Afficher les métadonnées. Dans les données EXIF, il faut trouver Exif.GPSInfo.GPSLatitude ou Longitude, vous trouverez les valeurs de position en degrés, minutes et secondes. Il faut alors convertir ces coordonnées en degré décimal de la manière suivante :
|
||
\begin{align*}
|
||
Latitude_{degré\;dec.}&=Latitude_{degré}+Latitude_{min.}/60+Latitude_{sec.}/3600\\
|
||
Longitude_{degré\;dec.}&=Longitude_{degré}+Longitude_{min.}/60+Longitude_{sec.}/3600
|
||
\end{align*}
|
||
Ensuite, on peut placer sans difficulté un POI sur le fond de carte UMAP. Pour cela, il faut passer en mode édition (le crayon en haut à droite), puis choisir d'ajouter un marqueur (goutte en haut à droite) et le placer n'importe où sur la carte. Il faut alors valider pour que le POI existe.
|
||
|
||
Ensuite seulement, il faut cliquer sur celui-ci et choisir de l'éditer (un petit crayon). Cela permet d'accéder au options du marqueur. Parmi celles-ci se trouve un onglet \emph{Coordonnées} que vous pouvez remplir des valeurs en degrés décimaux obtenus précédemment.
|
||
|
||
Puis, il faut choisir le calque sur lequel le POI trouvera sa place (éventuellement à créer précédemment), dans les \emph{Propriétés de la forme} choisir la forme du POI et dans les \emph{Options d'interaction}, sous \emph{Gabarit du contenu de la popup} et en vous aidant de l'aide, vous pouvez construire le contenu de votre POI en plaçant par exemple un titre à l'aide d'un \# précédant celui-ci et une image à l'aide d'accolades \{\{ url \}\} entourant le lien vers celle-ci, préalablement rendue disponible sur un site quelconque.
|
||
|
||
\subsection{Méthode automatique}
|
||
Évidemment, lorsqu'il faut placer cinquante POI, la méthode manuelle s'avère très fastidieuse. Il faut alors avoir recours à un script qui va extraire les informations de position du POI des métadonnées EXIF des images, puis les mettre dans un fichier texte de type csv.
|
||
|
||
\medskip
|
||
La première étape est d'utiliser le script du listing \ref{listing:creationcarteumap} dans un répertoire où se trouve le dossier comprenant les images.
|
||
|
||
\subsubsection{Fonctionnement du code}
|
||
|
||
Aux lignes \ref{creationcarteumap2:ligne:num1} à \ref{creationcarteumap2:ligne:num3}, on importe les modules nécessaires au script. En particulier, le module \emph{OS} (ligne \ref{creationcarteumap2:ligne:num1}) permet de récupérer les noms des fichiers images du répertoire les contenant, le module \emph{exifread} (ligne \ref{creationcarteumap2:ligne:num2}) permet de récupérer les données EXIF des images et enfin le script \emph{creation\_carte\_umap2\_coord} (ligne \ref{creationcarteumap2:ligne:num3}) fournit les fonction de transformation des coordonnées de degrés, minutes, secondes en degrés décimaux.
|
||
|
||
...
|
||
|
||
\lstinputlisting[float,
|
||
language=python,
|
||
caption={Le code pour récupérer la position des POI},
|
||
label={listing:creationcarteumap},
|
||
numbers=left,
|
||
firstnumber=1,
|
||
%linerange={8-11,94-130},
|
||
%firstline=94,
|
||
%lastline=130,
|
||
numberstyle=\tiny,
|
||
numbersep=6pt,
|
||
stepnumber=2]
|
||
{codes/creation_carte_umap2.py}
|
||
|
||
\lstinputlisting[float,
|
||
language=python,
|
||
caption={Le code de conversion des coordonnées.},
|
||
label={listing:creationcarteumapcood},
|
||
numbers=left,
|
||
firstnumber=1,
|
||
%linerange={8-11,94-130},
|
||
%firstline=94,
|
||
%lastline=130,
|
||
numberstyle=\tiny,
|
||
numbersep=6pt,
|
||
stepnumber=2]
|
||
{codes/creation_carte_umap2_coord.py}
|
||
|
||
\newpage
|
||
|
||
\section{Cartes interactives en python}
|
||
\subsection{Objectifs}
|
||
Avec des élèves qui ont choisi l'OC d'informatique, il est possible d'envisager des projets articulant langages de programmation et cartographie.
|
||
|
||
Par exemple, html5 et python peuvent être utilisés pour produire des des cartes interactives qui permettent au programmeur d'aborder le mélange de ces langages à travers les bibliothèques python \texttt{folium} et \texttt{leaflet.js}.
|
||
|
||
\begin{figure}[bh]
|
||
\centering
|
||
\includegraphics[scale=0.8]{images/CarteEPO-LBC.eps}
|
||
\caption{La carte de 2013}\label{figure:carte2013}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
L'exemple que nous allons donner ici se base sur un ancien atelier interdisciplinaire réalisé en 2013 par des élèves d'option complémentaire informatique, des élèves de l'atelier interdisciplinaire \og Imagine ton image \fg{} et des élèves de l'École primaire de l'ouest à la Chaux-de-Fonds.
|
||
|
||
Il s'agissait \og de collaborer pour la création d'un site qui a pour but de faire découvrir différents lieux de La Chaux-de-Fonds à travers des photos et des dessins. \fg{}\footnote{Le site est encore fonctionnel et se trouve à l'adresse : \url{http://www.cvgg.org/EPO-LBC/}.}
|
||
|
||
Dans ce site se trouve une carte assez interactive pour l'époque situant par de petits cercles bleus des lieux choisis et photographiés par les élèves. En survolant ces cercles, il apparaît un encadré avec le titre du lieu et une photo de celui-ci. En cliquant sur le cercle, on se retrouve sur un article consacré au lieu ou les élèves de l'école primaire le présentent par de petits textes, des dessins et des photos.
|
||
|
||
Le site dans son ensemble et la carte en particulier ont été réalisés par les élèves de l'option complémentaire d'informatique qui ont aussi pris en charge la présentation des photos réalisées par les élèves de l'atelier interdisciplinaire.
|
||
|
||
\medskip
|
||
Ce qui nous intéresse ici est la carte des lieux. Celle-ci est présentée dans la figure~\ref{figure:carte2013}.
|
||
|
||
Cette carte se base sur une image de fond de dimensions fixes. Ainsi, il n'est pas possible de zoomer pour mieux situer les lieux. De plus, le positionnement des étiquettes attachées à chacun d'entre eux est fixe et le même pour toutes celles-ci. La navigation dans cette carte est donc particulièrement malaisée.
|
||
|
||
\medskip
|
||
Nous allons montrer ici dans quelle mesure l'intervention de python avec folium permet de remédier à cette situation et permettre d'entrevoir beaucoup d'autre applications.
|
||
|
||
\subsection{Installation}
|
||
L'installation de folium passe par l'installation de python3-pip avec le gestionnaire de paquets de votre distribution et par l'utilisation de pip3~:
|
||
\begin{verbatim}
|
||
pip3 install folium
|
||
\end{verbatim}
|
||
|
||
\subsection{Les tags}
|
||
Le code utilisé est donné dans le listing~\ref{listing:cartepython}. On y voit l'importation du module folium (ligne \ref{ligne:modulefolium}) et la création d'un objet carte (ligne \ref{ligne:carte}).
|
||
|
||
\smallskip
|
||
Puis, on crée deux marqueurs et un cercle, tous centrés sur les mêmes coordonnées GPS.
|
||
|
||
Le premier est un marqueur goutte classique (ligne \ref{ligne:markgoutte}) qui ouvre un popup html quand on lui clique dessus. Son contenu est défini à la ligne \ref{ligne:gouttepopup} par remplacement du contenu des trois accolades par le contenu passé à la méthode \texttt{format()}. Évidemment, il est possible d'utiliser pleinement HTML dans le popup.
|
||
|
||
Le deuxième est un simple cercle. Un popup y est défini (ligne \ref{ligne:cerclepopup}) pour montrer qu'il n'est pas fonctionnel car ce n'est pas un marqueur.
|
||
|
||
Le troisième est un marqueur en forme de cercle. Il est défini à partir de la ligne \ref{ligne:markcerclepopup} et est rempli d'une couleur de fond.
|
||
|
||
Finalement, la carte est exportée au format html à la ligne \ref{ligne:sauvegarde}.
|
||
|
||
\lstinputlisting[float,
|
||
language=python,
|
||
caption={Le code de la carte},
|
||
label={listing:cartepython},
|
||
numbers=left,
|
||
firstnumber=8,
|
||
%linerange={8-11,94-130},
|
||
firstline=94,
|
||
lastline=130,
|
||
numberstyle=\tiny,
|
||
numbersep=6pt,
|
||
stepnumber=2]
|
||
{codes/carteLelbc3.py}
|
||
|
||
Le résultat de l'exécution de ce code en python est un fichier html qui constitue une page ayant pour fond une carte openstreetmap, centrée sur le parc Gallet et au facteur de zoom 17. Celle-ci est présentée à la figure \ref{figure:cartefolium}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[scale=0.6]{images/CarteEPO-LBC_folium.eps}
|
||
\caption{La carte réalisée avec folium}\label{figure:cartefolium}
|
||
\end{figure}
|
||
|
||
On y voit le popup du marqueur classique, mais pas celui du second marqueur qui apparaît quand on clique sur le petit cercle bleu.
|
||
|
||
\smallskip
|
||
Sur la figure \ref{figure:cartefoliumzoom}, on peut voir que l'effet d'un zoom arrière est parfaitement géré.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[scale=0.6]{images/CarteEPO-LBC_foliumZoom.eps}
|
||
\caption{La carte folium zoomée}\label{figure:cartefoliumzoom}
|
||
\end{figure}
|
||
|
||
\subsection{Méta-données}
|
||
Permettre le placement de tags sur un fond de carte OpenStreetMap est une chose, réaliser automatiquement le placement d'un grand nombre de ceux-ci en est une autre.
|
||
|
||
Pour cela, on part d'un répertoire dans lequel se trouvent des photographies des lieux qui vont servir de vignette aux tags. Chaque photographie a un nom qui sera le titre du tag.
|
||
|
||
\smallskip
|
||
L'idée est de récupérer l'ensemble des noms des fichiers dans le répertoire, de lire les méta-données de ceux-ci et de créer autant de marques correspondantes.
|
||
|
||
\subsubsection{Noms des fichiers}
|
||
La récupération des noms des fichiers se fait très simplement à l'aide du module \texttt{os} (ligne \ref{ligne:lemoduleos}). Il suffit de spécifier un chemin \texttt{path} et d'utiliser la méthode \verb|.listdir(path)| comme présenté à la ligne \ref{ligne:listdir} du listing \ref{listing:os}.
|
||
|
||
\lstinputlisting[float,
|
||
language=python,caption={La lecture des noms de fichiers},
|
||
label={listing:os},numbers=left,firstnumber=62,
|
||
firstline=62,lastline=66,numberstyle=\tiny,numbersep=6pt,stepnumber=2]
|
||
{codes/carteLelbc3.py}
|
||
|
||
\subsubsection{Données GPS-EXIF}
|
||
Prendre conscience de l'existence de données autres que celles constituant l'image dans un fichier image est pédagogiquement très important. On peut visualiser ces données à l'aide de différents logiciels. Gimp permet de le faire via l'entrée Métadonnées du menu Image, comme on peut le voir à la figure \ref{figure:metadonnees}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[scale=0.6]{images/Metadonnees.eps}
|
||
\caption{Les métadonnées dans Gimp}\label{figure:metadonnees}
|
||
\end{figure}
|
||
|
||
Il est évidemment intéressant à ce stade de constater toutes les informations embarquées par une image et de discuter avec les élèves des risques liés à l'exploitation de celles-ci pour des images publiées sur internet.
|
||
|
||
\medskip
|
||
Une bibliothèque est nécessaire pour récupérer les méta-données. Il s'agit de python3-exif, installable via le gestionnaire de paquets ou grâce à pip3.
|
||
|
||
Après import du module \verb|exifread| à la ligne \ref{ligne:exifread}, son fonctionnement est donné dans le listing \ref{listing:exif}.
|
||
|
||
\lstinputlisting[float,
|
||
language=python,caption={Le code de la carte},
|
||
label={listing:exif},numbers=left,firstnumber=62,
|
||
firstline=62,lastline=90,numberstyle=\tiny,numbersep=6pt,stepnumber=2]
|
||
{codes/carteLelbc32.py}
|
||
|
||
Les données EXIF-GPS fournissant les latitudes et longitudes en mode degré-minute-seconde, il était nécessaire de les convertir en degrés flottants. Pour cela les deux fonctions du listing \ref{listing:conversionangle} ont été utilisées.
|
||
|
||
La difficulté a été que les éléments des tableaux contenant les valeur degré-minute-seconde des latitudes et longitudes étaient de type exifread.utils.Ratio, un type non transformable et flottant par la méthode \verb|float()|. Pour cela, il a été nécessaire d'utiliser la méthode \verb|.num| que l'on voit apparaître aux lignes \ref{ligne:num1} à \ref{ligne:num2} et \ref{ligne:num3} à \ref{ligne:num4}.
|
||
|
||
\lstinputlisting[float,
|
||
language=python,caption={Le calcul des coordonnées},
|
||
label={listing:conversionangle},numbers=left,firstnumber=13,
|
||
firstline=13,lastline=51,numberstyle=\tiny,numbersep=6pt,stepnumber=2]
|
||
{codes/carteLelbc3.py}
|
||
|
||
\subsection{Boucle principale}
|
||
Évidemment, la création de tags doit se faire pour chaque image du répertoire. Ainsi, l'ensemble du code est contenu dans la boucle for de la ligne \ref{ligne:boucleprincipale} du listing \ref{listing:os}.
|
||
|
||
À l'exception de la déclaration des modules et des variables et de l'enregistrement de la carte, restait le problème de la création de celle-ci. En effet, elle se fait sur la base des coordonnées GPS des images en paramètres de la méthode \verb|Map()| de folium, comme le montre la ligne \ref{ligne:carte} du listing \ref{listing:cartepython}. Or, il ne s'agissait pas de faire une carte par image, mais de mettre tous les tags des images sur la même carte. Celle-ci devait donc n'être créée qu'une seule fois. Comme il n'était pas possible de la créer avant la récupération des données GPS, il a fallu décider de ne la créer qu'après la récupération des coordonnées de la première image. Cela s'est fait sur la base d'un compteur d'images (ligne \ref{ligne:compteurimages} du listing \ref{listing:os}.
|
||
|
||
On voit sur la figure \ref{figure:golf} le résultat du placement de trois images réalisées dans le golf du Morbihan en Bretagne sans même en connaître la géolocalisation précise.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[scale=0.6]{images/CarteMorbihan.eps}
|
||
\caption{Une carte avec trois images}\label{figure:golf}
|
||
\end{figure}
|
||
|
||
\subsection{Bugs}
|
||
\subsubsection{Facteur de zoom}
|
||
Le problème du zoom est complexe car pour que l'ensemble des tags soient représenté, il faudrait récupérer les différentes localisations, calculer les dimensions de la carte et, à partir de celles-ci en déduire le facteur de zoom. C'est réalisable, mais assez compliqué pour qu'une solution plus simple ait été mise en place ici.
|
||
|
||
Il s'agit simplement de demander à l'utilisateur de spécifier le facteur de zoom. Le code, donné dans le listing \ref{listing:input}, utilise simplement un descriptif de différents facteurs de zoom et une instruction de récupération de celui-ci (\texttt{input()} de la ligne \ref{ligne:input}). Remarquez les passages à la ligne (\verb|\n|) qui pourraient poser problèmes pour un débutant \dots
|
||
|
||
\lstinputlisting[float,
|
||
language=python,caption={La lecture des noms de fichiers},
|
||
label={listing:input},numbers=left,firstnumber=53,
|
||
firstline=53,lastline=60,numberstyle=\tiny,numbersep=6pt,stepnumber=2]
|
||
{codes/carteLelbc3.py}
|
||
|
||
En réalité, le facteur de zoom n'est pas à l'origine d'un bug lié à son type entier. En effet, la fonction de création de la carte prend en compte un éventuel facteur de zoom non entier en l'arrondissant.
|
||
|
||
\subsubsection{Géolocalisation}
|
||
Enfin, restait à passer l'étape du \og beta testeur \fg{}. En l’occurrence, il s'agissait de placer une image non géolocalisée dans le répertoire des images.
|
||
|
||
On peut alors se retrouver avec un bug réel si l'image non géolocalisée est la première~:
|
||
\begin{verbatim}
|
||
0 : _aport.jpg
|
||
Traceback (most recent call last):
|
||
File "carteLelbc2.py", line 81, in <module>
|
||
print("Latitude : {}, longitude : {}, date : {}".format(latitude,
|
||
NameError: name 'latitude' is not defined
|
||
\end{verbatim}
|
||
|
||
soit ne pas voir le bug la librairie d'accès au donnée EXIF ne retournant rien si les données ne sont pas présentes. Sauf que, sans interruption du programme, ce sont soit les valeurs de longitude et latitude de l'image précédente qui sont utilisées pour positionner celle qui est non géolocalisée. Cela implique que celle-ci superpose son tag à la précédente et qu'il semble alors que la mauvaise image est utilisée. Cela est aussi un bug.
|
||
|
||
\medskip
|
||
De multiples solutions sont envisageables. Nous allons ici présenter plus particulièrement l'une d'entre elle, car elle constitue une introduction à la notion des exceptions\footnote{Voir à ce sujet \url{https://docs.python.org/fr/3.5/tutorial/errors.html} et \url{https://docs.python.org/fr/3.5/library/exceptions.html\#bltin-exceptions}}, sujet souvent négligé.
|
||
|
||
\lstinputlisting[float,
|
||
language=python,caption={Placement d'un code en ligne},
|
||
label={listing:horsligne},numbers=left,firstnumber=88,
|
||
firstline=88,lastline=95,numberstyle=\tiny,numbersep=6pt]
|
||
{codes/carteLelbc3.py}
|
||
|
||
La strucutre \verb|try-except-else| est bien connue des programmeurs. L'idée est ici d'intercepter l'erreur produite quand on tente d'imprimer la latitude ou la longitude sur la sortie standard. C'est ce qui est fait avec les lignes \ref{ligne:try1} à \ref{ligne:try2}. Évidemment, cela signifie que cette instruction \verb|print| ne doit pas être retirée. L'exception recherchée est de type \verb|NameError| en raison de l'erreur reportée ci-dessus. Elle est levée à la ligne \ref{ligne:except}. Si elle ne l'est pas, le code se poursuit à la ligne \ref{ligne:else} à la suite du \verb|else:|.
|
||
|
||
Cela fonctionne très bien si l'image non géolocalisée est la première. Sinon, les variables latitude et longitude sont référencées et l'exception n'est plus levée. Il est donc nécessaire de les déréférencer\footnote{Concernant le référencement/déréférencement, voir \url{https://zestedesavoir.com/tutoriels/3163/variables-scopes-et-closures-en-python/}} à la fin de chaque boucle, comme cela est fait à la ligne \ref{ligne:deref}.
|
||
|
||
\subsection{Améliorations}
|
||
Finalement, le code est évidemment améliorable, notamment au niveau des deux fonctions de latitude et longitude. Il est possible de les regrouper en une seule et cela devrait être fait. Mais, comme il est probable que des élèves commencent par écrire ces deux fonctions de la même manière, nous les avons laissées pour souligner que le travail d'un informaticien ne devrait pas s'arrêter là.
|
||
|
||
\subsection{Pédagogie}
|
||
Il faut relever que la création d'un script permettant de placer des images comme tags sur une carte OpenStreetMap est un travail très formateur autant pour le géographe que pour l'apprenti informaticien.
|
||
|
||
Plusieurs aspects de ces disciplines sont abordés~:
|
||
\begin{itemize}
|
||
\item réflexions autour des objectifs d'un projet ;
|
||
\item utilisation d'un langage de programmation très connu : python ;
|
||
\item utilisation d'une bibliothèque de cartographie (folium), liée à une bibliothèque javascript (leaflet), avec la nécessité d'apprendre à l'utiliser grâce à son manuel ;
|
||
\item gestion d'une interface en mode texte ;
|
||
\item gestion des bugs éventuels et éventuellement tests unitaires.
|
||
\end{itemize}
|
||
|
||
On pourrait aussi reprendre le code HTML produit pour modifier la page selon les goûts des élèves.
|
||
|
||
Enfin, la problématique de la récupération des métadonnées embarquées dans les images constitue aussi un aspect pédagogique important de la réalisation de ce projet à développer avec les élèves.
|
||
|
||
\subsection{Conclusion}
|
||
Il s'agit d'un exemple où l'informatique intervient en cartographie avec du code et non seulement via des logiciels spécifiques. C'est une approche intéressante pour des élèves soit motivés, soit connaissant déjà un peu la programmation. Il y en a, mais tous ne sont certainement pas capable de le faire.
|
||
|
||
Mais c'est aussi une approche qui permet aux enseignants de mieux se rendre compte des multiples interactions entre le code et la cartographie. Et à ce propos, la bibliothèque folium dépasse clairement les limites de ce qui a été réalisé dans cette annexe. En effet, on peut voir à l'adresse suivante \url{https://portailsig.org/content/python-leaflet-folium-ou-comment-creer-des-cartes-interactives-simplement.html} que beaucoup de types de données vectorielles, comme les polygones et les polylines, sont disponibles et que différents formats, comme geojson, sont supportés. Cela permet la création de cartes choroplèthes par exemple.
|
||
|
||
Signalons enfin l'idée très intéressante d'une activité de \og Ballade de photos géolocalisées \fg proposée par \cite{Ballade} qui est tout-à-fait dans le même esprit que celui développé ci-dessus et qui utilise python pour la récupération des données GPS.
|
||
|
||
\subsection{Le code complet}
|
||
Voici finalement avec le listing \ref{listing:horsligne2}, le code complet qui constitue le script produisant la page html de la carte géotaguée.
|
||
|
||
\lstinputlisting[
|
||
language=python,caption={Le code complet},
|
||
label={listing:horsligne2},numbers=left,numberstyle=\tiny,numbersep=6pt]
|
||
{codes/carteLelbc3.py}
|
||
|
||
\section{Cartographie de terrain}
|
||
\subsection{Introduction}
|
||
Aux antipodes de la cartographie avec python, on peut envisager d'aborder le thème d'une toute autre manière : en se déplaçant sur le terrain. L'idée n'est pas ici \emph{d'utiliser} les cartes, mais de les faire. La question est : est-ce envisageable ? La réponse est oui, grâce à OpenStreetMap. Un bon descriptif des outils disponibles en relation avec OpenStreetMap (OSM) est donné à l'adresse \url{https://dane.ac-lyon.fr/spip/OpenStreetMap-la-cartographie-511}.
|
||
|
||
Avant de voir comment, il faut insister sur le fait que la cartographie est un travail méticuleux et généralement de longue haleine. Cela constitue à la fois un inconvénient et un avantage. Un inconvénient car le travail préparatoire à la construction d'éléments cartographiques est important et doit être précis. Un avantage, car il est si important qu'on pourra toujours trouver beaucoup de choses à faire pour tous les élèves.
|
||
|
||
\subsection{Cartes papier}
|
||
La première étape est de préparer des cartes papier sur la base du fond OpenStreetMap. Celles-ci permettrons d'utiliser le crayon pour y reporter les modifications à faire. Il est en effet non seulement plus facile de travailler sur un écran plus grand que celui d'un smartphone, mais cela permet aussi de mieux réfléchir à posteriori aux modifications à réaliser et d'en discuter avec l'enseignant.
|
||
|
||
Aller sur le terrain avec une carte papier, y reporter ses modifications, revenir en classe, discuter des propositions de modifications et, simultanément, aborder la nomenclature des représentations et les impératifs de la simplification liés à l'échelle avec l'enseignant, permet d'aborder la cartographie de manière particulièrement intéressante.
|
||
|
||
\smallskip
|
||
Pour cela, il est nécessaire de disposer de cartes papier des zones à cartographier. Pour faciliter la création de celles-ci, un projet nommé \emph{Fieldpapers} à l'adresse \url{http://fieldpapers.org} existe. La figure \ref{figure:fieldpapers} montre que ce projet permet de faire un atlas en PDF d'une région choisie. Puis, on peut l'emporter sur le terrain et au crayon y prévoir des modifications. Celle-ci peuvent ensuite être reportées comme notes directement sur le site grâce à de repères de positionnement.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[scale=0.4]{images/fieldpapers.eps}
|
||
\caption{Création d'un atlas physique}\label{figure:fieldpapers}
|
||
\end{figure}
|
||
|
||
La création d'un atlas peut étonner dans le cadre d'un cours sur l'utilisation de l'informatique en cartographie. Son côté désuet sera certainement évoqué par les étudiants. Mais, c'est certainement l'occasion d'une discussion, voire même d'une expérimentation, relativement aux outils de prise de notes de type cartographiques sur le terrain. On pourrait penser que l'omniprésence des smartphones engage leur utilisation dans ce cadre. Or, il se trouve que leur taille et le dispositif de prise de notes associé, en l'occurrence le doigt, sont très peu adaptés au placement de symboles schématiques sur une carte. Par ailleurs, l'invention sur le terrain de symboles appropriés aux situations inédites qu'on peut rencontrer, permet une souplesse de représentation que les catégories de symboles d'un logiciel peuvent rendre très difficile à utiliser sur un téléphone.
|
||
|
||
L'expérience d'une comparaison peut être tentée avec les élèves en demandant à un groupe d'utiliser un atlas papier et à un autre de prendre des notes sur leur smartphone. C'est l'occasion d'une discussion sur la pertinence du recours à l'informatique dans tous les cas pour aider les élèves à discerner non seulement les cas où l'informatique est nécessaire, mais ceux où celle-ci ne l'est pas, voire où celle-ci est peut être déconseillée.
|
||
|
||
\medskip
|
||
Avec le projet Field papers, on choisit une zone sur fond de carte OpenStreetMap et on peut régler sa couverture par un nombre déterminé de feuilles A4 ou A3 en position portrait ou paysage. On met un titre et on obtient un atlas constitué d'une page de garde présentant la zone et sur celle-ci la couverture par chaque feuille, comme le montre la figure \ref{figure:parcgallet}, et d'autant de feuilles au sein d'un PDF, comme présentées sur la figure \ref{figure:couvertureparcgallet}.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/FPTOUT.eps}
|
||
\caption{Couverture du parc Gallet}
|
||
\label{figure:parcgallet}
|
||
\end{figure}
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/FPA1.eps}
|
||
\caption{Nord-Ouest du parc}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/FPA2.eps}
|
||
\caption{Nord-Est du parc}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/FPB1.eps}
|
||
\caption{Sud-Ouest du parc}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/FPB2.eps}
|
||
\caption{Sud-Est du parc}
|
||
\end{subfigure}
|
||
\caption{La couverture du parc Gallet}
|
||
\label{figure:couvertureparcgallet}
|
||
\end{figure}
|
||
|
||
On voit aussi sur ces figures le QRCode qui permet de lier les images annotées scannées à l'atlas virtuel.
|
||
|
||
Toujours dans l'optique d'une discussion sur la pertinence de l'utilisation de l'informatique, il faut relever qu'après les notes prises sur le site du Parc Gallet, il a été impossible de les reporter dans l'atlas virtuel. La qualité des images pouvant être en jeu, beaucoup d'essais ont été fait et beaucoup de temps perdu pour une opération dont le bénéfice est aussi à discuter, puisque celles-ci servent simplement à mieux reporter les modifications à faire sur OpenStreetMap.
|
||
|
||
Par ailleurs, ces problèmes de report avaient une origine claire pour autant qu'on consulte l'évolution du projet. Contrairement aux logiciels propriétaires pour lesquels les informations quant aux évolutions des logiciels sont généralement inaccessibles, les projet mettant en jeux des logiciels libres publient ces informations. Le projet Fiels papers est publié sur la célèbre forge logicielle \emph{Github} à l'adresse \url{https://github.com/fieldpapers}. On peut y voir que le dernier dépôt de code date de 2016. Même si le projet est encore actif, il n'y a que trois développeurs. Cela signifie-t-il qu'il ne soit pas utilisable ? Évidemment non, puisque nous avons pu l'utiliser dans le cadre de cette annexe. Mais, il faut se dire que son évolution sera lente et qu'il ne faut rien attendre de précis à l'heure actuelle.
|
||
|
||
Finalement, on peut constater sur la page \emph{Github} du projet qu'il est écrit entièrement en python. Il est intéressant de le constater puisque ce langage est un langage simple très utilisé et facile à comprendre. Il est donc envisageable d'en visualiser le code sur \emph{Github}, puisque cela est possible pour un logiciel libre, et d'en commenter certaines parties.
|
||
|
||
\subsection{Modifications}
|
||
Le report des modifications se fait ensuite directement sur OpenStreetMap.
|
||
|
||
Le premier problème qui se pose ici est de savoir comment réaliser des modifications sur cette plateforme. Pour commencer, il existe une référence importante à lire absolument avant tout chose avec des élèves. Il s'agit des bonnes pratiques (\url{https://www.openstreetmap.fr/les-bonnes-pratiques-pour-contribuer-a-openstreetmap-en-snt/}) à prendre en compte, notamment pour l'utilisation d'un unique compte.
|
||
|
||
Deux manières de faire des modifications sur OpenStreetMap (OSM) peuvent être envisagées. Soit on propose des modifications sans vraiment faire de l'édition directement sur le site, soit on prend le risque de réaliser réellement des modification. Au niveau du Lycée, les deux manières peuvent être envisagées simultanément.
|
||
|
||
\subsubsection{StreetComplete}
|
||
La première passe par l'application StreetComplete\footnote{Voir~: \url{https://github.com/westnordost/StreetComplete/blob/master/README.md}}. Cette application est très pratique car elle cible des lacunes authentifiées sur OSM. L'idée est celle du jeu \emph{Pokemon Go}. Avec une interface graphique très simple, StreetComplete propose de compléter OSM autour de vous en identifiant et positionnant des requêtes vers lesquelles on se déplace physiquement pour trouver l'information. La figure \ref{figure:streetcompleteelements} présente les requêtes se situant autour du parc Gallet et la figure \ref{figure:streetcompleterequete} en présente l'une d'entre elle avec la demande d'information et le champ permettant de la satisfaire.
|
||
|
||
\begin{figure}[h]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=0.7\textwidth]{images/StreetComplete.eps}
|
||
\caption{Les éléments à compléter.}
|
||
\label{figure:streetcompleteelements}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=0.7\textwidth]{images/StreetCompleteRequete.eps}
|
||
\caption{Une requête}
|
||
\label{figure:streetcompleterequete}
|
||
\end{subfigure}
|
||
\caption{Le logiciel StreetComplete}
|
||
\label{figure:streetcomplete}
|
||
\end{figure}
|
||
|
||
L'intérêt de l'utilisation de StreetComplete est multiple. Il permet~:
|
||
\begin{itemize}
|
||
\item de découvrir que les cartes sont incomplètes et qu'on peut les compléter très simplement,
|
||
\item de comprendre qu'il n'est parfois pas simple de savoir comment donner l'information. C'est le cas pour la notation des rues. Doit-elle être celle qui apparaît sur les panneaux indicateurs ou doit-elle suivre une logique commune à OSM ? Il peut être alors intéressant de lier les problèmes d'odonymie, qui est l'étude des noms propres désignant les rues, à ceux propres à leur représentation dans des bases de données, notamment du point de vue de la longueur des noms avec celui de leur représentation en mémoire. C'est le cas aussi pour la gestion des majuscules dans les noms de places.
|
||
\item d'utiliser un logiciel qui va avoir une influence directe sur un grand système de cartographie, de marquer l'importance de la rigueur nécessaire pour le faire et se souligner ses multiples interactions avec le réseau, voire l'asynchronisme avec le transfert des données quand celui-ci n'est pas présent.
|
||
\item d'utiliser un logiciel installé sur son téléphone à partir d'un dépôt d'applications certifié/non certifié ou libre/non libre pour bien faire comprendre qu'il ne faut pas installer n'importe quoi. Pour Android, un dépôt comme Fdroid peut être mis en valeur pour ces raisons.
|
||
\end{itemize}
|
||
|
||
Bien que simple à comprendre, ce projet totalement fonctionnel, actif et réalisé dans le cadre d'OSM dispose d'une page de documentation sur le wiki d'OSM\footnote{Voir~: \url{https://wiki.openstreetmap.org/wiki/FR:StreetComplete}}. Nous conseillons de télécharger cette application par le dépôt Fdroid.
|
||
|
||
\subsubsection{Outils de modifications}
|
||
\paragraph{Éditeur iD}
|
||
La seconde passe par l'utilisation de divers outils de modifications en direct d'OSM. Le plus simple est l'outil de modification iD disponible en se connectant directement sur la page d'accueil d'OSM. Il est nécessaire d'avoir un compte OSM. Il est important pour utiliser iD dans le cadre de l'enseignement d'avoir un compte pour la classe de manière à pouvoir avoir un historique des modifications. La manière de nommer ce compte est donnée dans les bonnes pratiques mentionnées ci-dessus. Une fois le compte créé, on peut s'y connecter et utiliser l'éditeur iD disponible sur la page d'accueil dans le menu déroulant « Modifier ». D'autres éditeurs sont proposés, dont l'ancien éditeur d'OSM qu'iD a remplacé, Potlach 2, qui nécessite la technologie dépassée \emph{Flash}, et deux éditeurs hors ligne, JOSM\footnote{Une introduction~: \url{https://josm.openstreetmap.de/wiki/Fr\%3AIntroduction}} et Merkaartor\footnote{La documentation : \url{https://wiki.openstreetmap.org/wiki/Merkaartor/Documentation}}, le premier étant l'éditeur hors ligne d'OSM et nécessitant \emph{Java} et le second, un éditeur libre multi-plateforme. Nous reparlerons plus loin de ces éditeurs.
|
||
|
||
\medskip
|
||
Au lancement de l'éditeur iD, on peut voir à la figure \ref{figure:osmediteurid} que deux couches sont superposées : une photographie aérienne et la carte d'OSM.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/OSMEditeurID.eps}
|
||
\caption{L'éditeur iD}
|
||
\label{figure:osmediteurid}
|
||
\end{figure}
|
||
|
||
On voit aussi en haut au milieu les trois éléments qui constituent une carte OSM : les points, les lignes et les polygones. Ce sont les briques de la construction des cartes OSM. On voit aussi dans le bandeau vertical à gauche, qu'à chaque élément mentionnés ci-dessus correspond un ensemble de propriétés qui vont le définir plus précisément.
|
||
|
||
\bigskip
|
||
Les modifications que nous allons réaliser portent sur l'ajout, le déplacement et la suppression de lignes et l'ajout de polygones.
|
||
|
||
\bigskip
|
||
Commençons par les lignes. L'outil d'ajout de lignes est très simple à utiliser. Il suffit de le sélectionner (en haut, au milieu), de cliquer gauche sur l'endroit du départ de la ligne, puis de cliquer gauche pour ajouter des points et enfin de double cliquer gauche pour finir la ligne. Sur la figure \ref{figure:osm_lignes_apres} on voit que deux lignes ont été ajoutées de cette manière par rapport à la figure \ref{figure:osm_lignes}.
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\def\svgwidth{\textwidth}
|
||
\input{images/OSM_lignes.eps_tex}
|
||
\caption{Avant modification.}
|
||
\label{figure:osm_lignes}
|
||
\end{subfigure}
|
||
|
||
\smallskip
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\def\svgwidth{\textwidth}
|
||
\input{images/OSM_lignes_apres.eps_tex}
|
||
\caption{Les modifications faites.}
|
||
\label{figure:osm_lignes_apres}
|
||
\end{subfigure}
|
||
\caption{Modifications de lignes}
|
||
\end{figure}
|
||
|
||
Pour le déplacement de points, c'est tout aussi simple. On clique gauche sur le point et on maintient pendant le déplacement. Puis, on relâche. Un problème peut survenir si le point est lié à un autre élément, comme ce fut le cas pour la suppression du segment de chemin en haut de la figure.
|
||
|
||
Pour supprimer une extrémité de chemin, il faut simplement supprimer le dernier point. En réalité, l'adverbe simplement n'a pas lieu d'être, puisque cela peut être complexe dans le cas où le point est lié à un élément sous-jacent.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/OSMSuppressionPoint1.eps}
|
||
\caption{Le point à supprimer.}
|
||
\label{figure:osmsuppressionpoint1}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/OSMSuppressionPoint2.eps}
|
||
\caption{Séparation.}
|
||
\label{figure:osmsuppressionpoint2}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/OSMSuppressionPoint3.eps}
|
||
\caption{Suppression.}
|
||
\label{figure:osmsuppressionpoint3}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/OSMSuppressionPoint4.eps}
|
||
\caption{Problème.}
|
||
\label{figure:osmsuppressionpoint4}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/OSMSuppressionPoint5.eps}
|
||
\caption{Suggestion.}
|
||
\label{figure:osmsuppressionpoint5}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/OSMSuppressionPoint6.eps}
|
||
\caption{Enregistrement.}
|
||
\label{figure:osmsuppressionpoint6}
|
||
\end{subfigure}
|
||
\caption{Suppression de l'extrémité d'un segment}
|
||
\label{figure:osmsuppressionpoint}
|
||
\end{figure}
|
||
|
||
La série des figures de la figure \ref{figure:osmsuppressionpoint} montre que préalablement à la suppression d'un point lié, il est nécessaire dele séparer des éléments auxquels il est lié, puis d'en rattacher l'autre extrémité à l'élément auquel il était attaché avant d'enregistrer les modifications.
|
||
|
||
\paragraph{Éditeur JOSM}
|
||
Considérons ensuite les polygones. Trois éléments étaient à placer~: une petite zone de jeux pour enfants, un bassin avec une fontaine et une place goudronnée. Pour les deux premiers, nous allons utiliser l'éditeur en ligne JOSM pour les raisons présentées ci-dessous. Merkaartor sera finalement utilisé pour la place goudronnée.
|
||
|
||
\medskip
|
||
JOSM est disponible dans les dépôts Debian et Raspberrypi. Mais il a été impossible de réaliser avec cette version une connexion sur OSM. JOSM étant écrit en Java, même si cela est déconseillé du point de vue de la sécurité, en raison du fait que cet éditeur étant l'éditeur hors ligne officiel d'OSM est certainement dépourvu de malice (mais pas forcément de bugs problématiques sur un serveur par exemple), il a été possible de le télécharger (un unique fichier jar) et de le lancer par la commande du listing \ref{listing:josm}. La version pour Raspberrypi est elle parfaitement fonctionnelle.
|
||
|
||
\begin{lstlisting}[float,language=bash,caption={Lancement de JOSM},label={listing:josm},numbers=right,numberstyle=\tiny,numbersep=6pt]
|
||
java -jar josm-tested.jar
|
||
\end{lstlisting}
|
||
|
||
Sur la figure \ref{figure:creationzonejeu}, on peut voir les phases successives de la construction de l'élément place de jeu. On commence par dessiner le polygone (figure \ref{figure:josmpolygone}), puis on le nomme (figure \ref{figure:josmpolygonename}), en français et en anglais. La question de savoir dans quelle langue il faut le faire est ici posée. Finalement, on verse les changements sur OSM (figure \ref{figure:creationzonejeu}).
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/JOSMPolygone.eps}
|
||
\caption{Création du polygone.}
|
||
\label{figure:josmpolygone}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/JOSMPolygoneName.eps}
|
||
\caption{Création des métadonnées.}
|
||
\label{figure:josmpolygonename}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/JOSMVersement.eps}
|
||
\caption{Versement des modifications sur OSM.}
|
||
\label{figure:josmversement}
|
||
\end{subfigure}
|
||
\caption{Création de la zone de jeu.}
|
||
\label{figure:creationzonejeu}
|
||
\end{figure}
|
||
|
||
On voit aussi que le versement a eu lieu après le placement de la table et des bancs, dont nous parlerons ci-dessous.
|
||
|
||
\medskip
|
||
Le second élément est plus complexe, puisqu'il s'agit d'un bassin circulaire. JOSM est intéressant de ce point de vue, puisqu'il permet de construire automatiquement un cercle polygonal à partir de trois points. Pour les disposer, il faut afficher un fond constitué par une image satellite. Celui-ci est disponible dans le menu \emph{Imagerie} sous \emph{Images Mondiales ESRI}. Avec cette image de fond, on peut alors construire un polygone formé de trois points placés sur le cercle et choisir \emph{Créer un cercle} dans le menu \emph{Outil}. JOSM crée alors un cercle constitué de quatorze points comme le montre la figure \ref{figure:josmcercle}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/JOSMCercle.eps}
|
||
\caption{Création d'un cercle.}
|
||
\label{figure:josmcercle}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/JOSMBassin}
|
||
\caption{Métadonnées.}
|
||
\label{figure:josmbassin}
|
||
\end{subfigure}
|
||
\caption{La création du bassin.}
|
||
\label{figure:creationbassin}
|
||
\end{figure}
|
||
|
||
Pour les métadonnées, il s'agit de trouver dans le menu \emph{Préréglages} la bonne description, ici \emph{Name Bassin} (figure \ref{figure:josmbassin}). Le résultat sera un cercle hachuré de lignes bleues, comme le montre la figure \ref{figure:josmresultats}, page \pageref{figure:josmresultats}.
|
||
|
||
Si le choix des métadonnées des éléments peut se faire via le menu \emph{Prégéglages}, il est parfois difficile de savoir quelles métadonnées utiliser. Pour avoir des informations précises à ce sujet, on peut utiliser le wiki d'OSM concernant les \og éléments cartographiques \fg~: \url{https://wiki.openstreetmap.org/wiki/FR:Map_Features}. On y trouve une description très détaillée des pratiques d'utilisation de chaque métadonnée.
|
||
|
||
\bigskip
|
||
Enfin, plaçons les points, c'est-à-dire ici les bancs et les tables. Le travail est simple. On place un simple point à l'endroit désiré et on choisit une description dans le menu \emph{Préréglages}, tels que ceux présentés à la figure \ref{figure:josmbancsettable}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=8cm]{images/JOSMBancsEtTable.eps}
|
||
\caption{Les tables et le banc.}
|
||
\label{figure:josmbancsettable}
|
||
\end{figure}
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=8cm]{images/JOSMResultats.eps}
|
||
\caption{Le résultat final}
|
||
\label{figure:josmresultats}
|
||
\end{figure}
|
||
|
||
Finalement le résultat sur OSM sera celui présenté à la figure \ref{figure:josmresultats}.
|
||
|
||
\medskip
|
||
De nombreuses formes de modification à réaliser sont possibles. Celles réalisées par la suite au parc Gallet ont été très révélatrices des problèmes purement cartographiques auxquels on peut être confrontés. Sans classification aucune, on peut rencontrer~:
|
||
\begin{itemize}
|
||
\item des problèmes de nomenclature. Lors de la réalisation du bassin du parc des Crêtets, s'est posée la question de la description d'un bassin dont la profondeur ne dépasse pas quelques dizaines de centimètres, où les enfants peuvent évoluer, entouré d'une large bordure en béton permettant d'y déposer un linge, de s'assoir au bord du plan d'eau. Dans les catégories disponibles (menu « Préréglages ») via l'interface de JOSM, se trouvent dans les catégories « Eau » et « Hydrographie », deux possibilités qui semblent convenir : « Bassin » et « Plan d'eau ». Pour le premier sont proposés « infiltration » et « rétention » et pour le second un menu bien plus complet s'ouvre avec, notamment, la possibilité de spécifier le type de bateaux pouvant circuler sur le plan d'eau. On se rend donc bien compte de la difficulté, évidemment liée à toute classification, de faire entrer le petit bassin du parc des Crêtets dans ces catégories.
|
||
|
||
Il faut donc bien se rappeler qu'il n'est pas nécessaire d'être vraiment complet et que ne pas spécifier certaines propriétés des objets peut être la meilleures manière de faire de la cartographie et plus généralement que c'est précisément en réalisant ce type de choix qu'on cartographie. Ainsi s'ouvre une meilleures compréhension du rôle des cartes relativement à leur structure et à leur contenu.
|
||
\item L'alimentation du bassin se fait via un petit ruisseau dont l'origine est une petite cascade. Or, la réalisation du tracé du chemin vectoriel représentant celui-ci s'est fait depuis le bassin vers la cascade. À la déclaration du chemin comme ruisseau, le validateur de JOSM s'est déclaré étonné du sens du courant d'eau. Manifestement, JOSM mémorise l'ordre de création des points et l'assimile à la direction du courant d'eau. Sur la carte cependant, cette indication semble ne pas apparaître. On peut donc ne pas tenir compte de l'avertissement. Cela dit pour avertir qu'il est parfois difficile de savoir comment s'en sortir quand il semble possible de faire des modifications erronées.
|
||
\item Le validateur de JOSM est aussi une source d'hésitation qui peut mener à ne pas réaliser certaines modifications. En effet, en voulant supprimer un chemin devenu inexistant, cela après l'avoir déconnecté d'un autre chemin, il s'est trouvé que le validateur a annoncé soudainement plusieurs centaines de modification comme le montre la figure \ref{figure:validateurjosm}.
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/ValidateurJOSM.eps}
|
||
\caption{Les avertissements du validateur JOSM}
|
||
\label{figure:validateurjosm}
|
||
\end{figure}
|
||
À priori, on aurait pu croire que l'erreur venait des modifications du chemin supprimé. Mais, non seulement aucun objet n'était sélectionné, mais en développant les avertissements dans la fenêtre du validateur, en les sélectionnant et, à l'aide du bouton « Sélectionner » en bas à gauche, en localisant les objets à l'origine des avertissements, ceux-ci pouvaient se trouver très loin du parc, là où aucune modifications n'avait été réalisée. Il ne pouvait s'agir de relations entre les objets, puisque le chemin supprimé n'avait de relation avec aucun autre objet.
|
||
|
||
En réalité, en ne sélectionnant aucun objet, le validateur reporte l'ensemble des avertissement liés à la zone téléchargée. Or, ces avertissements n'étaient pas des erreurs et pouvaient sans problèmes être négligés, comme le validateur nous le spécifiait à l'envoi sur OSM. Mais outrepasser cet avertissement peut sembler osé quand on ne sait pas bien ce qui se passe, d'où des hésitations chronophages.
|
||
\item Certains éléments peuvent ne pas apparaitre. Dans le cas du bassin de baignade du parc Gallet par exemple, un polygone a été utilisé pour le tracé du bassin et un autre, englobant, pour la surface en béton permettant de s'allonger au bord de celui-ci. Or, seul le bassin apparaissait dans le rendu d'OSM, car la bordure de ce dernier recouvrait le polygone englobant. Pour remédier à cette situation, il a fallu utiliser une relation\footnote{Pour une introduction à la création de relations, voir~: \url{https://learnosm.org/en/josm/josm-relations/}} entre les deux polygones. Pour ce faire, il faut sélectionner les deux éléments avec la touche \verb|ctrl| enfoncée. Puis dans le menu « Outils », il faut choisir « Créer un multipolygone ». Une fois que cela est fait, celui-ci apparaît dans la liste des relations, dans la partie droite de l'interface. Il faut le sélectionner et demander son édition via le bouton « Modifier la relation dans l'éditeur de relation ». La figure \ref{figure:osmrelations} montre la fenêtre qui s'ouvre alors.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/OSMRelations.eps}
|
||
\caption{Éditeur de relations de JOSM.}
|
||
\label{figure:osmrelations}
|
||
\end{figure}
|
||
On y voit en haut les attributs de l'ensemble des deux objets auxquels on a ajouté le type « construction » (« building ») positionné à « oui ». En dessous, on voit les deux membres de l'ensemble ayant pour rôles « inner » et « outer ». En validant, on construit la relation et le rendu OSM fait apparaître la bordure du bassin.
|
||
\end{itemize}
|
||
|
||
\paragraph{Éditeur Merkaartor}
|
||
Merkaartor va maintenant être utilisé pour des modifications de chemins et pour la création d'une petite place goudronnée.
|
||
|
||
L'interface graphique de Merkaartor est présentée dans la figure \ref{figure:merkaartorinterface}. On voit d'entrée que l'aspect des éléments géométriques est particulier. Mais, on dispose à gauche d'un panneau intéressant pour gérer cela : \emph{Styles}. L'action de ce panneau peut être vue en comparant les figures \ref{figure:merkaartorinterface} et \ref{figure:merkaartorpathmetadata}. Le changement de style des objets est saisissant et si au premier abord il peut sembler inutile, il permet de mieux mettre en évidence certains éléments.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.45\linewidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/Merkaartor.eps}
|
||
\caption{L'interface graphique}
|
||
\label{figure:merkaartorinterface}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\linewidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/MerkaartorPathMetadata.eps}
|
||
\caption{Styles et chemins}
|
||
\label{figure:merkaartorpathmetadata}
|
||
\end{subfigure}
|
||
\caption{Merkaartor}
|
||
\label{figure:merkaartor}
|
||
\end{figure}
|
||
|
||
On voit en effet à la figure \ref{figure:merkaartorpathmetadata} que certains chemins semblables sur la carte OSM sont affichés de manière très différente. L'épaisseur des segments les mets en évidence. La différence tient dans le fait que certains éléments sont de type \emph{path} et d'autres de type \emph{Voie piétonne}.
|
||
|
||
S'il n'est pas ici dans notre propos de résoudre ces problèmes, il est intéressant de relever que ces difficultés peuvent être rencontrées avec des étudiants et qu'elles peuvent être à l'origine d'une discussion intéressante sur la nomenclature des objets. En effet, au parc Gallet, la circulation automobile est interdite et celle des vélos et des piétons autorisée. Mais les \og chemins \fg{} sont asphaltés et le déplacement des véhicules interdits est possible. On peut donc se demander dans quelle catégorie ce type d'objets doit être référencée. Les lignes épaisses de la figure \ref{figure:merkaartorpathmetadata} sont notées comme \emph{voie piétonne}. Or, il est possible d'y circuler en vélo mais certainement pas à moto. La nomenclature de \emph{voie piétonne} est-elle exclusive, ou est-il supposé que les vélos y soient autorisés ? Une manière de ne pas prendre position est de noter ces voies comme \emph{path}. C'est ce qui a été fait pour la majorité d'entre elles sans qu'on sache si cela est volontaire ou si c'est simplement parce que le type de chemin par défaut est celui-ci.
|
||
|
||
Pour en savoir plus, deux références sont intéressantes. Tout d'abord \og Les éléments cartographiques \fg{} du wiki d'OSM\footnote{Voir~: \url{https://wiki.openstreetmap.org/wiki/FR:\%C3\%89l\%C3\%A9ments\_cartographiques}} qui présentent de manière structurée est très claire avec un commentaire, leur représentation sur la carte et une photo de l'élément.
|
||
Puis, le projet \og taginfo \fg{} d'OSM\footnote{Voir~: \url{https://taginfo.openstreetmap.fr/}} qui déclare~:
|
||
\begin{quotation}
|
||
\og \emph{Que vous soyez contributeur ou utilisateur des données OSM, des questions se posent toujours : Quels tag utilisent les gens pour un objet X ? Quels tags dois-je utiliser pour l'objet Y afin qu'il s'affiche correctement sur la carte ? Le tag Z décrit sur le wiki est-il vraiment utilisé et où ?}
|
||
|
||
\emph{Taginfo vous aide en présentant des statistiques sur les tags qui sont actuellement dans la base de données, combien de personnes les utilisent, où, etc. Il recueille aussi des informations sur les tags depuis le wiki et d'autres sources. Taginfo tente de rassembler toutes les informations sur les tags afin de vous aider à comprendre comment ceux-ci sont utilisés et ce qu'ils signifient.}\footnote{Voir~: \url{https://taginfo.openstreetmap.fr/about}}
|
||
\end{quotation}
|
||
|
||
Du point de vue des bases de données, les problèmes liés à ces nomenclatures sont très importants, car dans le calcul d'itinéraires, la possibilité de spécifier le type de véhicule utilisé nécessite de savoir précisément à quel type de chemin appartient un segment de route. Aborder alors la différence entre route et chemin est nécessaire. Nous ne le ferons pas ici, car il ouvre tout un monde de relations quant à la description des routes.
|
||
|
||
\smallskip
|
||
Cependant, pour normaliser les chemins du parc Gallet, au contraire du choix que nous avions fait pour les chemins manquant ajoutés précédemment, comme celui présenté sur la figure \ref{figure:merkaartorpath}, nous sommes revenu à un chemin générique comme celui présenté sur la figure \ref{figure:merkaartorpathnormalise}.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/MerkaartorPath.eps}
|
||
\caption{Un path tagué \emph{voie piétonne}}
|
||
\label{figure:merkaartorpath}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/MerkaartorPathNormalise.eps}
|
||
\caption{Changement de tag : \emph{path}}
|
||
\label{figure:merkaartorpathnormalise}
|
||
\end{subfigure}
|
||
\caption{Normalisation des chemins}
|
||
\label{figure:normalisationpath}
|
||
\end{figure}
|
||
|
||
Pour le dernier tracé prévu pour le parc Gallet, celui de la place goudronnée, Merkaartor nous pose encore quelques problèmes~:
|
||
\begin{itemize}
|
||
\item par la définition de deux types de surfaces, le polygone et la surface. L'accès à la création de ces élément dans le menu \emph{Créer} n'en précise pas très clairement la nature. Contrairement à JOSM, la création d'un polygone se fait après en avoir spécifié le nombre de sommets, alors que pour une surface, il suffit de cliquer gauche à chaque point et de la finir sur le premier point par un clic droit. Évidemment la documentation le précise. Mais encore faut-il la lire.
|
||
\item par le fait que l'accès aux métadonnées est moins aisé qu'avec JOSM, même si, comme le montre la figure , Merkaartor dispose des éléments nécessaires en bas à gauche dans le menu déroulant.
|
||
\item par le fait qu'il se semble pas possible de voir réellement l'aspect final des surfaces créées. Mais c'est aussi le cas avec JOSM. Cela pose problème quand il s'agit de savoir si la surface va être au dessus ou en dessous de chemins qu'elle recouvre, comme c'est le cas sur la figure \ref{figure:surfacegoudronneemerkaartor} et cela d'autant plus qu'il peut se passer plusieurs dizaines de minutes avant que le report (par le bouton \emph{Envoyer}) sur OSM ne prenne effet. Mais en réalité, il est possible de voir le résultat en sélectionnant l'objet et, dans le panneau droit, sous \emph{Informations}, en scrollant tout en bas du panneau pour voir apparaître \emph{Browse}. En cliquant dessus et en se rendant dans le navigateur, on voir la surface apparaître dans OSM, même alors que les modifications reportées ne sont pas encore apparues.
|
||
\item Finalement, un problème plus difficile à corriger est apparu après avoir reportée la surface sur OSM. Pendant plus de douze heures, elle n'est pas apparue. En désespoir de cause, l'utilisation de l'éditeur iD a permis d'en comprendre la raison. Non seulement la surface n'avait pas de type général attribué, mais elle n'était pas connectée au chemin sous-jascent. Il semble qu'à tout objet doit impérativement correspondre un type général en plus des métadonnées comme son nom. L'éditeur iD effectuant un contrôle d'erreur sur les éléments crées, comme JOSM, s'en est immédiatement aperçu et a proposé de corriger le problème en proposant des solutions. Correction faite, trois autres problèmes de même type sont apparus. Un surface ne pouvant recouvrir un chemin, iD a proposé de lier la surface à ce chemin, puis les deux extrémités de ce chemin à la surface. En acceptant, le validateur d'iD à permis l'enregistrement des modifications sur OSM et la surface est apparue en quelques dizaines de minutes.
|
||
\end{itemize}
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.8\linewidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/SurfaceGoudronneeMerkaartor.eps}
|
||
\caption{Création de la surface}
|
||
\label{figure:surfacegoudronneemerkaartor}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.3\linewidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/PlaceGoudronnee1.eps}
|
||
\caption{Résultat : petite échelle}
|
||
\label{figure:placegoudronnee1}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.3\linewidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/PlaceGoudronnee2.eps}
|
||
\caption{Résultat : intermédiaire}
|
||
\label{figure:placegoudronnee2}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.3\linewidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/PlaceGoudronnee3.eps}
|
||
\caption{Résultat : grande échelle}
|
||
\label{figure:placegoudronnee3}
|
||
\end{subfigure}
|
||
\caption{La surface goudronnée}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
Le résultat est donné à la figure \ref{figure:placegoudronnee3}. Les figures \ref{figure:placegoudronnee1} et \ref{figure:placegoudronnee2}, montrent comment se comporte la représentation de la place en fonction du zoom sur la carte.
|
||
|
||
\paragraph{Vespucci}
|
||
D'autres éditeurs existent comme Vespucci\footnote{Voir~: \url{https://vespucci.io/}}. Il s'agit d'un éditeur complet pour OSM sur Androïd (voir figures \ref{figure:vespucci1} et \ref{figure:vespucci2}). Il peut sembler difficile de faire de la cartographie sur un téléphone portable. Pourtant, Vespucci rend cela possible et l'utilisation d'une tablette le rend agréable. C'est un éditeur qui n'est pas tout à fait évident à utiliser en raison de son ergonomie orientée vers le tactile. De plus, au début, l'utilisation d'un éditeur hors ligne avec un grand écran permet une meilleure gestion du travail de l'élève et de l'enseignant pour la validation de celui-ci avant le dépôt sur le serveur d'OSM. Mais, son orientation tactile est très intéressante et sa relation avec le GPS d'un smartphone très pratique. Une introduction de référence est donnée à l'adresse \url{https://vespucci.io/help/fr/Introduction/}.
|
||
|
||
Comme on peut le voir sur la figure \ref{figure:vespucci3}, en mode déverrouillé, la gestion du mode tactile est très bien faite et les préférences permettent de spécifier un mode de « zone élargie » qui rend le toucher encore plus facile. Cependant, il faut bien se familiariser préalablement à son utilisation, car entre simple toucher, double toucher et appuis long, plusieurs fonctions sont cachées.
|
||
|
||
Par exemple, remarquez que le cadenas ne sert pas qu'à déverrouiller l'édition. Un appuis long sur celui-ci permet de sélectionner quatre modes~:
|
||
\begin{description}
|
||
\item[Normal] Ajout, modification, déplacement, suppression des objets. C'est le mode d'édition principal de l'application.
|
||
\item[Attributs] Ouverture de l'éditeur d'attributs avec l'unique possibilité d'ajouter des objets sans aucune possibilité de modifications géométriques.
|
||
\item[Intérieur] Cartographie en intérieur avec filtrage des objets pour permettre une meilleure relation de toucher en environnement exigu.
|
||
\item[C] Il s'agit d'un mode de repérage des objets problématiques, objets à l'origine d'un avertissement. Il permet de repérer les corrections à réaliser.
|
||
\end{description}
|
||
Avec une souris, on a l'habitude pour déplacer un objet de cliquer sur celui-ci et de maintenir le clic en se déplaçant. En mode tactile, cela fonctionne en deux temps. Tout d'abord, on sélectionne un objet par simple clic. Il est alors noté comme sélectionné par une bordure jaune. Alors seulement, il est déplaçable.
|
||
|
||
Un appuis double permet d'entrer en mode d'ajout d'objet avec sélection de ses propriétés.
|
||
|
||
Un appuis prolongé permet de passer en mode ajout de n\oe uds avec réticule pour faire des polygones. Sont disponibles alors différentes opérations permettant de couper des chemins pour réaliser des portions avec des escaliers par exemple.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.3\textwidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/Vespucci1.eps}
|
||
\caption{Mode verrouillé}
|
||
\label{figure:vespucci1}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.3\textwidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/Vespucci2.eps}
|
||
\caption{Téléchargement}
|
||
\label{figure:vespucci2}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.3\textwidth}
|
||
\centering
|
||
\includegraphics[width=\linewidth]{images/Vespucci3.eps}
|
||
\caption{Mode déverrouillé}
|
||
\label{figure:vespucci3}
|
||
\end{subfigure}
|
||
\caption{Vespucci sous Fairphone OS.}
|
||
\label{figure:vespucci}
|
||
\end{figure}
|
||
|
||
La figure \ref{figure:vespuccilampadaires} montre des modifications réalisées au parc des Crêtets avec Vespucci. Notamment, on y voit en rouge en haut à gauche l'ajout d'un escalier et d'un chemin, au nord du kiosque à musique l'ajout de plusieurs bancs et encadrés l'ajout de lampadaires.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/VespucciLampadaires.eps}
|
||
\caption{Utilisation de Vespucci au parc des Crêtets.}
|
||
\label{figure:vespuccilampadaires}
|
||
\end{figure}
|
||
La sélection des propriétés des objets est intuitive et le positionnement des lampadaires est intéressante pour une autre raison. En effet, si on voit les lampadaires sur la figure \ref{figure:vespuccilampadaires}, on peut constater que ceux-ci n'apparaissent pas sur OSM. C'est un choix qui mène à consulter une autre carte pour les voir~: \emph{Street Lamps in OSM}\footnote{Voir~: \url{http://osmstreetlight.bplaced.net/\#18/47.09674/6.82576}}, comme le montre la figure \ref{figure:lampadairesparcgallet}.
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/LampadairesParcGallet.eps}
|
||
\caption{Les lampadaires de nuit sur \emph{Street Lamps in OSM}.}
|
||
\label{figure:lampadairesparcgallet}
|
||
\end{figure}
|
||
|
||
Remarquons enfin, que l'utilisation d'une tablette, si elle permet un positionnement des éléments plus facile, pose le problème de l'accès au réseau. À moins de disposer d'un accès 4G sur celle-ci, il est nécessaire de télécharger les données du lieu à cartographier avant de s'y rendre, puis de réaliser les modifications sur place sans réseau et de revenir sur un accès wifi pour les verser sur OSM.
|
||
|
||
L'autre solution est de disposer d'un téléphone permettant un partage de connexion. Vespucci travaillant en téléchargeant les informations pour y accéder hors ligne, la consommation de données est faible et c'est tout-à-fait envisageable.
|
||
|
||
De plus, l'accès au positionnement satellite est possible permettant là encore une cartographie de meilleure qualité. Mais, il faut rester prudent, tant le positionnement est encore aléatoire si on ne veut pas passer par une géolocalitation par wifi, généralement possible uniquement sous condition de transmission des données à Google. Avec un positionnement uniquement satellitaire, la précision reste limitée, comme on va le voir.
|
||
|
||
\subsubsection{Rendu 3D}
|
||
L'ajout de propriétés aux objets peut être assez complexe. Pour des bancs, la présence d'un dossier, la matière, la couleur et le nombre de places peuvent être spécifiées. Pour un arbre, on peut spécifier sa hauteur, son genre, son espèce, la taille de son tronc, \dots{} Pour un bâtiment, on peut spécifier le nombre de ses étages et on peut se demander si toutes ces informations sont réellement utiles. Pour en juger, la figure \ref{figure:parcgallet3d} présente le rendu 3D du parc Gallet avec le logiciel en Java \emph{OSM2World Viewer}.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/ParcGallet3D.eps}
|
||
\caption{Rendu 3D des informations d'OSM.}
|
||
\label{figure:parcgallet3d}
|
||
\end{figure}
|
||
On peut se rendre compte d'une possible utilisation des métadonnées de chaque objet pour réaliser une vue telle que celle-ci, de manière totalement automatique.
|
||
|
||
\subsubsection{Positionnement GPS}
|
||
Le monde du positionnement par GPS mériterait un ouvrage à lui seul tant il est vaste. Les quelques mots que nous allons en dire n'ont pour prétention que d'évoquer le sujet à travers quatre mesures réalisées par comparaison avec l'estimation relative de leur positionnement.
|
||
|
||
L'idée est d'utiliser un smartphone pour effectuer un positionnement GPS à l'aide de trois application libres : GPSTest, Here GPS Location et phyphox. Les deux premières ont pour unique but de donner la position par GPS. La dernière est une application permettant d'accéder à de nombreux capteurs du smartphone, dont le GPS.
|
||
|
||
Les mesures ont été faites en deux points du parc Gallet. Pour le premier, seul Here GPS Location a été utilisé et pour le second les trois logiciels l'ont été.
|
||
|
||
Les résultats sont donnés à la figure \ref{figure:positionnementgps}.
|
||
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_umap.eps}
|
||
\caption{Les points de mesures et leur estimation.}
|
||
\label{figure:umap}
|
||
\end{subfigure}
|
||
|
||
\smallskip
|
||
\begin{subfigure}{0.24\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_GPSTest.eps}
|
||
\caption{GPSTest}
|
||
\label{figure:gpstest}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.24\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_HereGPS_1.eps}
|
||
\caption{HereGPS 1}
|
||
\label{figure:heregps1}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.24\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_HereGPS_2.eps}
|
||
\caption{HereGPS 2}
|
||
\label{figure:heregps2}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.24\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_Phyphox.eps}
|
||
\caption{Phyphox}
|
||
\label{figure:phyphox}
|
||
\end{subfigure}
|
||
\caption{Positionnement GPS : comparaisons.}
|
||
\label{figure:positionnementgps}
|
||
\end{figure}
|
||
|
||
On reconnait sur la figure \ref{figure:umap} la partie du parc Gallet entre les deux zones de jeu. En bleu les points mesurés et en rouge l'estimation relative de leur position par rapport au distances à différents points déjà placés. La mesure de droite est unique, réalisée avec Here GPS Location et correspond à la mesure présente à la figure \ref{figure:heregps1}. La mesure de gauche est double, c'est-à-dire que deux points sont superposés : celui fait avec GPSTest et au-dessus celui fait avec Here GPS Location. Ils correspondent respectivement aux figures \ref{figure:gpstest} et \ref{figure:heregps2}. Enfin, la mesure de la figure \ref{figure:phyphox} n'est pas présente sur la carte, car elle se situait au centre de la ville de la Chaux-de-Fonds. Phyphox est une outil de grande qualité. Si la mesure qu'il a fourni est mauvaise, c'est que celui-ci a été mal utilisé. Nous reviendrons dans l'annexe \ref{section:outilsdepositionnement} consacrée au GPS sur cet outil et sur GPSTest que nous utiliserons avec plus de perspicacité.
|
||
|
||
\medskip
|
||
Ces figures questionnent plusieurs choses~:
|
||
\begin{itemize}
|
||
\item le positionnement relatif, tout d'abord, puisqu'on voit que le décalage entre celui-ci et les mesures GPS est relativement important. La question est donc de savoir dans quelle mesure on peut se fier à un positionnement relatif. Une expérience intéressante pour en juger serait d'effectuer des mesures de positionnement depuis des points établis avec précision comme des bâtiments vers un point particulier comme l'intersection d'un chemin et de la positionner par triangulation. On pourrait ainsi juger de la précision de l'estimation visuelle et en faire un estimation géométrique. Géométrique, car relative à des points qui eux-mêmes ne sont pas forcément correctement placés du point de vue des coordonnées géographiques.
|
||
\item le positionnement GPS, ensuite, car il est entaché d'erreur. Généralement, il est admis que sans corrections Wifi, celui-ci a une précision de plusieurs mètres (généralement deux ou trois). Il est donc très difficile de dire si les points GPS relevés fournissent un positionnement correct sans recourir à une triangulation Wifi. Or celle-ci est aujourd'hui essentiellement propriétaire (Google) et soumise à l'acceptation d'un traçage du téléphone que le RGPD (Référentiel Généralisé de Protection des Données) européen rend illégal, puis il spécifie que chacun doit pouvoir le refuser sans que cela nuise au service fourni. Sauf donc à utiliser un tel service qui méprise la loi européenne, il n'est pas encore possible d'effectuer un positionnement Wifi améliorant la précision du GPS\footnote{Des alternatives sont en cours de construction, notamment venant de la part de Mozilla qui cherche à fournir une prestation identique compatible avec le RGPD.}.
|
||
\item la disponibilité des valeurs de marge d'erreur pour les outils GPS utilisés. Dans quelle mesure, peut-on estimer cette marge d'erreur et quelle action peut-on avoir sur celle-ci en utilisant par exemple un plus ou moins grand nombre de satellites. GPSTest est a cet égard intéressant, puis il spécifie les satellites utilisés. Un travail intéressant pourrait donc être d'effectuer des mesures avec un nombre variable de satellites pour les comparer entre elles et de mener avec les élèves une réflexion sur le positionnement satellitaire.
|
||
\end{itemize}
|
||
|
||
La pertinence de l'utilisation du positionnement relatif apparait rapidement quand on tente de pacer des éléments sur une carte. Ce travail permet donc de mieux apprécier celui des géomètres qu'on voit parfois au travail avec leur goniomètre et dont on se demande vaguement le pourquoi de l'utilisation de cet appareil. Une introduction à la goniométrie pourrait être très intéressante dans le cadre de celle de la cartographie avec des élèves de niveau lycée.
|
||
|
||
Remarquez enfin que la carte de la figure \ref{figure:umap} a été réalisée avec un logiciel en ligne dédié à la création de cartes à usage collectif ou personnel à partir du fond cartographique d'OSM, nommé Umap\footnote{Voir~: \url{https://umap.openstreetmap.fr/fr/}}. La création de cartes avec celui-ci est décrite dans le corps du présent travail et nécessiterait une annexe approfondie à lui tout seul. Il est cependant très aisé de faire rapidement une carte avec umap et en apprendre l'usage des bases est certainement nécessaire.
|
||
|
||
\subsection{Traces}
|
||
\subsubsection{Principe}
|
||
Fatalement, un jour ou l'autre, on tombe sur la notion de traces. Qu'est-ce qu'une trace ?
|
||
|
||
Qui n'a jamais rêvé de se déplacer d'un point à un autre sans se soucier de rien, mais tout en mémorisant automatiquement son parcours. Si on prend en compte les capacités de positionnement des smartphones actuels, on se rend vite compte que ceux-ci sont capables de nous géolocaliser presque n'importe où. Cette géolocalisation se fait par deux biais~:
|
||
\begin{itemize}
|
||
\item la triangulation à partir d'antennes comme celle du téléphone ou celles du wifi et
|
||
\item le positionnement satellite.
|
||
\end{itemize}
|
||
La première manière de faire pose aujourd'hui de sérieux problèmes de pistage. On sait que les opérateurs téléphoniques ou avec le wifi des multi-nationnales comme Google, se permettent de mémoriser notre position sans nous en informer. Ces méthodes sont donc à éviter, même si elles permettent un positionnement plus précis que le positionnement satellite ou GPS.
|
||
|
||
Le positionnement satellite, par le fait qu'aucune information n'est envoyée par le smartphone au satellite, ne permet qu'au smartphone de se positionner. C'est un avantage pour la sécurité de la vie privée, mais pas pour la précision qui peut être mise en défaut dans des zones où les satellites ne sont pas directement visibles, comme les gorges de rivières par exemple.
|
||
|
||
\medskip
|
||
Le principe est donc de réaliser un positionnement à l'aide d'une dizaine de satellites, à intervalle régulier et de mémoriser ces positions dans un fichier dit de trace.
|
||
|
||
Si le principe est simple, la réalisation du positionnement ne l'est pas. Mais nous n'entrerons pas en la matière ici.
|
||
|
||
La mémorisation des position a, quant à elle, beaucoup évolué. Non seulement les types de fichiers de traces sont très nombreux, mais le contenu des fichiers de traces actuels s'est diversifié.
|
||
|
||
\subsubsection{Fichiers GPX}
|
||
Pour exemple, nous allons nous intéresser quelque peu aux fichiers de traces GPX. Le code du listing \ref{listing:formatgpx} présente le début d'un fichier de trace gpx issu, comme on le verra plus loin, de l'assemblage de trois fichier gpx nommés : Ronde\_2021-07-29\_09-52-18.gpx, Ronde\_2021-07-29\_11-48-44.gpx et Ronde\_2021-07-29\_13-14-09.gpx.
|
||
|
||
\begin{lstlisting}[float,language=xml,caption={Le format gpx},label={listing:formatgpx},numbers=right,numberstyle=\tiny,numbersep=6pt]
|
||
<?xml version="1.0" encoding="UTF-8"?>
|
||
<gpx version="1.1" creator="GPSBabel - http://www.gpsbabel.org" xmlns="http://www.topografix.com/GPX/1/1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
|
||
<metadata>
|
||
<name>Ronde_2021-07-29_09-52-18Ronde_2021-07-29_11-48-44Ronde_2021-07-29_13-14-09</name>
|
||
<time>2021-08-04T19:12:43.016Z</time>
|
||
<keywords>osmtracker</keywords>
|
||
<bounds minlat="47.113020570" minlon="6.845747000" maxlat="47.169750390" maxlon="6.882114260"/>
|
||
</metadata>
|
||
<wpt lat="47.117972350" lon="6.848543490">
|
||
<ele>997.000000</ele>
|
||
<time>2021-07-29T08:06:00Z</time>
|
||
<name>Mémo vocal</name>
|
||
<cmt>Précision: 67.0m
|
||
compass heading: 115.14871215820312deg
|
||
compass accuracy: 3.0</cmt>
|
||
<desc>Précision: 67.0m
|
||
compass heading: 115.14871215820312deg
|
||
compass accuracy: 3.0</desc>
|
||
<link href="2021-07-29_10-06-08.3gpp">
|
||
<text>2021-07-29_10-06-08.3gpp</text>
|
||
</link>
|
||
<sat>5</sat>
|
||
\end{lstlisting}
|
||
|
||
Sans entrer dans les détails, on constate que la structure du fichier est du XML essentiellement constitué de la balise \emph{wpt} qui signifie \emph{way point} positionnée en latitude et longitude. Celle-ci contient aussi d'autres éléments décrivant le contenu du \emph{way point}, ici par exemple un mémo vocal.
|
||
|
||
\medskip
|
||
Si cette structure est assez simple pour qu'on puisse éventuellement intervenir directement dans le texte, voyons maintenant un cas courant d'intervention sur de multiples fichiers gpx pour fusionner plusieurs traces en une seule sans devoir faire du copié-collé. En effet, il arrive régulièrement que de longs déplacement nécessitent l'arrêt de la trace à plusieurs reprises. Il faut alors postérieurement reconstruire le parcours sous la forme d'un unique fichier de trace pour plus de cohérence.
|
||
|
||
Un utilitaire intéressant fonctionnant en ligne de commande existe pour cela, mais aussi pour réaliser de multiples opérations sur des fichiers de traces de types différents. Il s'agit de \verb|gpsbabel|.
|
||
|
||
Ainsi la commande du listing \ref{listing:gpsbabel} permet de fusionner les traces précédemment évoquées en un seule dans un fichier nommé \emph{Ronde.gpx}.
|
||
\begin{lstlisting}[float,language=bash,caption={Gpsbabel},label={listing:gpsbabel},numbers=right,numberstyle=\tiny,numbersep=6pt]
|
||
gpsbabel -i gpx -f Ronde_2021-07-29_09-52-18_2021-07-29_09-52-18.gpx -f Ronde_2021-07-29_11-48-44_2021-07-29_11-48-44.gpx -f Ronde_2021-07-29_13-14-09_2021-07-29_13-14-09.gpx -o gpx -F Ronde.gpx
|
||
\end{lstlisting}
|
||
|
||
\medskip
|
||
Les traces sont donc des objets relativement facilement manipulables. Relativement, car en fait elles peuvent contenir bien plus des suites de points de positionnement. Mais avant de voir cela en détail, voyons comment les acquérir.
|
||
|
||
\subsubsection{Outil OSMTracker}
|
||
L'un des outils permettant de réaliser des traces sous Android est \emph{OSMTracker}\footnote{Voir le pdf~: \url{https://www.manifestationsportive.fr/media/uploads/2016/03/07/tutoriel_osmtracker_-mod_c.pdf} ou le site :~ \url{https://toolbox.hotosm.org/fr/pages/field-mapping-management/4.4_using_osm_tracker/}}. C'est un petit outil très simple disposant d'un menu permettant de régler les paramètres où se trouve disponible la fréquence de mesure de la position à travers deux paramètres : l'intervalle de temps entre deux mesures et la distance minimale entre deux points. Évidemment, c'est la longévité de la batterie qui est l'objectif de ces réglages. Plus le temps entre deux mesures est petit, plus la trace sera précise, mais moins longtemps la batterie tiendra. Le second paramètre est intéressant en cas d'arrêt prolongé. En effet, en dessous d'une certaine distance l'accumulation de mesures en un certain point peut nuire à la lisibilité de la trace. Avec une distance minimale d'enregistrement, des mesures proches sont bien effectuées, mais pas mémorisées. Ainsi la trace est de meilleure qualité.
|
||
|
||
Pour démarrer un enregistrement, il suffit d'appuyer sur le bouton (+). S'ouvre alors une fenêtre qui ne devient active que si le positionnement GPS est accessible. Si c'est le cas, la trace commence. La fenêtre des outils s'active alors, permettant de joindre à la trace un mémo vocal, une photo, une note, \dots{}
|
||
|
||
Mais tout n'est pas si simple.
|
||
|
||
En effet, tout d'abord l'accès au outils de marquage de certains points particulier, comme les \emph{points de vue}, par exemple, n'est possible que si le système de positionnement est de bonne qualité. Pour cela, une indication du nombre de satellite utilisés est disponible et tant que le positionnement n'est pas assez bon, OSMTracker se dit « En attente de fix GPS » et refuse d'activer les boutons permettant de réaliser des actions sur la trace, comme le montre la figure \ref{figure:osmtrackerfixgps}.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/OSMTrackerFixGPS}
|
||
\caption{OSMTracker en attente de fix GPS.}
|
||
\label{figure:osmtrackerfixgps}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/OSMTrackerPrecision}
|
||
\caption{OSMTracker en fonctionnement.}
|
||
\label{figure:osmtrackerprecision}
|
||
\end{subfigure}
|
||
\caption{OSMTracker}
|
||
\label{figure:osmtracker}
|
||
\end{figure}
|
||
|
||
Une fois le GPS « fixé », l'accès au fonctionnalités d'OSMTracker est déverrouillé et la précision affichées, comme on le voit sur la figure \ref{figure:osmtrackerprecision}.
|
||
|
||
\medskip
|
||
Les possibilités offertes par OSMTracker sont ensuite celles présentés sur la figure \ref{figure:osmtracker}. On y voit différents éléments comme le « Mémo vocal », « Prendre une photo » et « Tourisme ».
|
||
|
||
Normalement, chaque élément devrait permettre de faire le lien entre celui-ci et la trace en cours.
|
||
|
||
Pour « Mémo vocal » par exemple, le code de la trace présentée dans le listing \ref{listing:formatgpx}, page \pageref{listing:formatgpx}, montre qu'il est bien enregistré directement dans la trace, comme la balise \verb|<name>| du way point \verb|<wpt>| le montre.
|
||
|
||
Pour « Prendre une photo », il est intéressant de noter ici que la version d'OSMTracker pour le système d'exploitation \emph{Eilo e.} (sur un Fairphone 2) lance bien l'appareil de photo \emph{OpenCamera}, mais qu'une erreur est retournée disant qu'il est impossible de prendre la photo. Il s'agit probablement d'un bug d'OSMTracker pour cet OS et cela permet de se rendre compte que toutes les fonctionnalités ne sont pas toujours présentes.
|
||
|
||
Enfin, le bouton « Tourisme », donne accès à la fenêtre présentée à la figure \ref{figure:osmtrackertourisme} et qui permet de « géotaguer » différents élements comme les points de vue, les places de pique-nique, des monuments \dots
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/OSMTrackerTourismeElements}
|
||
\caption{Éléments du menu Tourisme.}
|
||
\label{figure:osmtrackertourisme}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/OSMTrackerTraces}
|
||
\caption{Menu des traces.}
|
||
\label{figure:osmtrackertraces}
|
||
\end{subfigure}
|
||
\caption{OSMTracker}
|
||
\label{figure:osmtrackermenus}
|
||
\end{figure}
|
||
|
||
Enfin, sur la figure \ref{figure:osmtrackertraces}, on voit en arrière plan l'affichage de la liste des traces déjà enregistrées, avec en avant plan différentes actions réalisables sur celles-ci. Outre le fait de pouvoir arrêter et reprendre l'enregistrement, remarquez la possibilité d'exporter la trace sous la forme d'un fichier GPX et celle de l'envoyer directement sur Openstreetmap.
|
||
|
||
\subsubsection{Représentation de la trace}
|
||
Le relevé de tous ces éléments permet de visualiser la trace du déplacement réalisé. Pour cela, il faut évidemment un fond de carte, OSM par exemple, mais aussi charger le fichier GPX de la trace dans QGIS par exemple. Il est aussi possible de le faire directement dans OSM évidemment.
|
||
|
||
\medskip
|
||
Voyons donc comment procéder dans QGIS.
|
||
|
||
Tout d'abord, il est nécessaire d'activer le module préinstallé de QGIS qui permettra d'importer la trace GPX. Celui-ci se trouve dans les extensions et se nomme \emph{Outils GPS}. Une fois trouvé, il faut cocher d'un petit vu la case en regard de son icône pour l'activer. Ainsi, il apparaîtra dans la barre latérale verticale tout à gauche de l'interface de QGIS un bouton nommé \emph{Outils GPS} (et un autre nommé \emph{Créer une nouvelle couche GPS} au-dessus). En cliquant sur ce bouton, un onglet nommé \emph{Charger un fichier GPX} se présentera vous permettant de sélectionner le fichier en question et de choisir les entités à charger : Points (Waypoints), Itinéraires (Routes) et Voies (Tracks).
|
||
|
||
La figure \ref{figure:rondeqgis} présente le résultat de cet import.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/RondeQGIS}
|
||
\caption{Import d'un fichier GPX dans QGIS.}
|
||
\label{figure:rondeqgis}
|
||
\end{figure}
|
||
|
||
On y voit, tout à gauche et tout en bas, le bouton d'import des outils GPS (juste en-dessous de celui de la saisie de coordonnée qui est sélectionné).
|
||
|
||
En regard des ces deux boutons, se trouvent les couches présentes au nombre de quatre : Ronde, waypoints, Ronde, routes, Ronde, tracks et OSM Standard.
|
||
|
||
Tout à l'opposé, en vert foncé, marqué de quelques étoiles rouges, la trace du déplacement.
|
||
|
||
Et au centre, un outil obtenu en cliquant à droite sur la couche Ronde, waypoints et en choisissant \emph{Ouvrir la table d'attributs}. Cet outil permet de voir les données associées à la trace qui se trouvent dans le fichier GPX. À l'ouverture de l'outil, c'est une table qui se présente. En cliquant sur le petit carré bleu en bas à droite de la fenêtre, on peut \emph{Basculer sur la vue formulaire} qui permet de voir les mêmes données mais sous une forme quelque peu plus lisibles.
|
||
|
||
\smallskip
|
||
On y voit treize \emph{waypoints} qui sont des éléments supplémentaires à la couche de la trace elle-même Ronde, tracks. Ces éléments sont représentés sur la trace par des étoiles rouges (le choix de ce symbolisme se fait dans la fenêtre des propriétés de la couche Ronde, waypoints).
|
||
|
||
Il est intéressant de noter que le point dont les éléments figurent à droite avec en particulier le nom \emph{Memo vocal}, correspond au quatrième mémo vocal présent sur la liste de gauche et que, comme on ne le voit pas entièrement dans les champs \emph{comment} et \emph{description}, figurent la précision, la valeur du compas intégré (compass heading) et la précision du compas (compass accuracy).
|
||
|
||
Par contre, ne figurent pas dans cette précision la localisation, c'est-à-dire la longitude et la latitude, des points. Pourtant ces indications figurent dans le fichier de traces, comme on peut le savoir en raison de la présence des points sur la trace, mais aussi en consultant le contenu même du fichier GPX présenté dans la figure \ref{listing:formatgpx}, page \pageref{listing:formatgpx}. Cela est évidemment lié aux décisions ergonomiques prises par QGIS qui situent le placement des points dans l'interface graphique de la carte et non au niveau de la base de donnée associée. C'est d'ailleurs la raison pour laquelle la table d'attributs de la couche Ronde, tracks est vide.
|
||
|
||
\subsubsection{Modification de la trace}
|
||
Se pose maintenant la question de la modification de la trace. En effet, non seulement en raison du petit bug d'OSMTracker mentionné plus haut, les photos ne sont pas géotaguées, mais il pourrait être intéressant d'utiliser une symbologie particulière en fonction de la nature des éléments tagués.
|
||
|
||
\smallskip
|
||
La première étape à réaliser pour pouvoir manipuler les éléments de la trace est de convertir la couche des \emph{waypoints} en une couche en permettant la modification. En effet, la couche créée par l'outil GPS ne permet pas de modifications.
|
||
|
||
Pour cela, il faut cliquer à droite sur la couche Ronde, waypoints et choisir \emph{Enregistrer sous\dots}. Plusieurs formats de couches sont alors disponibles. L'un des formats, intéressant parce que très répandu et facilement échangeable, est \emph{ESRI Shapefile}. Vous pouvez le choisir et lui donner un nom de fichier. Normalement, le SCR (Système de Coordonnée par Défaut) par défaut est présélectionné. Enfin, il faut ajouter les fichiers sélectionnés à la carte et valider.
|
||
|
||
Ainsi, une couche supplémentaire apparaît et il devient possible de modifier ou d'ajouter des points.
|
||
|
||
Par exemple, sur la figure \ref{figure:rondeculpre}, on voit comment joindre deux traces visuellement.
|
||
|
||
Sur la figure \ref{figure:rondeculpregpxqgis} sont visibles les couches GPX, non modifiables, directement importée de l'unique fichier créé par la fusion de trois traces. Remarquez que la fusion de ces trois fichiers GPX n'a pas vraiment joint les traces, même si elle a mis l'ensemble des données dans un seul fichier. En effet, on voit clairement au niveau du lac que les traces sont disjointes. Travailler sur les deux couches GPX des traces et des waypoints ne permet pas de joindre graphiquement les chemins.
|
||
|
||
Il faut donc enregistrer ces deux couches dans deux nouvelles couches au format ESRI Sahpefile, comme décrit précédemment. On obtient alors les deux couches modifiables présentées à la figure \ref{figure:rondeculpreesriqgis}. On voit sur celle-ci que les traces sont alors décomposée en une multitude de points de mesure joints par des segments sauf au niveau du lac où les traces ne sont pas jointives.
|
||
|
||
On voit aussi sur la figure \ref{figure:rondeculpretable} que la table des waypoints est maintenant liée aux points situés sur la carte. En effet, à l'élément sélectionné par un point jaune dans la table, correspond le point mis en valeur par la couleur jaune, ici situé au milieu du lac.
|
||
|
||
Par ailleurs, ce point au milieu du lac est le dernier de la trace située à droite de la figure. Évidemment, sa position est due à l'incertitude du GPS et il devrait correspondre au premier point de la trace suivante. Il est donc nécessaire non seulement de déplacer ce point à proximité du premier point de la trace suivante, mais aussi de fusionner l'extrémité de la trace de gauche, représentée par une petit croix rouge sur avec le début de la trace de droite. Pour cela les outils de déplacement et de fusion de chemins sont nécessaires. Nous n'entrerons pas ici dans le détail de ces modifications.
|
||
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.48\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/RondeCulPreGPXQGIS}
|
||
\caption{Couche GPX}
|
||
\label{figure:rondeculpregpxqgis}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.48\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/RondeCulPreESRIQGIS}
|
||
\caption{Couche ESRI Shapefile}
|
||
\label{figure:rondeculpreesriqgis}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.48\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/RondeCulPreTable}
|
||
\caption{Table des waypoints}
|
||
\label{figure:rondeculpretable}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.48\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/RondeCulPreCorrige}
|
||
\caption{Repositionnement de noeuds}
|
||
\label{figure:osmtrackertraces}
|
||
\end{subfigure}
|
||
\caption{Modification de traces}
|
||
\label{figure:rondeculpre}
|
||
\end{figure}
|
||
|
||
\smallskip
|
||
La seconde étape à réaliser concerne les images. Pour pouvoir les positionner sur la carte, il est nécessaire d'en connaître les coordonnées.
|
||
|
||
Celles-ci sont contenues dans les métadonnées des images.
|
||
|
||
\subsection{Outils de positionnement}\label{section:outilsdepositionnement}
|
||
\subsubsection{Introduction}
|
||
Quand on fait de la cartographie, il est naturel à un moment où à un autre de s'intéresser à un positionnement absolu. Il s'agit d'une longue histoire qui passe par les méthodes de détermination de la latitude, puis évidemment du célèbre problème de la longitude.
|
||
|
||
L'apparition du positionnement satellite nous intéresse ici dans le cadre de la cartographie. Or, dans ce cas, des problèmes spécifiques comme celui de l'évaluation de la précision, apparaissent et ils peuvent être à l'origine de découvertes qui peuvent intéresser des étudiants et mener à des expériences pratiques instructives.
|
||
|
||
\subsubsection{Positionnement}
|
||
Pour poser le problème de manière très pragmatique, nous avons utilisé un smartphone (sous Fairphone OS) et trois applications, soit GPSTest, Here GPS Location et Phyphox, pour effectuer trois mesures de position au parc Gallet. L'idée est de se positionner précisément en un point connu et de faire les trois mesures sans en bouger. Ainsi, le kiosque à musique du parc, l'intersection de trois chemins et le coude de l'un d'eux ont été choisis pour cela. La figure \ref{figure:gpsmesurestout} montre en rouge les points choisis et en bleu les mesures.
|
||
\begin{figure}
|
||
\centering
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_Mesures_TOUT.eps}
|
||
\caption{L'ensemble des points.}
|
||
\label{figure:gpsmesurestout}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_Mesures_Kiosque.eps}
|
||
\caption{Les mesures du kiosque.}
|
||
\label{figure:gpsmesureskiosque}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.5\textwidth}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/GPS_Mesures_Centre.eps}
|
||
\caption{Les mesures des chemins.}
|
||
\label{figure:gpsmesurescentre}
|
||
\end{subfigure}
|
||
\caption{Mesures GPS avec GPSTest, Here GPS Location et Phyphox.}
|
||
\label{figure:mesuresgps}
|
||
\end{figure}
|
||
En premier lieu, il est intéressant de constater que les mesures sont assez éloignées des points cartographiés et que ces éloignements ne sont pas systématiquement dans une direction privilégiée. On a donc pas à faire à une erreur systématique du GPS.
|
||
|
||
Ensuite, la figure \ref{figure:gpsmesureskiosque} montre les trois mesures réalisées en se trouvant exactement au centre du kiosque. La référence est donc un bâtiment dont la position devrait être précise, puisque probablement tracé à partir d'une image satellite de celui-ci. On remarque que la mesure la plus près de ce point est celle réalisée avec Phyphox. Nous y reviendrons. Pour les deux autres mesures, elles sont tout de même éloignées de plusieurs mètres.
|
||
|
||
Enfin, la figure \ref{figure:gpsmesurescentre} montre deux point dont le positionnement cartographique est mal assuré, puisque il a été obtenu par estimation visuelle. Mais, on voit que les écarts sont importants et, à nouveau, que c'est Phyphox qui s'en sort le mieux.
|
||
|
||
\medskip
|
||
La raison pour laquelle Phyphox s'en sort relativement bien semble être due au fait que dans les trois cas, la mesure effectuée avec lui a duré 300 secondes, soit cinq minutes, alors que pour les autres mesures, celles-ci ont duré moins de trente secondes.
|
||
|
||
On peut comprendre cela en regardant les graphes de l'évolution des mesures faites avec Phyphox. La figure \ref{figure:zonejeuparcgallet} présente l'évolution des mesures GPS de latitude et longitude derrière la zone de jeu principale du parc Gallet.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/KiosqueAMusiqueParcGalletSimple.eps}
|
||
\caption{Positionnement au parc Gallet.}
|
||
\label{figure:zonejeuparcgallet}
|
||
\end{figure}
|
||
On voit que le facteur temps est très important pour obtenir une bonne mesure GPS. Il s'agit du point le plus à gauche visible sur la figure \ref{figure:gpsmesurescentre}.
|
||
|
||
\medskip
|
||
Le problème du positionnement d'une référence de positionnement de la carte est donc posé en même temps que celui de la précision du GPS. Pour tenter d'obtenir une première réponse à ces deux questions, il faut en premier lieu une référence géographique incontestable. Dans la région du parc Gallet, celle-ci a été trouvée au plus haut point aux alentours de la Chaux-de-Fonds, soit sur la colline de Pouillerel où se trouve une borne cadastrale. En plaçant le smartphone sur celle-ci, juste sur la borne et au-dessous de la pointe maquant le sommet, une mesure de cinq minutes a été réalisée avec Phyphox. Le résultat est présenté à la figure \ref{figure:pouillerel}. L'échelle est la plus petite possible sur OSM et on voit que l'écart entre la mesure et la position du sommet est très faible (pour autant que le calage de la carte sur la borne soit très précis).
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/Pouillerel.eps}
|
||
\caption{Positionnement sur la borne de Pouillerel}
|
||
\label{figure:pouillerel}
|
||
\end{figure}
|
||
Les mesures relatives à ce positionnement sont présentées à la figure \ref{figure:pouillerelgraphe}. On constate qu'il faut bien une minute avant que celles-ci ne soient stables et de bonne qualité. Il faut relever que celles-ci ont été obtenues avec un ciel très dégagé, sans aucun arbres à proximité, contrairement aux mesures effectuées au parc Gallet.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/PouillerelGraphe.eps}
|
||
\caption{Mesures GPS à Pouillerel}
|
||
\label{figure:pouillerelgraphe}
|
||
\end{figure}
|
||
On voit donc que non seulement le temps de mesure est important dans la détermination des coordonnées GPS, mais le dégagement du ciel le semble tout autant.
|
||
|
||
\medskip
|
||
Par ailleurs, il faut aussi relever qu'avec un ciel dégagé d'arbres et en étant en mouvement, la position GPS était d'assez bonne qualité pour que l'utilisation de traces permette un relevé très correct des chemins piétons. Il est donc nécessaire d'explorer plus avant les possibilités d'utilisation des traces dans OSM.
|
||
|
||
\medskip
|
||
Il est aussi mentionné sur internet qu'un autre facteur puisse encore influencer la qualité d'une mesure GPS. Il s'agit de la proximité du serveur de temps utilisé par le smartphone. Malheureusement, malgré la publicité faite autour du Fairphone informant du fait qu'il peut être « rooté » sans difficultés, après plusieurs essais avec un Fairphone 2, il n'a pas été possible de le faire. En conséquence de quoi, il n'a pas été possible de spécifier le serveur de temps utilisé, puisque pour cela un accès root est nécessaire.
|
||
|
||
\subsubsection{Décalages}
|
||
Avec JOSM comme avec Merkaartor, il est possible de superposer la carte d'OSM à une vue satellite du lieu. Dans le cas d'arbres, celle-ci est généralement inutile, car le couvert forestier ne permet alors pas une cartographie correcte au sol. Cela constitue un problème que des mesures relative de distance au sol permettent de résoudre. Mais un autre problème peut mener à y avoir recours. Il s'agit du décalage de l'image satellite avec la carte OSM. Ce décalage est du a différentes raisons et l'utilisation de méthodes comme celle des traces permet d'y remédier, comme le précise l'article \url{https://wiki.openstreetmap.org/wiki/FR:Utilisez\_l\%27imagerie} du wiki d'OSM. Ce décalage est un réel problème puisqu'il dépend de plusieurs facteurs qui ne permettent pas toujours de décaler l'image satellite pour qu'elle corresponde partout à la position de l'ensemble des bâtiments.
|
||
|
||
Sur la figure \ref{figure:decalage}, on peut se rendre compte de la situation pour des bâtiments autour de la gare de La Chaux-de-Fonds.
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/Decalage.eps}
|
||
\caption{Décalage de l'image satellite}
|
||
\label{figure:decalage}
|
||
\end{figure}
|
||
|
||
\medskip
|
||
En conclusion, on peut clairement dire que l'utilisation du GPS, sans y adjoindre des corrections obtenues soit par GPRS, soit par Wifi, nécessite du temps, un ciel dégagé et éventuellement du mouvement. Le positionnement relatif reste donc un outil très important pour le positionnement des objets cartographiques et les méthodes qui y sont associées, avec au premier rang des quelles la triangulation (voir annexe \ref{sec:triangulation}), doivent impérativement être explorées.
|
||
|
||
\subsection{Triangulation}\label{sec:triangulation}
|
||
Les méthodes actuelles et passées de positionnement relatif sont essentiellement basées sur la triangulation. Encore aujourd'hui, malgré la télémétrie laser, on utilise des téodolites laser pour effectuer ce genre de mesures. Or, ces téodolites sont très chers et clairement hors de portée d'un particulier.
|
||
|
||
Avec l'avènement des smartphones, il existe cependant aujourd'hui des solution intéressantes. Nous allons considérer ici le logiciel \emph{Trail-Sense}. Il s'agit d'un logiciel libre sous licence MIT\footnote{Voir : \url{https://github.com/kylecorry31/Trail-Sense} et pour la politique de confidentialité \url{https://kylecorry.com/Trail-Sense/privacy_policy.html}} qui possède de multiples fonctionnalités intéressantes.
|
||
|
||
\section{Imagerie satellitaire}
|
||
Cette section est une introduction à l'imagerie satellitaire. QGis est au centre de cette découverte qui a pour objectif de présenter ses possibilités de superposition d'information météorologique, océanographiques, \dots{} On peut ainsi imaginer faire travailler des élèves sur différentes situations météorologiques pour leur permettre d'apprendre à lire des cartes météo ou leur faire découvrir les fond océaniques pour étudier les plaques tectoniques.
|
||
|
||
Par ailleurs, beaucoup de problèmes caractéristiques à la fois de la construction de l'information géographique, des droits sur celle-ci ou de la gestion informatique des éléments cartographiques, étant présents dans l'imagerie satellitaire, l'apprentissage de son utilisation est un exercice particulièrement pertinent à tout les points de vue.
|
||
|
||
\subsection{Introduction}
|
||
Le premier problème auquel l'étudiant va être confronté est simplement de savoir où trouver des images satellites. Il peut sembler évident, dans une société où l'image du monde est omniprésente, qu'on puisse en disposer sans difficultés. Or, ce n'est pas le cas. Il est même difficile d'y parvenir dans la mesure où on ne se satisfait pas de la représentation de Google Map et qu'on désire obtenir des images aux contenus particulier, comme l'état des sols ou si on désire maitriser les droits sur ces images.
|
||
|
||
Pour se rendre compte de ces problèmes, le site du \og Global Investigative Journalism Network \fg{} publie un \og Guide pour trouver et utiliser des images satellites \fg\footnote{gijn.org : \url{https://gijn.org/guide-pour-trouver-et-utiliser-des-images-satellites/}} qui, malgré son orientation vers l'utilisation journalistique des images, constitue une bonne entrée en matière.
|
||
|
||
Cet article donne aussi des motivations intéressantes à l'utilisation des images satellites~:
|
||
\begin{quotation}
|
||
\og Les images satellites sont de puissants outils de découverte et d’analyse, et permettent également d’illustrer de manière très précise une enquête. Les journalistes utilisent déjà les images satellites pour des reportages dans des zones de conflit, sur le changement climatique, les réfugiés, les feux de forêts, l’exploitation minière illégale, les marées noires, la déforestation, l’esclavage et de nombreux autres sujets. Dans le cadre du journalisme d’investigation, le potentiel de l’exploitation de ces images venues de l’espace est également considérable.\footnote{gijn.org : \url{https://gijn.org/guide-pour-trouver-et-utiliser-des-images-satellites/}}\fg
|
||
|
||
\medskip
|
||
Le deuxième problème auquel l'étudiant va être confronté est d'obtenir des informations sur les images qu'il va trouver, notamment la date et l'heure à laquelle elles ont été prises et leur licence.
|
||
|
||
\medskip
|
||
Le troisième problème auquel l'étudiant va être confronté est de savoir comment utiliser les images qu'il a trouvée et, s'il peut disposer de plusieurs formats, le ou lesquels choisir.
|
||
\end{quotation}
|
||
|
||
\subsection{Des profondeurs à la canopée}
|
||
Commençons par un exemple en en présentant le résultat à la figure \ref{figure:profondeurscanopee}.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/profondeursCanopee.eps}
|
||
\caption{Des profondeurs à la canopée.}
|
||
\label{figure:profondeurscanopee}
|
||
\end{figure}
|
||
|
||
Il s'agit d'une carte mondiale présentant trois informations distinctes~:
|
||
\begin{enumerate}
|
||
\item les profondeurs océaniques,
|
||
\item les reliefs continentaux et
|
||
\item la canopée mondiale.
|
||
\end{enumerate}
|
||
|
||
Il s'agit, comme le montre la figure \ref{figure:profondeurscanopee} dans l'onglet couches en bas à gauche de l'image, d'une composition des trois couches nommées \og GLAD Tree Canopy Height 2020 \fg{}, \og World Imagery \fg{} et \og World\_Ocean\_Base \fg{}.
|
||
|
||
En premier lieu, il est intéressant de constater que ce trois couches semblent très bien se marier et cela dans l'ordre dans lesquelles elles se présentent. Il faut ensuite constater qu'en changeant l'échelle de la carte (en zoomant), tout se passe très bien et l'image reste de très bonne qualité comme on peut le constater en comparant les images des figures \ref{figure:profondeurscanopee}, \ref{figure:europetroiscouches} et \ref{figure:suissetroiscouches}.
|
||
\begin{figure}[h]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/Europe.eps}
|
||
\caption{L'Europe avec trois couches}\label{figure:europetroiscouches}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/Suisse.eps}
|
||
\caption{La Suisse avec trois couches}\label{figure:suissetroiscouches}
|
||
\end{subfigure}
|
||
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/SuisseMontagnes.eps}
|
||
\caption{La Suisse sans la couche canopée}\label{figure:suissesanscanopee}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/golfeGascogne.eps}
|
||
\caption{Golfe de Gascogne, couche océanique}\label{figure:golfegascogne}
|
||
\end{subfigure}
|
||
\caption{Échelles et couches}
|
||
\end{figure}
|
||
|
||
En second lieu, il faut remarquer l'intérêt de pouvoir n'afficher que certaines couches, comme le montre les figures \ref{figure:suissesanscanopee}, qui présente la Suisse sans la couche de la canopée et \ref{figure:golfegascogne} qui présente le golfe de Gascogne avec la seule couche \og World\_ocean\_base \fg{}.
|
||
|
||
Il est manifeste que la couche de la canopée se superpose avec transparence à la couche du monde. La figure \ref{figure:couchecanopee} montre la canopée, mais sans les reliefs sous-jascents. La transparence est évidente.
|
||
|
||
Par contre, la figure \ref{figure:coucheworld} n'est constituée que de la seule couche \emph{World\_Imagery} décrite plus bas. Or, on y voit les reliefs sous-marins et en affichant la carte sous-jascente des fonds sous-marins, rien ne change. La carte du monde se superpose ainsi sans transparence à celle de fond marins.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/Canopee.eps}
|
||
\caption{La couche de la canopée.}\label{figure:couchecanopee}
|
||
\end{subfigure}
|
||
\begin{subfigure}{0.45\textwidth}
|
||
\includegraphics[width=\textwidth]{images/Profondeurs.eps}
|
||
\caption{La couche \emph{World}}\label{figure:coucheworld}
|
||
\end{subfigure}
|
||
\caption{Les couches principales}
|
||
\end{figure}
|
||
|
||
Il existe ainsi plusieurs types de cartes dont les possibilités de superposition sont très différentes.
|
||
|
||
\bigskip
|
||
La réalisation de ces cartes dans QGIS passe donc par la recherche des cartes, celle de l'information les concernant, par leur construction et en fin de compte par leur interprétation.
|
||
|
||
\subsubsection{Acquisition des cartes}
|
||
QGIS dispose d'un plugin permettant d'obtenir relativement facilement des cartes de fond. Il s'agit de \og QuickMapServices \fg{} (QMS). L'installation de celui-ci permet d'obtenir via le menu Internet, sous QuickMapServices et l'item Search QMS, le panneau de recherche QSM qui est présent à droite de l'image sur la figure \ref{figure:profondeurscanopee}. En utilisant le champ de recherche en haut de ce panneau et en choisissant \og Valid \fg{} dans le menu déroulant juste en dessous, on obtient une liste de cartes portant sur des sujets divers. Ces cartes sont liées au niveau de zoom et à la localisation. Il faut donc bien choisir ces grandeurs préalablement à la recherche.
|
||
|
||
Par exemple, pour obtenir la carte de fond, il suffit d'utiliser le mot clé \emph{world} dans le champ de recherche. Apparaissent alors plusieurs cartes dont \emph{Esri World Imagery} et \emph{ESRI Satellite (ArcGIS/World\_Imagery)}. Ces deux cartes permettent de disposer d'une image de fond du monde. La seconde a une résolution légèrement meilleures.
|
||
|
||
\medskip
|
||
Un autre exemple de carte acquise avec le plugin \og QMS est la carte \dots
|
||
|
||
\subsubsection{Informations sur les cartes}
|
||
L'information disponible pour la couche de la canopée l'est directement depuis QGIS. En effet, on voit sur la droite de la figure \ref{figure:profondeurscanopee}, à l'entête de \og Search QMS \fg{} une liste d'items au sein desquels figure le lien \og details \fg{}. Dans le cas de la couche canopée, celui-ci mène sur le site \url{https://qms.nextgis.com}\footnote{Voir : \url{https://qms.nextgis.com/geoservices/3561/}} où on trouve l'information suivante~:
|
||
\begin{quotation}
|
||
\textbf{GLAD Tree Canopy Height 2020}
|
||
|
||
\smallskip
|
||
\textbf{General info}
|
||
|
||
Description: Global Forest Canopy Height, 2019 P. Potapov, X. Li, A. Hernandez-Serna, A. Tyukavina, M.C. Hansen, A. Kommareddy, A. Pickens, S. Turubanova, H. Tang, C. E. Silva, J. Armston, R. Dubayah, J. B. Blair, M. Hofton (2020). A new, 30-m spatial resolution global forest canopy height map was developed through the integration of the Global Ecosystem Dynamics Investigation (GEDI) lidar forest structure measurements and Landsat analysis-ready data time-series (Landsat ARD). The GEDI RH95 (relative height at 95\%) metric was used to calibrate the model. The Landsat multi-temporal metrics that represent the surface phenology serve as the independent variables. The “moving window” locally calibrated and applied regression tree ensemble model was implemented to ensure high quality of forest height prediction and global map consistency. The model was extrapolated in the boreal regions (beyond the GEDI data range, 52°N to 52°S) to create the global forest height prototype map. GEDI: https://gedi.umd.edu Landsat ARD: https://glad.umd.edu/ard/home Data download: https://glad.umd.edu/dataset/gedi
|
||
|
||
Type: WMS
|
||
|
||
CRS: 4326
|
||
|
||
Submitter: glushkov2igor
|
||
|
||
Source: Aucun(e)
|
||
|
||
Date added: 15 septembre 2020 10:23
|
||
|
||
Last update: 17 septembre 2020 15:17
|
||
|
||
Service boundary: none
|
||
|
||
Status: works
|
||
|
||
\smallskip
|
||
\textbf{License \& Copyright info}
|
||
|
||
License name: Creative Commons Attribution 4.0 International License
|
||
|
||
License URL: http://earthenginepartners.appspot.com/science-2013-global-forest/download\_v1.6.html
|
||
|
||
Copyright text: Source: Hansen/UMD/Google/USGS/NASA
|
||
|
||
Copyright URL: Aucun(e)
|
||
|
||
Terms of use URL: Aucun(e)
|
||
|
||
\smallskip
|
||
\textbf{WMS info}
|
||
|
||
URL: https://glad.umd.edu/mapcache/?SERVICE=WMS?LAYER=forest\_height\_2019
|
||
|
||
GET parameters: Aucun(e)
|
||
|
||
Layers: forest\_height\_2019
|
||
|
||
Turn over layers order: False
|
||
|
||
Image format: image/png
|
||
\end{quotation}
|
||
|
||
Ces informations sont très intéressantes et exploitables par les étudiants.
|
||
|
||
\subsubsection{Construction des cartes}
|
||
Comme nous l'avons montré dans la partie principale de ce document, une carte n'est pas une construction neutre. Au mieux, elle donne à voir certains aspects relativement objectifs de la réalité. On peut imaginer les images satellites plus objectives que les cartes symboliques. S'il n'en est en réalité rien en raison des déformations liées à l'imagerie elle-même (on sait que selon la focale, un objectif déforme plus ou moins l'image qu'il produit), certains type d'images satellites peut être très problématique à comprendre. C'est le cas, par exemple, des images de la canopées. En effet, des informations précises sur ce que ces images représentes sont nécessaires pour en saisir convenablement le sens.
|
||
|
||
La figure \ref{figure:canopeechxfds} présente la canopée autour de la ville de la Chaux-de-Fonds.
|
||
\begin{figure}[t]
|
||
\centering
|
||
\includegraphics[width=\textwidth]{images/CanopeeChxFds.eps}
|
||
\caption{La canopée de la Chaux-de-Fonds}
|
||
\label{figure:canopeechxfds}
|
||
\end{figure}
|
||
|
||
Deux couches sont présentes. Le fond est la carte d'OpenStreetMap et la couche supérieure vient des cartes de \emph{Glad Tree Canopy Height 2020}\footnote{Voir le site GLAD (Global Land Analysis \& Discovery)~: \url{https://glad.umd.edu/}}. Qgis, par l'intermédiaire de Search QMS, donne les informations suivantes sur cette couche~:
|
||
\begin{quotation}
|
||
\og \textbf{General info}
|
||
|
||
Description: Global Forest Canopy Height, 2019 P. Potapov, X. Li, A. Hernandez-Serna, A. Tyukavina, M.C. Hansen, A. Kommareddy, A. Pickens, S. Turubanova, H. Tang, C. E. Silva, J. Armston, R. Dubayah, J. B. Blair, M. Hofton (2020). A new, 30-m spatial resolution global forest canopy height map was developed through the integration of the Global Ecosystem Dynamics Investigation (GEDI) lidar forest structure measurements and Landsat analysis-ready data time-series (Landsat ARD). The GEDI RH95 (relative height at 95%) metric was used to calibrate the model. The Landsat multi-temporal metrics that represent the surface phenology serve as the independent variables. The “moving window” locally calibrated and applied regression tree ensemble model was implemented to ensure high quality of forest height prediction and global map consistency. The model was extrapolated in the boreal regions (beyond the GEDI data range, 52°N to 52°S) to create the global forest height prototype map. GEDI: https://gedi.umd.edu Landsat ARD: https://glad.umd.edu/ard/home Data download: https://glad.umd.edu/dataset/gedi
|
||
|
||
Type: WMS
|
||
|
||
CRS: 4326
|
||
|
||
Submitter: glushkov2igor
|
||
|
||
Source: Aucun(e)
|
||
|
||
Date added: 15 septembre 2020 10:23
|
||
|
||
Last update: 17 septembre 2020 15:17
|
||
|
||
Service boundary: none
|
||
|
||
Status: works \fg
|
||
\end{quotation}
|
||
|
||
À part l'explication~:
|
||
\begin{quotation}
|
||
\og Une nouvelle carte de la hauteur de la canopée de 30 mètres de résolution spatiale a été développée par l'intégration de mesures lidar de la structure de la forêt du Global Ecosystem Dynamics Investigation (GEDI) et des séries de données temporelles prêtes pour l'analyse de Landsat (Landsat ARD).\fg
|
||
\end{quotation}
|
||
|
||
aucune explication réelle n'est fournie. Pour obtenir une information plus détaillée, il est nécessaire de se rendre sur le site de GLAD\footnote{Voir~: \url{https://glad.umd.edu/}} et de choisir, parmi les multiples données qu'il fournit (onglet \emph{DATASET}), les \emph{GLAD Landsat ARD Tools}\footnote{Voir~: \url{https://glad.umd.edu/ard/home}}. Une section \emph{Landsat ARD Methodology} permet d'entrevoir comment la carte a pu être partiellement construite. Partiellement, car il s'agit de la partie \emph{Landsat ARD}, qui est utilisée parallèlement à l'analyse lidar du GEDI. Pour des renseignements à ce sujet, il faut se rendre sur le site éponyme du GEDI\footnote{Voir~: \url{https://gedi.umd.edu/}}.
|
||
|
||
\medskip
|
||
La construction d'une carte de la canopée autour de la Chaux-de-Fonds est donc tributaire de recherches de documentation supplémentaire, ne serait-ce que pour obtenir une échelle de couleur permettant de \dots
|
||
|
||
\subsection{Indice de végétation}
|
||
Évidemment,
|
||
|
||
\subsection{Arcgisonline.com}
|
||
fdgfd
|
||
|
||
\subsection{Définition}
|
||
Dans la recherche d'images satellites plusieurs problèmes peuvent survenir~:
|
||
\begin{itemize}
|
||
\item il faut trouver des sites fournissant des images ;
|
||
\item s'il ne s'agit pas simplement de les visionner, il faut que les images puissent être téléchargées pour être intégrées dans un logiciel d'analyse cartographique comme QGIS, mais même si on ne désire que les visionner, comme c'est souvent le cas en météo, il faut pouvoir leur superposer des données spécifiques, comme une représentation des vents ;
|
||
\item si elles sont potentiellement téléchargables, se pose alors la question de leur prix et de leur licence ;
|
||
\item si elles sont accessibles, se pose la question de leur format ;
|
||
\item si elles sont accessibles, se pose la question du spectre électromagnétique utilisé ;
|
||
\item se pose enfin la question de leur définition.
|
||
\end{itemize}
|
||
|
||
Un site très intéressant pour obtenir des images libres, dans le cadre du RGPD européen, est le site du projet Copernicus. Dans sa section de surveillance des terres (\emph{Land Monitoring Service}\footnote{Voir~: \url{https://land.copernicus.eu/fr}}), est spécifié~:
|
||
\begin{quotation}
|
||
\og \textit{Nous fournissons un accès total, gratuit et ouvert aux informations relatives à l’occupation et à l’utilisation des sols aux utilisateurs dans le domaine de l’environnement et d’autres applications terrestres!} \fg
|
||
\end{quotation}
|
||
L'intérêt pour les images fournies sur Corpernicus est donc important. L'inscription est conforme au RGPD et seuls les éléments nécessaires sont demandés. Cependant, comme Copernicus fournit plusieurs prestations, comme des images terrestres, des images maritimes, \dots, il est nécessaire de s'inscrire plusieurs fois, car il n'existe pas de compte valable pour toutes celles-ci.
|
||
|
||
À partir du moment où l'inscription est réalisées, il est ensuite possible d'intégrer le téléchargement des images à l'intérieur de QGIS de plusieurs manières.
|
||
|
||
\dots
|
||
|
||
Pour le dernier point, il est intéressant d'appréhender ce qu'est une image en très haute résolution. Pour cela, une couche raster de type WMS (Web Map Service), provenant du serveur WMS de Copernicus (à l'adresse~: \url{https://copernicus.discomap.eea.europa.eu/arcgis/services/GioLand/VeryHighResolution2012/MapServer/WMSServer?version=1.3.0 }) a été superposée au parc Gallet. La figure \ref{figure:parcgallethd} présente l'image récupérée à l'adresse \url{https://copernicus.discomap.eea.europa.eu/arcgis/services/GioLand/VeryHighResolution2012/MapServer/WmsServer?} en très haute résolution (détails de 2,5 m) du parc Gallet.
|
||
\begin{figure}
|
||
\centering
|
||
\includegraphics[width=0.8\textwidth]{images/ParcGalletHD.eps}
|
||
\caption{Image en très haute résolution du parc Gallet.}
|
||
\label{figure:parcgallethd}
|
||
\end{figure}
|
||
|
||
\end{document}
|