Fiabilité des données Open Data

Posté par Romain le 16/03/2017

Le plus problématique quand on développe une application basée sur des données Open Data, ce sont les données elles-mêmes. On ne les maîtrise pas, ni leur validité, ni leur fréquence de mise à jour. On est entièrement dépendant de l’organisme gérant ces données.

Cette semaine j’ai reçu un mail d’un utilisateur :

Bonjour j’ai raté mon bus et je suis obligé d’attendre 25 min car dans l’application le bus est à 17h49 et sur l’arrêt il est à 17h46 résultats je suis en retard pour récupérer mon fils au périscolaire comment je fais? C’est vous qui payé les employés de l’école qui vont rester 15 min de plus? Bref ce n’est pas la première fois à cause d’un soucis comme ça que je rate un bus et cela c’est toujours produit sur la ligne 39

Au delà de la forme, la question qui se cache derrière est : Comment être sûr de la fiabilité des données ? Et formulée du point de vue du développeur : À quoi bon passer un temps fou à développer une app si les données ne sont pas fiables ?

Validation

Un des projets développé dans le cadre de Naonedbus consiste à vérifier les horaires du GTFS fourni par la Tan en les comparant aux horaires fournis par leur API. Et ce ligne par ligne, service par service, afin de déterminer un indice de fiabilité du GTFS.

Principe

Pour valider le GTFS, je prend chaque ligne, récupère chaque service associé (pour la Tan ça correspond aux jours bleus, jaunes, verts…) et vérifie les horaires de chaque début de service, pour le premier arrêt des deux directions. Ce qui donne 3044 requêtes, réparties sur la journée histoire de ne pas surcharger les serveurs de la Tan.

Résultats

Grâce à cette analyse je peux avoir une idée de la fiabilité des données par ligne, et avoir un détail des services manquants ou erronés.

Exemple

La ligne 20 a un indice de fiabilité de de 0,99 car certains horaires indiqués dans le GTFS ne sont pas présents via l’API, comme on peut le voir pour l’arrêt Mendès-France-Bellevue (BLVU3) en direction de Ecole Centrale-Audencia (1) le jeudi 6 juillet 2017 :

gtfs api service
6:04 6:04 HS17P101-20-BLEU
6:24 6:24 HS17P101-20-BLEU
6:41 6:41 HS17P101-20-BLEU
6:57 6:57 HS17P101-20-BLEU
7:09 HA17P101-25-BLEU
7:10 7:10 HS17P101-20-BLEU
7:19 HS17P101-20-BLEU-1101100
7:22 7:22 HS17P101-20-BLEU

Indice pour chaque ligne

Ligne Indice Commentaire
1 1,00
2 0,98
3 1,00
4 1,00
10 0,98
11 1,00
12 1,00
20 0,99
23 1,00
26 0,98
27 1,00
28 1,00
29 0,91
30 0,93
33 0,75
36 0,99
39 0,91
40 1,00
42 1,00
47 1,00
48 0,94
50 1,00
54 1,00
59 1,00
66 0,00 L’api ne renvoie aucun horaire pour cette ligne
67 0,13 L’api ne renvoie que très peu d’horaires pour cette ligne
68 0,00 L’api ne renvoie aucun horaire pour cette ligne
69 0,99
71 0,97
75 0,99
77 1,00
78 0,84
79 0,91
80 1,00
81 1,00
85 0,99
86 0,98
87 1,00
88 1,00
89 1,00
91 0,99
93 0,97
95 1,00
96 1,00
97 1,00
98 1,00
C1 1,00
C2 0,98
C3 0,99
C4 0,93
C5 0,96
C6 1,00
C7 0,99
E1 1,00
E4 1,00
E5 1,00
E8 1,00
LU 0,83
NA 0,98
NL 0,87

Data d’analyse : 14/03/2017 • Données GTFS analysées : 19/12/2016 • Version de la base de données Naonedbus : 2.2

Tous les détails sont disponibles ici : https://goo.gl/dHsX8Q

Je connais maintenant les problèmes de chaque ligne, mais je ne sais pas encore qui a tort et qui a raison. À moins de vérifier manuellement — visuellement ? — chaque horaire pour chaque ligne, je ne sais pas s’il y a vraiment un bus à 7h09.
J’ai envoyé les résultats à la Tan, en espérant les aider à améliorer leur GTFS.

Alternative

Depuis la version 4.3 de novembre 2016, Naonedbus est capable d’afficher les horaires temps réel, ce qui permet de se passer des horaires du GTFS.

Mais là encore, il m’est impossible de vérifier ces données ¯\(ツ)/¯.