Les API de l’IGN sont bien pratiques, plusieurs existent : calcul d’itinéraires, d’isochrones autour d’une position, géocodage d’adresses, ou calcul d’altitude en un point donné. Comme la plupart des API, on les utilise sous contrainte. Pour l’API altimétrie : moins de 5 000 positions « alti-codables » par requête, et moins de 5 requêtes par seconde. Avec plusieurs millions de positions à coder, on peut s’attendre à des heures d’interrogation, et des essais répétés pour tenir compte des requêtes rejetées.

Un fichier parquet bien construit oriente le requêteur en lui disant d’abord où ne pas aller. Plus il ferme de portes à votre requête SQL, moins elle se perd en explorations inutiles, plus vite elle avance vers l’essentiel.

C’est exactement la logique du data skipping : éviter de lire ce qui ne sert à rien.

Pour cela, le format parquet dispose de trois leviers complémentaires — dont deux sont bien connus, et un troisième, plus discret : les filtres de Bloom.

Premier levier : des colonnes physiquement séparées.
Parquet est un format orienté colonnes. Si une requête ne porte que sur 3 colonnes d’un fichier qui en contient 20, alors les 17 autres ne seront tout simplement jamais lues. 

La base nationale des décès est un ovni statistique : c’est une des rares bases open data France entière qui décrive des personnes avec leurs nom et prénoms en clair. Aussi surprenant que cela puisse paraitre, les fichiers de l’Insee relatifs aux personnes décédées ne constituent pas des données à caractère personnel. Ils ne relèvent pas du secret de la vie privée, ce dernier ne protégeant que les individus en vie. La loi Informatique et Libertés (loi n° 78-17 du 6 janvier 1978) s’applique uniquement aux données concernant des personnes vivantes.

La base des décès comprend aujourd’hui près de 29 millions de décès survenus après 1970. C’est l’année à partir de laquelle les communes ont systématiquement transmis les mentions de décès à un répertoire national géré par l’Insee.

Cas d’école du data storytelling, la mise à jour annuelle des populations communales (dites « de référence ») se dévoile chaque décembre dans un ballet parfaitement réglé : l’Insee publie le même jour un « Focus » national et 17 « Flash » régionaux, immédiatement amplifiés par la presse locale et nationale.

Grande gagnante de la remise des prix : l’Occitanie ! À vrai dire, ce n’est pas nouveau, la vitalité démographique de cette région est régulièrement soulignée. Mais cette année, deux seuils symboliques sont en passe d’être franchis.

Deux exigences opposées tiraillent le cartographe : schématiser pour mieux imprimer les messages essentiels, ou délivrer le maximum de détails, tant que l’image le permet. Ces exigences ne sont pas forcément contradictoires.

En cartographie thématique, l’art de la coloration repose d’abord sur le découpage en classes, ce que l’on appelle discrétiser. Les bons logiciels proposent plusieurs méthodes automatiques : quantiles, intervalles égaux et Jenks (ou seuils naturels) sont les plus fréquentes.

C’est l’un des graphiques les plus utilisés dans la production statistique française, mais aussi le plus paresseux et le moins efficace pour comprendre et surtout mémoriser. La plupart des responsables éditoriaux le savent, formés qu’ils/elles le sont à la sémiologie graphique. Pour autant, pas moyen de remiser ces empilements : ils collent aux publications statistiques comme le sparadrap au capitaine Haddock !

Prenons comme premier exemple ce graphique sur l’évolution des crimes en France, classés par type. Le diagramme en barres empilées traduit tel quel le tableau croisé des données, y intégrant un total. Et c’est la principale raison de son emploi : on voit en même temps l’évolution d’ensemble et le détail des catégories. 

Les résultats des dernières élections françaises sont maintenant disponibles à un niveau fin, à la commune et même jusqu’au bureau de vote. Mais comment produire une cartographie lisible et synthétique à partir de données si détaillées ?

Ce travail récent de Karim Douïeb, largement repris, illustre bien le dilemme : il dénonce le caractère trompeur de la carte (choroplèthe) de gauche et propose à la place la variante (à symboles) de droite.

Les cartes choroplèthes sont faciles à lire avec leur coloration continue de tout le territoire. Mais l’œil voit seulement des surfaces, il ne peut faire le tri entre les territoires plus peuplés et les moins peuplés.

De plus en plus de bases sont désormais diffusées en parquet, ce format de données compact, maniable et spectaculairement rapide à interroger. Des outils simples le permettent.

J’observe pour autant ici ou là quelques défauts de préparation qui amoindrissent les avantages de ce nouveau format. Il est facile de les corriger avec un peu de vigilance, les bons outils, et le réflexe de tester ses fichiers avec quelques requêtes types.

1 – Des colonnes facilitant l’écriture d’une requête

Éric est régulièrement sollicité sur le thème de la sémiologie graphique, un de ses domaines d’expertise. Il intervient souvent pour des conférences, des exposés, des formations. Encore la semaine dernière, il était invité par SSPHub, le réseau des « datascientists » des services de la Statistique Publique, pour une visioconférence intitulée “La dataviz pour donner du sens aux données et communiquer un message”.

Qu’est-ce qui retient notre attention ? Dans le flot d’informations dans lequel nous baignons en permanence, il arrive que quelque chose accroche notre regard. C’est le eye catching content, le graal que recherche toute personne souhaitant communiquer. 

Je reçois chaque jour des dizaines de courriels, que je ne peux pas tous lire. Dans ce flot, un titre a capté mon attention, il y a quelques jours : walking or cycling 30 minutes per day. Dans mon filtre personnel, les mots-clés walk ou marche sont très réactifs. Cela m’a conduite à cette image :

Une carte statistique qui parle de marche, cela ne pouvait pas m’échapper ! Cette image, indéniablement accrocheuse, m’a sauté aux yeux, avec ses couleurs très brillantes, jaune radieux, vert éclatant, rouge lumineux.

Nous sommes entourés de données géolocalisées. La séparation données statistiques / données spatiales est bien souvent arbitraire. Mais si elle perdure, c’est parce que les outils SIG (systèmes d’information géographiques) sont lourds à installer et complexes à utiliser.

Avec son extension spatiale, DuckDB met enfin l’analyse géographique à la portée de tou·tes.

Comme dans les deux articles précédents, je vais présenter deux cas concrets, l’un avec les données GTFS de transports en commun dans la métropole toulousaine, l’autre avec la base adresse nationale (BAN).

DuckDB saurait-il rivaliser avec JavaScript pour exploiter des données JSON ? Ce n’est pas le terrain sur lequel j’attendais ce moteur SQL. Quelle ne fut pas ma surprise, pourtant, de le voir se jouer des imbrications les plus retorses, des modèles de données les plus échevelés, auxquels JSON accorde volontiers son flexible habillage.

Après le premier épisode consacré aux formats Parquet et CSV dans DuckDB, voici donc à nouveau deux exemples concrets de jeux avec des données formattées en JSON.