L'arrière boutique de l'Open Data

J'ai découvert il y a quelques semaines le service online gratuit de Data Visualisation cartographique https://cartodb.com.
C'est un super outil pour maquetter (voire plus) la représentation graphique de données cartographiques, avec plein de paramètres pour mettre le focus sur tel ou tel champ de données.
Sa mise en oeuvre est des plus simples : vous importez un jeu de données et vous activez la représentation cartographique.

Après avoir suivi les quelques tutoriels à disposition, j'ai cherché à le mettre en pratique, à partir d'un jeu de données réel.
Pour cela, je disposait d'une base MySQL, pilotée par un CMS Joomla, qui contient des événements géolocalisés.
Je me suis dit : "Rien de plus facile, je récupère la table concernée dans un format standard, je l'exporte dans CartoDB et je n'ai plus qu'à jouer avec les paramètres de visualisation ...".
La réalité, c'est que la visualisation, c'était pas pour tout de suite. J'étais, sans le savoir, face à un problème de type Open Data. Comment mettre à disposition des données de qualité, à partir d'une base de données opérationnelle ?

Le premier problème a été d'identifier la ou les tables contenant les données qui m'intéressaient. Facile direz-vous ? Oui, si on est dans le cadre d'une application dont on maîtrise le MCD (Modèle Conceptuel de Données). Ce n'est pas toujours le cas, surtout si l'application a été développée par un tiers ou qu'elle est mise à disposition en mode SaaS (Software as a Service). On peut donc être bloqué car le fournisseur ne divulgue pas le MCD, ou alors on peut disposer d'un vieux MCD obsolète, ou tout simplement ne pas avoir d'accès SQL à la base de données.
Dans mon cas, ça allait : accès PhpMyAdmin à la base MySQL. Par contre, l'application c'est un CMS sous Joomla, avec N composants qui rajoutent ou modifient des tables, compliquant sérieusement l'identification des champs pertinents, et obligeant à naviguer entre tables à travers les relations ...
Après avoir identifié la bonne table, j'ai eu la mauvaise surprise de constater que les données de géolocalisation n'était pas isolées dans des champs dédiés, mais qu'elles étaient noyées dans un méga-champ nommé "metadata". Ce qui donne, par exemple, pour un seul champ :
{"robots":"","author":"","rights":"","xreference":"43.461403, -0.8210799999999381","marker":"ylw-pushpin.png"}
Autant dire que si vous importez ça dans CartoDB, il vous dira qu'il ne trouve pas de données de géolocalisation.

A ce stade, j'ai commencé à me dire que je ne devais pas être le premier à tomber sur ce type de problème et que la plupart des gens qui préparent des données pour un projet Open Data devaient probablement en passer par là. Je me suis donc pris au jeu et j'ai cherché à produire un jeu de données de qualité, partant du principe que l'objectif, en Open Data, est de mettre à disposition le jeu de données le plus simple, clair et propre, de manière à ce que le développeur qui s'en empare consacre toute son énergie à exploiter des données explicites et prêtes à l'emploi.

Il s'agissait donc, à partir d'une seule table (cas simple) de ma base MySQL, de n'extraire qu'une liste limitée de 4 champs, dont celui évoqué ci-dessus (metadata).

J'ai donc commencé par récupérer un export SQL de ma table. Je l'ai injecté dans un wAMP local, de manière à supprimer les champs inutiles et conserver une table épurée.

L'étape suivante consistait à remplacer le champ "metadata" par deux champs "latitude" et "longitude", contenant seulement les coordonnées perdues dans le champ "metadata". Et là, c'est pas gagné. Si vous avez quelques dizaines de lignes, ça peut se faire à la main, mais dans mon cas (plusieurs centaines), impossible de ne pas automatiser un minimum.
Il y a quelques années, je me débrouillais assez bien sous Unix avec awk, sed et compagnie, et ça aurait probablement été jouable. J'ai finalement opté pour Notepad++ qui m'a permis avec la fonction Rechercher/Remplacer de faire une bonne partie du boulot, le reste ça a été "à la main" et grosse galère car je me suis rendu compte que tous les enregistrements ne présentaient pas le même contenu pour le champ "metadata". Par exemple, un enregistrement avait une valeur pour le champ "author", ce qui perturbait les commandes de recherche/remplacement. Bref, il a fallu N itérations du genre modification-importation car impossible de détecter visuellement tous les cas particuliers. C'est l'échec d'importation qui me donnait l'erreur suivante ...

Après 2 heures de manipulation dans tous les sens, je suis enfin parvenu à injecter mes données dans CartoDB.

J'en suis arrivé à la conclusion que la mise à disposition d'un jeu de données "propre" et exploitable est un gros chantier, quasiment impossible à mener sans développeur ou expert en outils de manipulation de données. Dans le cas contraire, on peut toujours publier le jeu de données, et communiquer là-dessus, mais il sera probablement inexploitable en l'état.

Il doit être rare de pouvoir complètement automatiser toutes les opérations pour passer des données en base vers un jeu de données ouvert. Ceci signifie que les opérations manuelles (plus ou moins importantes) seront à refaire à chaque fois qu'on devra rafraîchir le jeu de données. Et se pose ici l'autre problème de l'Open Data : a-t-on sous la main un jeu de données de type "one-shot" ou alors un jeu de données fréquemment actualisé ? En effet, les projets d'Open Data prennent rarement en compte le rafraîchissement des données, ce qui conduit à répandre des jeux de données vite obsolètes. Dans le cas contraire, les opérations manuelles souvent incontournables peuvent rendre économiquement prohibitif le rafraîchissement des données.

Voilà, mon petit TP m'aura permis de mettre le doigt sur cette difficulté que je sentais déjà autour de l'Open Data : le coût de la qualité des données et de la fréquence d'actualisation.