Déroulement de la réunion

La réunion s’est déroulée en plusieurs étapes, à savoir la présentation du système de manière globale et ses deux interfaces utilisateurs (le client lourd et le client léger). Les participants ont ensuite expliqué leurs besoins metier et en quoi IQmulus pourrait être utile. Ils ont éffectué des manipulations sur des données tests via ces outils et ont enfin signalé les fonctionnalités manquantes ainsi que leurs atouts.

 

Plus concrètement, les différents points traités dans la réunion sont résumés ci-dessous :

 

En ce qui concerne leur données, la méthode d’acquisition de données à la SNCF s’est faite grâce à la mise en place de plusieurs mécanismes, à savoir les scanners statiques posés près de gares et les scanners dynamiques instalés sur les trains (prochainement aussi placés sur des drones). Ces équipements possèdent une capacité importante d’acquisition de données LIDAR de l’ordre de 2To par jour. Ces données sont traitées afin d’éffectuer la détection de plusieurs objets tels que le rails pour aider la maintenance de voies et parfois pour prevenir des accidents. A long terme, les participants souhaiteraient pouvoir effectuer automatiquement ces traitements de détection et de pouvoir visualiser à la volée ces masses de données car tout est actuellement réalisé de façon un peu manuelle. La SNCF pourraient fournir à IQmulus dans un premier temps un premier jeu de données de 100Go qui sera mis en open-source.

 

Quant aux traitements SIG souhaités, les participants s’interessent particulièrement à la détection d’arbres (workflow US2). Néanmoins, il paraît que celui-ci pourraient presenter des problèmes tel qu’il a été implementé actuellement. En effet, il est très frequent que les trains soient en hauteur par rapport au sol, contrairement à la voiture. Les critères d’utilisation des traitements pour la détection d’arbres proposés par IQmulus semblent donc incompatibles avec les conditions dans lesquelles les relevés LIDAR sont collectés à la SNCF (à tester). De plus, ils souhaitent étendre la portée des traitements de détection à d’autres types d’objets notamment les rails. Ils ont déjà implémenté leurs propres algorithmes dont la SNCF est proprietaire. Les participants souhaiteraient pouvoir fournir des binaires via l’interface IQmulus au lieu de recoder le workflow en DSL. L’idée d’un “workflow store” a été lancée (cf. Apple Store), ainsi il serait possible de publier des traitements (soit en binaire soit en DSL), les utilisateurs auraient les privileges sur qui en aurait accès.

 

Concernant le client lourd IQmulus de visualisation, il a été perçu comme étant limité vis-à-vis des fonctionailités proposées. De leur point de vue, l’outil CloudCompare parait plus adapté aux besoins de manipulation de nuage de points. En particulier, les fonctionnalités manquantes qu’ils attendaient sont : choix de centre de rotation, metadonnée visible, decoupage de points, immersion sur le nuage de points (semblable à une promenade dans un univers 3D, “free fly camera”), slider pour choisir l’échelle, ouverture de plusieurs fichiers (notion de projet comme dans un SIG), enregistrement de preferences également dans un projet, interaction en direct avec les données sur le cloud via un bouton dans le client lourd. Par rapport à ce dernier, il semble très intéressant de pouvoir visualiser en streaming ces données sans besoin de télécharger le tout en local. En effet, cette fonctionnalité n'existe nulle part ailleurs.

 

Quant au le client principal IQmulus, les participants étaient assez satisfaits et curieux. La notion de traitements (workflows) et de leur mise en queue dans le cloud a été très apprécié, surtout dans une perspective de réutilisation de la plateforme IQmulus où l’utilisateur peut définir et partager des traitements. Dans tous les cas, il faudrait informer l’utilisateur de l’état d’avancement de la prise en charge de leur workflows.