Première partie d'une trilogie consacrée à un gros travail de cartographie réalisé pour Rue89Strasbourg. Au programme pour commencer : comment gagner un maximum de temps sur QGis.
Je me suis lancé il y a quelques semaines dans un projet assez costaud : réaliser une cartographie électorale d'une énorme zone, en prenant comme références plus de 9 000 communes. Pour cela, je me suis servi de deux stocks de données gratuits :
Une fois le tri fait sur les communes que je souhaitais garder pour la future visualisation, je suis passé à l'étape QGis, du nom de cet excellent logiciel de cartographie distribué sous licence GNU.
Je m'attendais à devoir faire quelques modifications pour générer un .shp réutilisable, mais beaucoup de petites choses se sont accumulées et m'ont fait perdre un maximum de temps. J'en répertorie quelques-unes, en espérant que cela puisse resservir à quelqu'un.
Le pénible chemin des vers des syntaxes identiques
Ça a été le principal pépin au début : arriver à rassembler deux fichiers parlant de la même choses, mais pas forcément de la même façon...
Utiliser des fichiers en UTF-8
La première joyeuseté fut de voir des noms de communes avec accents ressembler à du yaourt à cause d'un mauvais codage. Pour se simplifier la vie, commencez par réenregistrer les fichiers non modifiés en UTF-8, ce sera déjà ça de pris.
Harmoniser les noms entre les fichiers
Avant d'espérer faire une carte interactive que chaque tracé communal d'OSM soit rattaché aux données de data.gouv. Sauf que les noms répertoriés chez OSM ne sont pas forcément écrits de la même façon que les noms du fichier fourni par l'administration.
Plusieurs raison à cela :
- certaines règles de nomenclature. Par exemple, la commune "Les Bouchoux" sur OSM sera noté "Bouchoux (Les)" dans le fichier de données, ou encore certains noms de commune à rallonge ne seront pas écrits avec des tirets dans l'un des fichiers. Et la correspondance ne se fera évidemment pas
- des erreurs de saisie ou des noms incomplets. Par exemple, le fichier OSM a noté la commune "Waldighofen", alors que la bonne orthographe est "Walidghoffen". Après avoir tout corrigé, je dois reconnaître que c'est bien le fichier OSM qui présentait le moins d'erreurs ou d'imprécision
Ces erreurs se détectent facilement lors de la jointure avec une base de données en .csv (je reviendrai sur la manip' plus loin) car les valeurs qui devraient s'afficher à côté des communes sont notés "NULL" dans la table d'attributs.
C'est donc que la correspondance ne s'est pas faite, et que les noms entre les fichiers sont différents.
Je n'ai pas d'autre méthode que de tout corriger, patiemment à la main, sur le fichier où se trouve l'erreur. Ce qui est évidemment fastidieux...
Chasser les doublons
Même à la fin, il restait forcément des doublons. Or, pour l'avoir constaté, QGis ne s'embête pas : il choisit au hasard l'un des éventails de valeurs d'une commune, et le duplique sur le doublon. On perd donc des informations, ce qui n'est évidemment pas l'objectif.
Du coup, en cas de doublons, il faut veiller à bien les différencier. Personnellement, j'ai ajouté dans mon fichier OSM et mon fichier administratif, le numéro de département entre parenthèses après la commune qui comptait le moins d'inscrits.
Quelques manip' bien utiles sur QGis
Nous avons maintenant deux fichiers qui parlent de la même chose de la même façon. C'est plutôt bien, mais il y a encore quelques trucs à peaufiner. Voici quelques astuces sur le logiciel QGis pour gagner encore un peu plus de temps.
Fusionner plusieurs shapefiles en un
Première étape : on a les tracés communaux de chaque département dans un .shp propre, et on aimerait tous les rassembler en un.
Il suffit d'ouvrir tous les .shp dans QGis, de les sélectionner dans la zone de gauche, puis d'aller dans > Vecteur > Outils de gestion de données > Fusionner les shapefiles en un seul.
Cliquez sur l'image pour l'agrandir
Une fois ceci fait, il ne reste plus qu'à choisir un dossier d'origine où sont rangés les .shp à fusionner, et un dossier de destination avec le nom du nouveau fichier.
En quelques secondes, le .shp nouveau est arrivé 
!
Fusionner des entités en une seule
Le fichier d'OSM répertorie les limites communales de 2013. Seulement, il arrive que certaines de ces communes aient par le passé été fusionnées à d'autre, voire défusionnées.
Autrement dit, des données de 2009 peuvent avoir des communes en moins que celles de 2013 à cause de ces enjeux locaux.
Comment faire pour rassembler deux tracés voisins pour n'en faire plus qu'un seul ? Il faut d'abord sélectionner la couche .shp sur la zone de gauche, et la basculer en mode Edition (le bouton représentant un crayon).
Ensuite, il faut ouvrir la table d'attributs (> clic droit sur la couche .shp > Ouvrir la table d'attributs), sélectionner le premier tracé, puis le second en restant bien appuyé sur la touche Ctrl.
On peut vérifier que les deux entités ont bien été sélectionnées directement sur la carte. Elles doivent être colorées en jaune.
Cliquez sur l'image pour l'agrandir
On va alors dans > Editer > Fusionner les attributs des entités sélectionnées pour se retrouver sur les options suivantes.
Cliquez sur l'image pour l'agrandir
Dans Fusion, il ne reste plus qu'à mettre le nom de la nouvelle entité, d'appuyer sur OK, et le tour est joué.
Cliquez sur l'image pour l'agrandir
Joindre une couche .shp à un fichier .csv
On s'approche tout doucement de notre .shp final, il ne reste plus qu'à placer les données dans le couche .shp.
Pour cette manipulation, on va utiliser un fichier .csv (bien sauvegardé en UTF-8 :-)) qui va inclure une colonne de commune dont chaque nom correspond précisément à chaque nom d'entité du fichier .shp.
On ouvre dans QGis le .shp et on fait glisser le .csv dans la même zone. Il ne reste plus qu'à double cliquer sur notre couche .shp, à aller dans l'onglet Jointure, à cliquer sur la croix verte et ensuite à choisir la bonne colonne de référence.
Voici l'illustration correspondante :
Cliquez sur l'image pour l'agrandir
Il ne reste plus qu'à vérifier dans notre table d'attributs que tout s'est bien passé.
Cliquez sur l'image pour l'agrandir
¡ Vale ! Aucune encombre, on peut donc enregistrer cette couche .shp customisée en nouvelle couche .shp via > clic droit > Sauvegarder sous.
On choisit le format Esri Shapefile, et surtout on exporte le tout en UTF-8.
Transformer une colonne Texte en une colonne Nombre
Dernière joyeuseté, et non des moindres : après la jointure, le .shp contient des colonnes Texte là où il devrait y avoir des colonnes Nombre. On a beau être certains que les colonnes du .csv étaient bien formatées comme des nombres cela ne change rien.
Et un problème arrive vite : quand on trie les résultats, une valeur comme 9,25 se trouve supérieure à une valeur comme 63,47. Pas terrible... Heureusement, on peut facilement transformer sur QGis une colonne à partir d'une autre.
Pour cela, on bascule en mode Edition (icône de crayon) et > clic > Ouvrir la table des attributs. De là, on clique sur l'option Ouvrir la calculatrice de champ, en haut tout à droite.
Cliquez sur l'image pour l'agrandir
De là, on peut créer une nouvelle colonne à partir d'une déjà présente.
Il suffit de choisir un format de colonne (rappel : un nombre avec décimales doit être formaté en real, pas en integer), de lui donner un nom et d'écrire une ligne de conversion, comme ci-après :
Cliquez sur l'image pour l'agrandir
Dans l'exemple, on va créer une colonne "Inscrits" en transformant en nombre entier les valeurs de la colonne europ_20_1. Une fois créée, on peut trier les valeurs de cette nouvelle colonne pour vérifier qu'elles sont (enfin) bien rangées !
Pour ma part, j'ai dû à chaque colonne créée, refermer et réouvrir ma couche .shp pour avoir effectivement des conversions en nombre sur les transformations suivantes. Ça ne doit être qu'un bug, mais je préfère le signaler.
Les limites techniques
Il y a forcément des limites dans le cas décrit précédemment. Voici celles que j'ai relevées :
- on peut fusionner des entités, mais pas obtenir les anciens tracés lorsqu'il y a eu fusion. Ainsi, si la commune A de 2013 est le résultat d'une fusion des communes B et C de 2004, il sera impossible de recréer ces tracés à partir de ceux fournis par OSM. Lorsque c'est arrivé, j'ai additionné les valeurs des deux communes sur celle de 2013.
- les fichiers impossibles à traiter en l'état. Petit coup de gueule sur ce fichier précis, fourni par data.gouv. Pour résumer simplement : aucune règle de nomenclature n'a été appliquée pour harmoniser les noms de communes, et chaque département a fait un peu comme il voulait. Certains toponymes sont donc en majuscules sans tirets, d'autres en majuscules avec tirets, d'autres écrits normales, certains "Les [...]" sont bien écrits, d'autre écrits "[...] (Les)". Bref, on dirait que quelqu'un a juste copié/collé les données de chaque département, sans se soucier de la réutilisation de l'ensemble. Vraiment pas glop...
A suivre
Ouf, ce fut dur, mais on est enfin arrivé à un fichier shapefile rempli de données réutilisables. Au menu pour la suite : comment transformer ce fichier en cartes choroplèthes affichant plus de 9 000 zones...
Edit
Jérémie a posté un commentaire plein de bon sens, et qui mérite un grand merci et qu'on s'attarde sur une autre méthode pour gagner encore plus de temps !
Le fichier OSM contient en effet des identifiants uniques, dits codes INSEE, pour chaque commune (les deux chiffres du département plus les trois de l'identifiant local), mais le fichier de data.gouv les a séparés en deux.
Heureusement, en deux coups de cuillère à pot, on va pouvoir reconstituer ces id.
Text, pas Number
Tout d'abord, Calc Office va noter les chiffres 1, 2, 3, etc... Ce qui ne nous intéresse pas, puisqu'il nous faut trois chiffres sur chaque commune (001 pour la première, 010 sur la dixième et effectivement 100 sur la centième).
Cliquez pour agrandir l'image
Comment faire pour formater tout ça avec trois chiffres ? En convertissant simplement les colonnes en Texte, et pas en Nombre.
Pour cela, il suffit juste de cliquer-glisser sur les deux colonnes en haut (département et code commune) pour en sélectionner tout le contenu.
De là, un simple Ctrl+1 (pavé numérique) permet d'afficher les options de formatage de cellule. On choisit "Text", tout en bas.
On peut alors réécrire 1 en le précédant de deux 0, puis cliquer-glisser depuis le bord inférieur droit de la cellule jusqu'au 9, comme ceci :
Cliquez sur l'image pour l'agrandir
Plus qu'à faire la même manip en faisant maintenant précéder 10 d'un seul zéro, et de faire la même glissade jusqu'à 99 :
Cliquez sur l'image pour l'agrandir
Tous nos codes sont maintenant formatés avec trois chiffres, on n'a plus qu'à réunir le département et le code pour obtenir un identifiant unique.
Pour cela, on va dans la colonne qui va accueillir la fusion, et on tape à l'intérieur de la première cellule la formule =CONCATENATE(A1;B1)
Le résultat se plaque sur le bord gauche de la cellule, ce qui prouve qu'on se trouve bien face à un texte. Plus qu'à cliquer-glisser depuis le bord inférieur droit pour obtenir des identifiants identiques à ceux du fichier OSM.
Cliquez sur l'image pour l'agrandir
Et si jamais on réalise dans QGis que la colonne identifiant de l'un des deux fichiers est un nombre au lieu d'un texte, l'astuce du calculateur de champs permettra de convertir tout ça rapido.
Cette astuce fait effectivement gagner beaucoup de temps, donc encore une fois un grand merci à Jérémie !
Gare à la suite logique !
Dans certains cas particuliers comme les fusions ou les "villages morts pour la France", la commune en question n'apparaît pas dans le fichier de data.gouv, et il peut donc y avoir un "trou" entre les codes.
Pour l'illustrer, prenons les communes A, B et C (respectivement les codes 1, 2 et 3) de 2013. Si en 2009, A était fusionnée à B, le code 2 n'apparaît pas dans le fichier.
Mais si vous êtes un peu distrait (ou à la bourre) et que vous effectuez l'astuce précédente du cliquer-glisser, le code qui suivra 001 sera 002, et non 003.
Bref, assurez-vous juste qu'il n'y ait aucun trou dans les codes de communes avant de vous lancer !
