< retour à la page précédente

3.OpenData

Qualité des données OpenData RATP

Ce petit billet à l'attention des ré-utilisateurs de l'API http://navitia.io et des consommateurs des données RATP de http://data.ratp.fr Vous avez dû constater que les données de Paris proposées par l'API n'étaient ni stables, ni de qualité. Nous essayons de redresser les données proposées par la RATP sur leur serveur d'openData, mais certains cas sont difficilement gérables:

  • Le jeu de donnée actuellement à disposition ne décrit pas la majorité des calendriers de ce début d'année 2014. Du coup le métro est fourni comme ne circulant pratiquement pas. Nous avons donc dû prendre une semaine type de l'année dernière sur le jeu de données précédent et ré-appliquer les horaires sur 2014. On comprend bien que du coup, la qualité globale n'est pas satisfaisante.

  • Les correspondances fournies ne semblent pas être celles utilisées par le site ratp.fr : on trouve par exemple une correspondance de 2 minutes entre les stations de metro Montrouge et St Jacques par exemple. (ligne "3442548,3449469,2,69" du fichier transferts.txt). Erratum sur ce cas, autant prendre un exemple avéré ! 2 minutes entre la station des Abbesses et le Funiculaire de Montmartre. Du coup, on a préféré faire un calcul de correspondance basé sur les coordonnées pour le moment et ne pas tenir compte du fichier transfert. Pareil : pas très qualitatif tout ça.

  • Nous avons fréquemment des lignes de bus qui ne circulent plus et pour lesquelles nous devons attendre des mises à jours de données. Mais la fréquence de mise à jour des exports est encore très faible.

Quelqu'un d'autre constate-il les mêmes problèmes ? Comment les contournez-vous ? Et surtout : quelqu'un a-t-il déjà obtenu des réponses depuis la page de contact de http://data.ratp.fr ? Je continue le débat, ouvert par turblog, mais j'aimerais que les contributeurs du premier article du labs qui abordait ce sujet puissent me donner leur avis après 6 mois de recul.  

Par Stephan Simart, le 17 January 2014