Article rédigé par AdrienVH, le 16/10/2012
Retrouver l’article original en suivant ce lien : article
Chocolatine ou Pain au chocolat ? est un projet qui tenait à cœur à Romain Ménard, son concepteur, depuis déjà pas mal de temps. L’envie de créer ce petit site est venue de débats passionnés qui ont eu lieu dans son entourage. Notre ville de Poitiers est, en effet, à la frontière géographique et lexicale entre la chocolatine du sud et le pain au chocolat du nord. C’est finalement pour rebondir sur la polémique toute récente, liée aux propos de Mr Copé au sujet du Ramadan, que Romain a décidé de finaliser son site et de le lancer sur la toile. Sur le site, on vous demande de voter pour l’un ou l’autre terme, en précisant la ville dont vous venez. En quelques jours, le site a déjà collecté près de 20 000 votes !
En géographe averti, j’ai tout de suite vu l’aspect « Analyse Spatiale » de la question posée (effets de distance, d’appartenance, tout ça, tout ça,…). J’ai donc proposé à Romain de réaliser un rendu cartographique de ces votes. Dans ce billet, vous trouverez tout le processus technique d’exploitation des données, du fichier SQL à la carte finalisée…
Résultat cartographique et dataviz’
résultat de l’étude
Analyse de ces résultats
Sans faire une thèse sur les résultats obtenus, il y a quelques observations pertinentes à faire.
Comme pour les résultats simplement statistiques, le triomphe du pain au chocolat est aussi géographique. En effet, il domine les débats dans le nord et le sud-est de la France. Les statistiques montrent une domination moins importante (62% – 38%), mais on peut expliquer cela par le fait qu’un clan ait été plus mobilisé que l’autre. Dans le cas de la chocolatine, il y a une question identitaire derrière le terme, ce qui est moins le cas du pain au chocolat (terme plus générique). C’est ce qui explique la résistance de la chocolatine dans les statistiques, nuancée par la sombre vérité du terrain. Une façon de corriger ces biais aurait pu être pondérer les votes par le poids démographique des communes, mais cela aurait amené d’autres biais.
On peut aussi remarquer l’existence de zones de conflits entre les deux termes. Ces zones « tampon » sont bien évidemment situées entre les deux zones chaudes, sur le front de la bataille. Parmi ces départements conflictuels, indécis, on retrouve notre département de la Vienne (86), comme Romain l’avait senti, suite aux débats passionnés dans son entourage. On peut aussi noter des poussées inattendues du pain au chocolat et de la chocolatine, dans des départements ou zones clairement adverses.
Enfin, même dans les zones les moins consensuelles, on peut observer des sortes de diasporas, et ce des deux côtés. On peut aussi expliquer ce phénomène par l’aspect identitaire des termes, mais il y a aussi une question de biais statistique puisque sur plus de 36 000 communes françaises, seules 2415 différentes sont représentées dans les votes des internautes. C’est ce qui à tendance à donner beaucoup de poids aux villes et à ne pas lisser les résultats dans l’espace.
Bonus [18/10/2012 20h15] : Pour alimenter les discussions, voici un graphique qui représente l’usage d’un terme et de l’autre dans les livres numérisés par Google Books. On voit clairement qu’au début du XXème siécle, le terme « chocolatine » était majoritaire… Qui est vraiment la poule ? Et qui est l’œuf ? Enfin, moi, je dis ça, je dis rien !
Nettoyage et import du fichier SQL dans la base de données PostgreSQL
Le 15 octobre au matin, Romain m’a envoyé un fichier SQL comprenant les 18 636 votes collectés par son site jusque là. Comme souvent, l’exécution directe du fichier SQL dans PgAdmin III n’a pas fonctionné du premier coup. C’est surtout la création de la structure de la table qui a posé problème. Pour ne pas perdre trop de temps, j’ai créé cette unique et simple table manuellement. Après encore un peu de nettoyage (suppression des lignes qui posaient initialement problème et nettoyage des apostrophes sur les lignes INSERT INTO), le fichier SQL était prêt pour être exécuté dans pgAdmin :
INSERT INTO copc (id, ip, choice, city, date) VALUES
(1, ‘xx.xx.xxx.xxx’, 2, ‘41100’, 1349532447),
(2, ‘xx.xx.xxx.xxx’, 1, ‘86000’, 1349532421),
(3, ‘xx.xx.xxx.xxx’, 1, ‘33500’, 1349532415),
(4, ‘xx.xx.xxx.xxx’, 2, ‘14000’, 1349532404),
…
Le temps d’exécution de cette requête SQL est très court, malgré un nombre d’enregistrements assez conséquent (18 636).
Export de la table dans un fichier CSV, grâce à ogr2ogr
Pour la suite des événements (faites-moi confiance…), on va devoir utiliser des formats plus classiques, notamment du tableur. Pour arriver à un format comme celui là, on va utiliser l’outil ogr2ogr pour exporter la table en un fichier CSV, à l’aide de la ligne de commande suivante :
ogr2ogr -f « CSV » D:\dropbox\…\copc\csv\ PG: »host=localhost port=xxxx dbname=xxxxxxxx user=xxxxxxxx password=xxxxxxxx » « copc »
Là encore, l’exécution de cette unique ligne de commande est assez rapide.
Enfin, avant de pouvoir passer au géocodage de vos données, il vous faudra (parfois) faire encore un peu de nettoyage : séparateur décimal, colonnes obligatoires pour le géocodage (même vides), etc.
Géocodage des données du fichier XLS
L’opération de géocodage est essentielle ici, puisqu’il s’agit de la transformation d’une adresse postale en coordonnées géographiques (on déduit de l’adresse postale une localisation précise). Ici, nous n’avons que le code postal à notre disposition mais cela suffit car le rendu final se fera de toute façon à petite échelle. Cela compensera bien ce manque de précision.
Plusieurs sites internet vous proposent de procéder à ce géocodage pour vous, mais la plupart vous propose de le faire gratuitement jusqu’à un certain nombre d’adresses. Après, c’est payant. Le seul site qui offre une large marge de manœuvre, c’est celui que j’utilisais déjà à l’époque de la fac (http://www.batchgeocodeur.mapjmz.com/). Il permet notamment de géocoder jusqu’à 10 000 adresses en une seule fois. Seul soucis : c’est assez lent (environ une adresse toutes les 1,5 secondes, soit plusieurs heures pour 10 000 adresses). En import, comme en export, vous pourrez copier/coller depuis et vers Excel (la tabulation est utilisée comme séparateur).
Au final, les 18 636 codes postaux collectés ont tous été géolocalisés avec un degré de précision largement suffisant (> 4). En fait, seuls cinq codes postaux ont du être passés au géocodage une seconde fois, car le premier passage avait retourné une erreur serveur (500).
Création de la couche SIG et interpolation raster (IDW)
Avant de commencer cette étape, j’ai téléchargé, sur le site de l’IGN, un jeu de données sur les départements et les communes de France, disponible sous Licence Ouverte (GéoFLA). Je vais m’en servir pour des représentations cartographiques, mais aussi pour découper le raster créé. Quoi qu’il en soit, maintenant que nous avons un tableur propre avec nos coordonnées géographiques et nos votes, il ne reste plus qu’à créer une couche SIG (en Lambert 93) à partir de votre tableur. Je vous laisse faire cette opération avec votre logiciel SIG favori. Moi, je l’ai fait avec QGis.
Maintenant, on va s’attaquer à quelque chose de moins classique : l’interpolation. L’idée derrière cette opération, c’est d’utiliser la couche des points créée et des formules mathématiques (basées notamment sur la distance entre deux points) pour « interpoler » l’espace, notamment celui où il n’y a pas de point du tout. L’objectif c’est d’avoir une représentation continue dans l’espace d’un phénomène localisé. Plusieurs techniques d’interpolation existent, mais la plus adaptée, dans notre cas, c’est celle dite IDW (Inverse Distance Weighting). Cela se fait aussi avec QGis sans aucun soucis. Pour ma part, j’avais du temps et l’envie d’avoir un raster assez fin, alors j’ai demandé à ce que les pixels du raster fassent 1 kilomètre de côté. C’est pourquoi mon interpolation a pris plus d’une heure (ce qui n’est rien comparé à l’étape de géocodage) !
Découpage du raster obtenu par l’emprise d’une couche SIG
Une fois le raster créé par QGis et « stylé » par vos soins, vous pouvez le découper, soit en indiquant un rectangle d’emprise (bounding box), soit en désignant une « couche de masquage » (déjà ouverte ou non dans QGis). Dans les deux cas de figure, l’outil « Découper » de QGis génère en fait une ligne de commande qui sera ensuite interprétée par la librairie GDAL (celle souvent livrée avec ogr2ogr). Pour votre information, dans le cas d’un découpage par couche de masquage (notre cas ici), la ligne de commande produite par l’outil contient systématiquement une erreur : vous devrez remplacer « -crop_to_cutline » par « -r cubic » (après avoir cliqué sur le petit crayon jaune).
Map'Monde 