1596 lines
167 KiB
TeX
1596 lines
167 KiB
TeX
\documentclass[11pt,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{} \citep{MM2019} consacré au sujet\footnote{Dans \citet*[p. 129]{NL2017}, se trouve un commentaire de l'ouvrage de \citet*{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{} \citep{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 \citep{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 \citep{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 \citep{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{} \citep{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 \citet*{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 \citep[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 \citet*[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 \citet*[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 \citet*{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 \citet*[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 \citep[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 \citep[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=11cm]{images/modeleSol.eps}
|
||
\caption{Modèle sol \citep[pp. 42-43]{FA2019}}\label{modelesol}
|
||
\end{subfigure}
|
||
|
||
\medskip
|
||
\begin{subfigure}{\textwidth}
|
||
\centering
|
||
\includegraphics[width=11cm]{images/carteSol.eps}
|
||
\caption{Carte sol \citep[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 \citet*[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 \citep[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.} \citep[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 \citet*{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 \citet*{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 \citet*[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.} \citep[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 \citep{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{} \citep{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,...). \citet*{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 \citep{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 \citet*{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{} \citep{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{} \citep{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 \citep{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{} \citep{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 \citep{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 \citet*[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 \citet*[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{*}
|
||
\bibliographystyle{apalike-fr}
|
||
%\bibliographystyle{apacite}
|
||
\bibliography{geographie-informatique}
|
||
|
||
\newpage
|
||
\appendix
|
||
|
||
\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/carteLelbc3.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.
|
||
|
||
\subsection{Le code complet}
|
||
Voici finalement 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:horsligne},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}[top]
|
||
\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.
|
||
|
||
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}[c]
|
||
\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. 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}.
|
||
|
||
\begin{lstlisting}[float,language=shell,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 .
|
||
|
||
\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}.
|
||
|
||
\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}
|
||
\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 est évidemment difficile de faire de la cartographie sur un téléphone portable. Par contre, avec une tablette, cela est tout-à-fait possible avec Vespucci. C'est un éditeur qui n'est pas tout à fait évident à utiliser et compte tenu de cette difficulté, il vaut mieux ne pas faire de cartographie avec cet éditeur sans être passé par une bonne connaissance des autre précédemment. De plus, au début, l'utilisation d'un éditeur hors ligneavec 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, il est tout de même envisageable de l'utiliser dans un second temps puisque, comme on peut le voir sur la figure \ref{figure:vespucci3}, en mode déverrouillé, la gestion du mode tactile propre au smartphones est bien prise en charge.
|
||
|
||
\begin{figure}
|
||
\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}
|
||
|
||
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{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.
|
||
|
||
\end{document}
|