Les données OpenData de la RATP
Il faut remercier la RATP qui a fait le choix d'ouvrir les données de leur offre de transport en OpenData.
C'est désormais la majeure partie de l'offre de transport en Ile de France qui est désormais disponible. Les données ouvertes par la RATP viennent en effet compléter celles du Transilien déjà accessible en OpenData.
Au défaut de participer au Hackathon, j'ai mené une analyse des données dans leur format GTFS.
En effet la qualité des données est un enjeu qui va au delà du slogan et de l'affichage marketing. C'est un critère déterminant pour l'utilisation des données en aval.
Le premier résultat de cette analyse est rassurant: la qualité est suffisante pour un réaliser un calculateur d'itinéraire. C'est déjà un point essentiel.
Néanmoins la qualité des données pourrait être meilleure à plusieurs niveaux
en éliminant les données inutiles
en utilisant mieux le format GTFS pour structurer davantage les données
en ajoutant quelques données manquantes
Elimination des données inutiles
1/ Dans les fichiers "calendar.txt", "calendar_dates.txt", "trips.txt", "stop_times.txt"
Aucun calendrier ("calendar.txt") ne devrait être complètement révolu au moment de la mise à disposition du jeu de données (2502 calendriers révolus au 04/06/2013).
De même pour les dates ("calendar_dates.txt") qui sont révolues.
De même encore les courses ("trips.txt") qui ne circulent que pour des calendriers révolus peuvent être éliminés ainsi que leurs horaires ("stop_times.txt").
2/ Dans le fichier "transfers.txt" :
Ce fichier définit des correspondances ("tranfers.txt") qui pointent des arrêts ("stops.txt") qui sont inconnus du fichier "stops.txt".
En effet la RATP ne peut publier que les arrêts ("stops.txt") de son offre de transport.
Les arrêts gérés par les autres acteurs du transport en IDF (SNCF, OPTILE, etc...) ne font pas partie du jeu de données mis en Open Data par la RATP.
Les correspondances entre l'offre RATP et celle de ses partenaires ne peut donc pas figurer dans le fichier "transfers.txt"
Le fichier "transfers.txt" pourrait donc être réduit à 7500 correspondances au lieu des 76542 fournis.
Ce nettoyage peut diminuer sensiblement le volume de données.
On peut imaginer que les développeurs seront plus à l'aise avec de moindre volumes qui se limitent aux seules données utiles.
Meilleur usage du format GTFS
Telle que les données fournies par la RATP, les lignes sont dupliquées à cause d'une distinction des sens aller et retour dans le fichier routes.txt.
Par exemple, un extrait du fichier "routes.txt" :
959390,100,"20","(GARE SAINT-LAZARE <-> GARE DE LYON) - Aller",,3,,FFFFFF,000000
959391,100,"20","(GARE SAINT-LAZARE <-> GARE DE LYON) - Retour",,3,,FFFFFF,000000
Or en GTFS, la ligne (sans considération de sens) devrait être définie une seule fois dans le fichier routes.txt.
C'est le fichier trips.txt qui est prévu pour faire la distinction de sens (aller et retour) avec le champ "direction_id".
cf : https://developers.google.com/transit/gtfs/reference?hl=fr#routes_fields
Ajout de données complémentaires
Le format GTFS met à disposition un certain nombre de paramètres optionnels qui permettent de mieux décrire l'offre de transport.
On ne peut qu'encourager la RATP à préciser ces paramètres dans les jeu de données à venir.
Par exemple les champs "parent_station" et "location_type" permettent de distinguer dans le fichier "stops.txt" les quais et leurs stations.
cf https://developers.google.com/transit/gtfs/reference?hl=fr#stops_fields
Ces informations supplémentaires facilitent la création de service comme :
l'affichage de la carte des stations de métro
la recherche de station dans un formulaire de saisie
Un mot pour conclure
Pour mener cette analyse, j'ai utilisé Chouette qui gère le format GTFS.
Les données sont à disposition sur cette plateforme: http://chouette.dryade.net/chouette2/users/sign_in
login: [email protected]
mdp: opendata
