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