Faire de l’open-data efficace
… ou au moins ce que l’on en pense
“La donnée est le nouveau pétrole”
Selon l’ODI, “une infrastructure de données cohérente doit être une condition de base pour une société saine et progressiste, et pour une économie globale compétitive”.
Il devient clair qu’énormément de valeur se trouve dans la masse de données gigantesque que nous générons chaque jour. Bon nombre d’entreprises l’ont bien compris et en tirent déjà de gros bénéfices. Mais l’utilisation de la donnée pour construire de meilleures infrastructures publiques est encore balbutiante.
La nécessité d’une open-data efficace
Chez Ants, nous sommes convaincus que l’open-data est une nécessité. Nous croyons qu’utilisée à bon escient, elle pourrait bénéficier au plus grand nombre. C’est pourquoi nous travaillons autant que possible à démocratiser le concept de la donnée ouverte.
Cela implique de travailler main dans la main avec les collectivités publiques, génératrices de données. Mais la plupart d’entre elles ne sont pas toujours habituées à travailler la donnée, encore moins à la publier. Ce qui implique que l’open-data aujourd’hui n’est pas suffisamment efficace.
Voici quelques exemples et conseils concrets que nous tenions à partager afin d’aider à améliorer l’open-data.
ToilettesBordeaux
Il s’agit d’un projet annexe dont le but était de montrer que les technologies web peuvent servir à développer facilement des applications multi-support.
L’application (disponible pour Bordeaux et Paris) est une simple carte affichant la position des toilettes publiques, avec quelques informations supplémentaires comme le type de toilettes (lorsque l’on ne veut pas se retrouver face à un urinoir), la distance, le temps et l’itinéraire pour y accéder.
Nous avons utilisé un fichier JSON fourni par le site open-data de la ville de Bordeaux. Voici à quoi ressemble une entrée de ce fichier :
{ “PartitionKey”: “02a79969–27ab-4a73–9eff-352b6c906889”, “RowKey”: “c3752768-c886–44f6-a406–25de27e56d58”, “Timestamp”: “2014–10–07T14:31:48.8383233Z”, “entityid”: “02a79969–27ab-4a73–9eff-352b6c906889”, “cle”: “138”, “adresse”: “Place Dormoy”, “nom”: “Dormoy”, “quartier”: “Bordeaux Sud”, “typologie”: “Urinoir”, “x_long”: “-0.564321470670066”, “y_lat”: “44.8267129011554”, “geometrie”: “POINT (-0.564321470670066 44.8267129011554)”, “num_quartier”: “6”},
Nous n’avons pas eu de gros problèmes avec ces données, qui sont simples et efficaces. Toutefois, certaines informations sont très probablement issues directement de processus de travail internes, et ne sont donc pas pertinentes. Pour 2 raisons:
Fiabilité de la donnée
Certain champs — PartitionKey, RowKey, entityid — sont présents dans le fichier JSON, mais pas dans le fichier CSV, censé contenir la même information.
Pourquoi la donnée n’est pas cohérente entre les formats ?
Dans ce cas, l’information utile, celle qui importe, est la même dans les deux formats, il n’y a donc pas à s’inquiéter. Mais plus généralement, de telles différences peuvent remettre en question la fiabilité de la source. Quel est alors le fichier auquel il faut se fier ?
Une infrastructure de données, quelle qu’elle soit, doit être la plus fiable et transparente possible. Par exemple en étant très explicite, en documentant un maximum de quelles manières ont été générées les données.
Optimisation de la donnée
La donnée, pertinente ou non, a un poids. Les 3 champs cités précédemment, — PartitionKey, RowKey, entityid — , sont des exemples de données non pertinentes, qui prennent de la place pour rien.
Mais en y regardant mieux, même la donnée pertinente peut parfois peser trop lourd. Ici, les coordonnées des toilettes ont une précision qui peut aller jusqu’à 15 décimales, ce qui représente une précision d’environ 0.1 nm, grosso modo la taille d’un atome…
Une telle précision est clairement absurde (autant de décimales sont en général des résidus de calcul, et n’ont pas de réalité physique), d’autant plus lorsque la même information est présente 2 fois dans le même fichier.
Pour un bâtiment 7 ou 8 décimales (à peu près 1 mm de précision) suffisent à représenter précisement sa position.
Pourquoi dépenser autant de volume de données pour rien ?
La latitude 44.8267129011554 se résumerait à 44.8267129, et la longitude -0.564321470670066 à -0.56432147, et sans aucune perte d’information.
Dans cet exemple, avec seulement une centaine de points, l’information superflue ne représente que quelques octets… Bah, c’est pas si grave.
Mais à plus grande échelle, avec des jeux de données de plusieurs millions d’entrées, ces quelques octets superflus se transformeraient en quelques Giga octets, menant à des problèmes pénibles de traitement de fichiers. Pour rien.
La donnée doit être réduite à son minimum, sans perdre d’information.
Bordeaux3D
Pendant l’été 2014, on s’est amusé à jouer avec les données 3D toutes neuves de tous les bâtiments de Bordeaux Métropole. Le jeu de données est disponible sur la page open-data de Bordeaux Métropole, dans Modélisation Agglo 3D.
Ce projet expérimental est maintenant appelé City (et marche mieux sur Chrome), car il est techniquement capable d’afficher n’importe quelle ville dans un navigateur web, à condition d’avoir les modèles 3D à disposition.
Travailler avec le jeu de données original nous a posé quelques problèmes, principalement liés à l’accessibilité et la qualité de la donnée.
Accessibilité de la donnée
La région bordelaise est urbaine, ce qui implique beaucoup de modèles de bâtiments. Les stocker tous dans un seul fichier le rendrait beaucoup trop lourd à partager, d’autant plus si les gens n’ont pas besoin du jeu de données complet. Pensez à un architecte qui voudrait travailler sur un quartier seulement.
La bonne façon de faire, comme l’a fait la Métropole de Bordeaux, est de segmenter la donnée en zones, auxquelles les usagers peuvent accéder selon leurs besoins: une ou plusieurs zones à la fois, les zones d’une ville en particulier…
Pour la Métropole, la donnée est fournie sur environ 500 zones. Essayez de toutes les sélectionner. Vous ne pourrez pas les télécharger, parce que le service de téléchargement est limité à 500 Mo, et que l’ensemble des données pèse 1.8 Go. Il faut donc s’y prendre à plusieurs fois pour obtenir l’intégralité du jeu de données. Et je ne parle même pas des données texturées :/(environ 25 Go).
Pourquoi l’accès à la donnée est-il limité ?
Les gens devraient pouvoir accéder facilement à toute la donnée dont ils ont besoin.
Sans cette limitation, le service de téléchargement est correct. Mais dans tous les cas, il aurait été plus simple de faire appel à une API. Moins de restrictions, des requêtes programmées si on veut, la même interface graphique (basée sur cette API) si on préfère.
La qualité de la donnée
Donc maintenant, nous avons la donnée sur toutes les zones.
Chaque zone est un rectangle de 7 par 5 tuiles, et chaque tuile est un carré de 200m par 200m.
Pour s’y retrouver dans ce puzzle géant, toutes les tuiles ont des coordonnées globales (X et Y), et locales (x et y). Il est très important que ces 2 systèmes de coordonnées soient cohérents afin de reconstruire les géométries au bon endroit.
Et bien ce n’est pas le cas ici. Les axes Y et y ont des directions opposées, ce qui positionne les bâtiments à l’envers si, comme la plupart des gens, vous ne vous y attendiez pas. Certes, corriger ce problème est facile, mais ce n’est pas le sujet: chaque personne qui télécharge ce jeu de données va devoir se rendre compte de ce problème et le régler. C’est beaucoup trop de temps perdu à ne pas travailler sur la vraie donnée.
Mais il y a plus grave.
Une fois que les bâtiments sont à leur place, on se rend compte de la présence d’espaces ouverts entre les tuiles dans les 3 directions, sans qu’il y ait de raison apparente. Evidemment, il y en a une.
Une tuile a pour dimensions 200m par 200m. Mais dans la réalité, les bâtiments ne suivent jamais cette règle. Ce qui signifie qu’une grande partie des modèles 3D devraient être découpés en plusieurs morceaux pour rentrer dans leur tuile. Ce qui est une mauvaise idée, et Bordeaux Métropole a eu raison de garder l’intégrité des modèles, quitte à ce que certains bâtiments dépassent de leur tuile.
Cela implique que les tuiles ont des frontières théoriques, carrées, et des frontières réelles. Le problème est que le centre du système de coordonnées local de chaque tuile est le centre des frontières réelles au d’être celui des frontières théoriques. En d’autres termes, si un bâtiment dépasse largement de sa tuile (un pont par exemple), sa tuile sera largement décalée par rapport à sa position réelle.
Des calculs supplémentaires ont été nécessaires pour corriger ce problème dans le plan horizontal, ainsi que plusieurs aller-retours avec le fournisseur de données pour corriger la position verticale…
Et enfin, nous avons pu profiter de notre Bordeaux en 3D. Après un pré-traitement de la donnée fastidieux dont nous nous serions bien passé.
Pourquoi un jeu de données se serait pas utilisable tel quel?
Aucun pré-traitement ne devrait être nécessaire pour utiliser la donnée. Elle doit être utilisable telle quelle.
Dans le cas de données manquantes ou d’erreurs dans le jeu de données, il faut publier un jeu corrigé avec de la documentation concernant la correction. Surtout pas de patch externe à appliquer sans que l’on sache pourquoi.
Open-Moulinette
Pour certains de nos projets nous avons eu besoin d’utiliser des données INSEE.
L’INSEE a récemment publié tout un tas de données ouvertes concernant les IRIS, qui sont les plus petites entités géographiques que l’on peut étudier sans porter atteinte à la vie privée.
Toute la donnée dont nous avions besoin était présente, accessible et de bonne qualité. Néanmoins, utiliser cette donnée n’était pas si simple. C’est la raison d’être d’Open-Moulinette: digérer ces jeux de données de l’INSEE (et maintenant d’autres sources) de sorte qu’ils soient facilement manipulables par tout le monde.
De la donnée universelle
Certaines données INSEE utilisent des coordonnées géographiques pour localiser des points. Ces coordonées sont exprimées en projection de Lambert, car celle-ci est adaptée pour représenter précisément les lieux en France sur un plan. Mais comment faire si l’on veut utiliser un programme externe qui n’accepte que des latitudes/longitudes en entrée ? Ou si pour une raison ou une autre on veut appliquer une autre projection ?
Pourquoi certaines données ne sont utilisables que dans un certain contexte ?
Les projections sont vraiment pratiques, parce que le monde est en 3D, et que le papier et les écrans sont en 2D. Mais nous ne sommes pas convaincus que les projections doivent être utilisées dans les jeux de données. Il faut plutôt utiliser les latitudes et longitudes, car elles sont universelles. Et éventuellement fournir de l’information (ou même un algorithme complet) pour projeter efficacement ces points sur une carte.
En général, la donnée doit être publiée avec un format et des conventions les plus universels possibles. Le modifications de données liées à certains contextes doivent être mises de côtés, ou fournies à part avec de la documentation.
La structure de la donnée
Nous nous sommes également intéressés aux contours géographiques des IRIS. Les jeux de données sont disponibles ici. Voici ce à quoi ressemble le jeu de données une fois dézippé:
Beaucoup de dossiers, de sous-dossiers, de sous-sous-dossiers avec des noms bizarres, et beaucoup de fichiers pas forcément nécessaires.
Toute cette structure est directement issue des processus INSEE, et a probablement une bonne raison d’exister.
Bien que nous comprenions cela, nous ne comprenons pas forcément pourquoi cette structure est publiée de la sorte. Les gens ne sont pas intéressés par les reliquats de processus internes à l’INSEE. Les gens sont intéressés par la donnée pure, facilement manipulable.
Des fichiers avec des extensions comme .xls, .dbf, .prj, .shp, … ne sont pas facilement manipulables. Des routines ou des programmes externes sont nécessaires pour accéder à la donnée réellement intéressante.
Pourquoi la structure de la donnée est-elle si compliquée à manipuler ?
La première chose que nous ayons fait avant de travailler sur la donnée a été de transformer cette structure dans un format qui nous paraissait plus approprié : un simple JSON contenant toute la donnée structurée. Le format CSV est également intéressant, selon le langage qui est utilisé.
C’est la raison d’être d’Open-Moulinette. Des routines permettant de rendre les jeux de données faciles à lire et à manipuler. Nous avons également ajouté un tutoriel pour construire un tableau de bord permettant d’explorer la donnée INSEE. Parce que c’est bien plus simple de comprendre la donnée quand vous pouvez la représenter graphiquement.
Nous sommes convaincus que les consommateurs de données ne devraient pas à avoir à développer des projets comme Open-Moulinette. C’est aux producteurs de données de ne pas publier leurs jeux sans les rendre facilement manipulables. Quitte à ce qu’ils aient leur propre Open-Moulinette à faire tourner avant de publier la donnée.
Nos conseils pour générer de la donnée ouverte efficace
Chez Ants, nous voulons aider les services publics à générer de la meilleure donnée. Nos expériences ont montré qu’il y a encore beaucoup de choses à améliorer pour rendre l’open-data efficace. L’idée principale est que les producteurs de données doivent construire leurs jeux de sorte que les consommateurs puissent vraiment se concentrer sur l’analyse de ces données.
Voici nos conseils aux producteurs de données. Nous pensons qu’ils peuvent être utiles à tout le monde.
Fiabilité
- Gardez vos différents formats cohérents entre eux
- Soyez transparents sur vos données et sur la manière dont elles ont été produites
- Soyez explicites, documentez un maximum
Optimization
- Réduisez la donnée à son minimum, sans jamais perdre d’information
Accessibilité
- Fournissez un accès simple à tout le monde
- Ne restreignez pas la quantité
- Fournissez des filtres permettant d’adapter le contenu
- Utilisez des APIs autant que possible
Qualité
- Fournissez des jeux complets et vérifiés
- Mettez vos jeux à jour si des erreurs sont découvertes
- Documentez les mises à jour
- Restez à l’écoute de vos utilisateurs
Universalité
- Utilisez les formats et unités standards autant que possible
Structure
- Publiez des jeux de données bien organisés et compréhensibles par tous
- Rendez votre structure de données simple à manipuler, ne la publiez pas telle quelle
- Utilisez les formats JSON ou CSV ou fournissez des outils open-source pour les générer
- Ne supposez pas que les gens utiliseront les mêmes outils que vous
