2. Méthode
2.2. Partenariat pour la démonstration
2.2.1 Rappel de la démarche prévue
Les étapes suivantes du projet ont été prévues initialement par Carte Blanche Conseil.
1ère phase : Expertise et spécifications
• Identification des interlocuteurs adaptés dans les cinq grands groupes d'exploitants Connex, Kéolis, RATP, SNCF, Transdev pour constituer un échantillon de démonstration cohérent : un réseau de bus ou de tram d'une ville moyenne de province, la ou les lignes SNCF reliant cette ville à Paris ou à une autre ville de province.
• Clarification des conditions de la fourniture de données-test avec les exploitants choisis. L'engagement du développement (phase 2) sera soumis à la condition de l'accord des exploitants retenus.
• Définition du format de fourniture avec chaque exploitant (actuel et évolution prévisible)
• Définition des tests de validation de ce format
• Identification des manques éventuels de données
• Spécification des éléments manquants dans Chouette et requis par le banc de test.
2ème phase : Développement, mise en service et validation
• Développement des traducteurs, intégration du banc de test (avec son IHM internet)
• Démonstration, tests de validation appliqués à trois sources existantes.
2.2.2 Résultats obtenus par la 1ère phase
La première phase a donc visé à identifier les trois réseaux acceptant d’expérimenter le banc de test et les interlocuteurs acceptant d’être les contacts techniques et représentatifs de ces exploitants.
Après divers échanges avec les cinq grands groupes d'exploitants Connex, Kéolis, RATP, SNCF, Transdev, par ailleurs membres de la PREDIM, pour constituer un échantillon de démonstration cohérent, il s'est avéré qu'aucun groupe ne s'est déclaré prêt à motiver un de ses exploitants à s'engager dans le projet.
Nous avons entamé une autre démarche — mais deux mois avaient été consommés à ce moment-là — par l’intermédiaire des Autorités Organisatrices en commençant par celles que nous avions rencontrées dans le
cadre de l’étude de faisabilité de l’opérateur de contenu : les communautés urbaines de Nantes et Rennes.
Elle a abouti à une présentation du projet devant le comité de pilotage de l’information multimodale à Rennes le 10 Février.
L’intérêt et l’accord de principe de Rennes Métropole et de la Région Bretagne nous ont été confirmés comme ceux de leurs exploitants : STUR et Direction Déléguée TER de la SNCF.
Au cours de la même réunion, il nous a été conseillé de sonder la Communauté Urbaine de Brest.
Celle-ci nous a notifié son accord par lettre du président datée du 3 juin 2005.
Les AOT nous ont dirigé vers les interlocuteurs appropriés auprès des exploitants respectifs.
2.2.3 Collecte de données auprès des exploitants
Demande de données
Carte Blanche Conseil a demandé aux exploitants concernés une fourniture de données selon les termes suivants.
• Carte Blanche Conseil se base sur le format proposé par l'exploitant et se charge des transcodages.
• Exigences vis-à-vis du format :
La fourniture doit être renouvelable en format identique lors des mises à jour des horaires.
Les fichiers doivent être exploitables sans reprise manuelle. (Par exemple, il faut que le nombre et les libellés des colonnes dans un export texte à partir d'Excel soient constants, que le codage des jours de validité des horaires soit homogène à travers l'ensemble des fichiers, que les identifiants des points d'arrêts soient consistants entre le fichier des arrêts et les fichiers d'horaires.)
! autres attributs (commune, code postal, etc.) Lignes et horaires des bus et trains:
! horaires
! missions
! tableaux de marche
! pour les trains: attributs tels que "réservation obligatoire"
Tout ce qui décrit les correspondances:
! entre lignes de bus aux arrêts de correspondance, entre les trains dans les gares
! entre les réseaux urbains et les gares.
• Périodes de validité:
! Pour les réseaux urbains : Vacances scolaires 2005, période normale 2005-2006
! Pour le réseau ferroviaire : été 2005, hiver 2005-2006.
Données collectées
Suite à cette demande, nous avons reçu plusieurs fournitures de données entre fin juin et octobre 2005. Les fichiers collectés se divisent en :
! Fichiers des arrêts,
! Horaires des lignes.
Les fichiers collectés ne réunissent pas toutes les caractéristiques souhaitées dans la demande, c'est-à-dire que sur chacun d'eux, il subsiste des réserves aussi bien sur la capacité du fournisseur à reproduire le même format à chaque mise à jour, que sur son statut technique précis et documenté.
Pour les réseaux urbains, nous avons en outre été confrontés à des défauts de cohérence entre les fichiers d'une même fourniture (p.ex. dans les noms d'arrêts) et à des fournitures partielles que nous avons complétées manuellement.
2.2.4 Développement des traducteurs
Carte Blanche Conseil s'est engagé dans le développement des traducteurs et le traitement des données collectées malgré les écarts importants entre les fichiers souhaités (conformes aux exigences de la demande reproduite ci-dessus) et les fichiers réellement obtenus.
Les traducteurs sont des logiciels capables de lire un fichier source au format identifié, et d'écrire un fichier cible dans le format TRIDENT.
S'appuyant sur les fonctions d'import CSV et de génération XML-TRIDENT de CHOUETTE, les traducteurs développés pour le banc de test opèrent en deux étapes :
• Lecture des fichiers source et génération de fichiers CSV moyennant des programmes développés en C++, intégrant des librairies Open Source pour la lecture des formats Excel et MapInfo.
Les programmes opèrent à partir d'un fichier source ainsi que d'un fichier de paramétrage préalablement adapté au fichier source. Le fichier de
paramétrage guide la lecture des données en définissant les délimitations de champs qui structurent le fichier source.
Le programme comporte un algorithme de normalisation des noms d'arrêts, dont le but est de neutraliser les incohérences les plus fréquentes entre les noms d'arrêt du fichier des arrêts et ceux des fichiers horaires.
• Conversion CSV vers XML moyennant les fonctions de CHOUETTE.
Au stade actuel, du fait de l'hétérogénéité et de l'instabilité des fichiers source, la mise en œuvre des traducteurs demande un paramétrage au cas par cas. Ce travail est évidemment préjudiciable à la productivité des traitements de données.
Ainsi, le problème des formats non stabilisés et non documentés représente le principal handicap rencontré par le projet banc de test PREDIM. Le problème est soluble par un accord entre exploitant et gestionnaire du banc de test sur un format d'échange identifié, stable et documenté, qui permettrait de réduire puis d'éliminer les analyses et opérations manuelles préalables au traitement automatisé d'une mise à jour d'horaires.
La négociation d'un tel accord, à la lumière d'un exposé par chacun des outils et méthodes utilisés pour générer et traiter les données échangées, permettraient en fait d'identifier l'ensemble des problèmes qui surgissent lors des traitements, et d'optimiser la productivité non seulement du côté du banc de test mais aussi du côté des exploitants.
Les résultats de cette démarche intéresseraient autant les exploitants que les autorités qui leur demandent d’organiser de tels échanges.